PEP 327: Decimal Data Type

[Bengt Richter]

On Tue, 3 Feb 2004 09:33:26 -0300, "Batista, Facundo" <FBatista at uniFON.com.ar> wrote:

>cookedm wrote:
>
>#- What we need for this is an interval type. 1.80 m shouldn't be stored
>#- as '1.80', but as '1.80 +/- 0.005', and operations such as addition
>#- and multiplication should propogate the intervals.
>
>I think this kind of math is beyond a pure numeric data type. 1.80 is to be
>represented as a numeric data type. And also 0.005. 
>
>But '1.80 +/- 0.005' should be worked in another object. Hey! These are the
>benefits of OOP!
>
The key concern is _exactly_ representing the limits of an interval that is
_guaranteed to contain_ the exact value of interest. One hopes to represent
very narrow intervals, but the principle is the same irrespective of the available
computer states available to represent the end points.

E.g., integer intervals can reliably enclose 1.8 and 0.005
(with [1,2] and [0,1] respectively). Of course, [1,2] +- [0,1]
=> [0,3] gets you something less than useful for 1.8+-0.005

But choosing from available IEEE-754 floating point double states
gets you some really narrow intervals, where e.g. 1.8 can be guaranteed to
be in the closed interval including the two nearest available
exactly-representable floating point numers, namely

    [1.8000000000000000444089209850062616169452667236328125,
     1.79999999999999982236431605997495353221893310546875]

I'll leave it as an exercise to work out the exactly representable value
interval limits for 0.005 and 1.8+-0.005 ;-)

The _meaning_ of numbers that are guaranteed to fall into known exact intervals
in terms of representing measurements, measurement errors, statistics of the
errors, etc. is a separate matter from keeping track of exact intervals during
computation. These concerns should not be confused, IMO, though they inevitably
arise together in thinking about computing with real-life measurement values.

Regards,
Bengt Richter