[ANN] FixedPoint with selectable rounding

[Chad Netzer]

On Wednesday 09 October 2002 17:35, Chris Gonnerman wrote:

> Imagine for a moment a metaclass, for instance MetaFixedPoint,
> which has a signature like this:
>
>     MetaFixedPoint(RoundingFunction = None,
>         ErrorOnMismatch = None)
[snip]
> Such instances would automatically round using the supplied
> rounding function, and if the ErrorOnMismatch value is "true,"
> computations with mismatched types would result in an error:

This seems fairly nice to me, with one proviso:

If ErrorOnMismatch is false for both m and n, and m and n are different 
classes, then math operations aren't strictly commutative:

   m + n    results in a different type of object than   n + m

Am I right?  (I may not be, I haven't had the need to overload operators in 
my python code)  This makes me a bit uncomfortable.  In particular, the 
rounding rules, with further use of the combined object, will change 
depending on the positional order of expression operands.

I would suggest that this should always throw an error, unless written 
something like this:

    m = OtherFixedPoint("4.01")
    n = MyFixedPoint("5.5")
    o = m + OtherFixedPoint( n )

ie. explicit conversion between types.  In practice, you will almost always 
be combining the same types (in the code you control), so the verbose casting 
would not always be necessary.  But getting someone else's FixedPoint objects 
(or another function's), you then have to force a decision, explicitly, to 
combine them.

This is all thread safe, but even more so, you can safely use multiple 
FixedPoint rounding implementation (say one customer needs it done one way, 
and another customer, another way) in your program, without having to set 
module globals (which I see as a fragile implementation).

> Gah.
>
> That must be a bad idea, because it's hard to explain.

I think you did a better job than I. :)

-- 

Chad Netzer
cnetzer at mail.arc.nasa.gov