[Python-Dev] RE: FixedPoint and % specifiers.

[Tim Peters]

[David LeBlanc]
> Well sheesh, I guess this just points to how long it's been since
> I've done any serious C/C++ involving format specifiers. %f does what
> I expect given a string initializer of a FixedPoint.

Then you haven't tried enough examples yet (one of my last two msgs showed a
surprising result from "%.17f" % FixedPoint("0.1")).

> It's confusing to think of FixedPoints as really being Floats though.

They aren't floats, but they participate in Python's numeric protocols, and
"silently coerce when in a float context" is one I don't personally like but
is generally expected.  FixedPoint plays along with it, although in a
perverse way (it usually coerces the float to a FixedPoint instead of vice
versa, since that's probably less surprising more often).

> If FixedPoint is going to be oriented towards business app programmers
> and/or edu-kids, isn't the need to pass a string a bit counter intuitive?

Yes, but, as before, inputs to FixedPoint constructors are unlikely to be
literals.  In business apps, they're likely to be sucked out of databases,
most of which support a native decimal type of their own.  In that context
there's no cause for any loss of information.

> Has the parser hacked the arg into a float by the time the __init__
> sees it?  (I suppose, come to think of it, that's an obvious "yes".)

Two points!  That's right.

> I suggest that DEFAULT_PRECISION should be 4. From the dim recesses of
> my pre-history, I seem to recall that the money programmers liked that -
> they _saved_ the round-offs into what was called a "penny register" and
> accumulated them. When you're dealing with millions, a drip here
> and a drop there and pretty soon, if you're dishonest, you can add a
> check to the check processing run for some serious pocket change (this
> actually happened) ;)

This module has been in use for a few years already.  If the people who
actually used it suggested this, I'd be happy to oblige.  But this is the
first time it's been suggested, and by someone who hasn't used it "for
real", so I'm inclined to let it go at that.

> Ok, so FixedPoint is really just a subterfuge for floats?

No.  Read the docs and play more with the module.  For example, FixedPoint +
and - are always exact.  Float + and - are not.

> Seems less than useful to our money and edu-kid users? (I think I'm
> hinting here that FixedPoint should be a distinct type if it's really
> going to have the semantics the intended audience expects. That probably
> kills it for 2.3 I guess.)

FixedPoint is already a distinct type, but if you mix one with a float,
you're going to get surprised.  The surprise will come from the float part,
though, not from the FixedPoint part.  Don't mix FixedPoints with floats, or
use them in float contexts, and you won't get surprises.

> ...
> Agreed - internally, a FixedPoint should retain all it's digits and only
> have any idea of precision at display time IMO.

I don't know what this means, or do but assure you it can't be implemented.
For example, the mathematical result of FixedPoint(1)/7 doesn't have a
finite decimal representation -- "all its digits" is unbounded.  As
implemented, the result inherits its precision from the FixedPoint operand,
which can be as large as you like, but must be specified in advance.

>>> print FixedPoint(1, 70)/7
0.1428571428571428571428571428571428571428571428571428571428571428571429
>>>

Try that with floats and see what you get <wink>.