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

Raymond Hettinger python@rcn.com
Thu, 6 Feb 2003 00:31:03 -0500


Let's continue all of this in a private discussion.

If Tim had time to answer these emails, then it
would already be done; the problem is 95% solved
and it won't take rocket science to cover the last 5%.

Raymond


----- Original Message ----- 
From: "Tim Peters" <tim_one@email.msn.com>
To: "David LeBlanc" <whisper@oz.net>
Cc: <python-dev@python.org>
Sent: Wednesday, February 05, 2003 9:35 PM
Subject: RE: [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.
> 
> 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>.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev