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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4