[ANN] FixedPoint with selectable rounding

Chris Gonnerman chris.gonnerman at newcenturycomputers.net
Thu Oct 10 02:35:41 CEST 2002

----- Original Message ----- 
From: "Doug Fort" <doug.fort at verizon.net>

> On Wed, 09 Oct 2002 23:55:53 +0200, Piet van Oostrum wrote:
> >>>>>> "dougfort" <dougfort at dougfort.net> (D) writes:
> > D> You can select which rounding algorithm FixedPoint uses 
> > D> by assigning a bound function to 
> > D> FixedPoint.RoundingAlgorithm. 
> > 
> > The problem with such a more or less global assignment is 
> > that you can't use it in a thread-safe way.
> Our assumptions are:
>     1) You will assign the rounding algorithm once at start 
>        of program
>     2) The algorithm will not maintain internal state
> Given these assumptions, I believe it is thread-safe.
> I'm working on making the rounding algorithm a non-static 
> member, but this will be no more or less thread-safe that 
> the static member. Ultimately if you want to maintain 
> internal state, and/or change the algorithm during
> processing; you will have to provide your own protection.

Just an idea from left field:

Imagine for a moment a metaclass, for instance MetaFixedPoint,
which has a signature like this:

    MetaFixedPoint(RoundingFunction = None,
        ErrorOnMismatch = None)

which would return a class object when called.  The class 
object could then be used to instantiate objects:

    MyFixedPoint = MetaFixedPoint(myRoundingFunction, 1)

    n = MyFixedPoint("5.5")

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:

    OtherFixedPoint = MetaFixedPoint(None, None)

    m = OtherFixedPoint("4.01")

    m * n

would result in a TypeError.  Basically, you could do math
with automatic coercion between objects of the same 
MetaFixedPoint class as well as with int's, float's, etc.,
but mixing different MetaFixedPoint class instances would
throw an error if either operand had the ErrorOnMismatch as

Threadsafe, because each instance "knows" from it's class
how to round, and further individual modules can have their
own consistent rounding without impacting other modules.


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

Still, here it goes, into the darkness of the ng...
Maybe it will spark a good idea somewhere.

Chris Gonnerman -- chris.gonnerman at newcenturycomputers.net

More information about the Python-list mailing list