numeric rounding thought

Ron Adam radam2 at tampabay.rr.com
Sun Nov 2 23:13:03 CET 2003



With all the discussion about numbers here and particularly in regards
to prePEP concerning decimal data types got me wondering about how
numbers are handled when it comes to rounding. And if that can be
improved.

My thought/question is,  is it possible to have a numeric varable
where weather or not it's value has been rounded, and which way, is
persistent?

For example using 2 bits to represent this you would have something
like the following for each value of n:

n00	# value not rounded,  an exact amount
n01	# rounded down
n10	# rounded up
n11	# rounded even, sum of oppositely rounded numbers

I was originally thinking base 10 rounding,  but realized this would
apply to base 2 numbers also.  

If the numbers retain their rounding status, would it be possible to
use that in the following ways.

Addition:
n00 = n00 + n00   
n01 = n00 + n01    or   n01 = n11 + n01
n10 = n00 + n10    or   n10 = n11 + n10
n11 = n01 + n10    or   n11 = n11 + n11

The rules of multiplication would be the same as addition.

Subtraction would reverse the bits of the second term and then be the
same as addition. 

Division .....  ?   I haven't thought past this point yet. But I don't
think it would be too hard to figure out.  This would set a rounding
bit depending on the outcome and the rounded status of the varables
used.

Anyway,  this is just an idea and I was wondering if something like
this would help in cases like representing 0.1 in binary or 1/9 in
decimal?

Could something like this reduce the trailing digits that sometimes
appear by allowing the number to be rounded in the appropriate
direction?  or be used to indicate repeating decimals?

Would this  maintain a significant degree of accuracy over a large
numbers of operations within a given precision?

Are there systems that have used something like this before?   

And of course this may be too hardware/compiler dependant to
implement.  Or it may take up more memory or slow things down too much
to be worth while. 

_Ron     (Just thinking out loud.)


Ronald R. Adam
radam2 at tampabay.rr.com





More information about the Python-list mailing list