PEP 327: Decimal Data Type

[David M. Cooke]

At some point, Stephen Horne <steve at ninereeds.fsnet.co.uk> wrote:

> On Mon, 02 Feb 2004 17:07:52 -0500, cookedm+news at physics.mcmaster.ca
> (David M. Cooke) wrote:
>
>>At some point, "Batista, Facundo" <FBatista at uniFON.com.ar> wrote:
>>
>>> danb_83 wrote: 
>>>
>>> #- On the other hand, when I say that I am 1.80 m tall, it doesn't imply
>>> #- that humans height comes in discrete packets of 0.01 m.  It 
>>> #- means that
>>> #- I'm *somewhere* between 1.795 and 1.805 m tall, depending on my
>>> #- posture and the time of day, and "1.80" is just a convenient
>>> #- approximation.  And it wouldn't be inaccurate to express my height as
>>> #- 0x1.CC (=1.796875) or (base 12) 1.97 (=1.7986111...) meters, because
>>> #- these are within the tolerance of the measurement.  So number base
>>> #- doesn't matter here.
>>>
>>> Are you saying that it's ok to store your number imprecisely because you
>>> don't take well measures?
>>
>>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 disagree with this, not because it is a bad idea to keep track of
> precision, but because this should not be a part of the float type or
> of basic arithmetic operations.
>

I was being a bit facetious :-) This is certainly something that can
be done without being builtin, like this:
http://pedro.dnp.fmph.uniba.sk/~stanys/Uncertainities.py

> Having an approximate representation with an interval sounds good, but
> remember that one error source is the arithmetic itself - e.g. 1.0 /
> 3.0 cannot be finitely represented in either binary or decimal without
> error (except as a rational, of course).

Hey, if my measurement error is so small that arithmetic error becomes
significant, I'm happy.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)physics(dot)mcmaster(dot)ca