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

[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. It's confusing to think of FixedPoints
as really being Floats though.

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?
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".)

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) ;)

More below:

<snip>
> floats have no inherent precision in this sense, and the number you passed
> to the constructor was not decimal 2.135.  Appendix A of the Tutorial
> explains this; the number you actually passed was
>
>     1201898150554501 / 2**49 ==
>     2.1349999999999997868371792719699442386627197265625
>
> and FixedPoint rounded that correctly to 2 decimal digits after the radix
> point.  You would have been more surprised if FixedPoint had said the
> precision was 49, but it does require exactly 49 digits after the decimal
> point to capture your input number without loss of information.
>
> >>> print FixedPoint.FixedPoint(2.135, 51)
> 2.134999999999999786837179271969944238662719726562500
>
> >>> print FixedPoint.FixedPoint("2.135", 51)
> 2.135000000000000000000000000000000000000000000000000

Ok, so FixedPoint is really just a subterfuge for floats? 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.)

> Now forget literals -- they really aren't very interesting.  You normally
> have computed quantities, and there's no hope of *guessing* "the inherent
> precision" from those, unless they're also FixedPoints and so explicitly
> support a reasonable notion of precision.  You can't guess this
> from a float
> in isolation, and you can't guess anything about how many digits after the
> decimal point are implied by an integer.  You either accept the
> constructor's default (2), or explicitly tell it how much precision you
> believe the input has.

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

Dave LeBlanc
Seattle, WA USA