Decimal() instead of float?

[Ron Adam]

Michael B. Trausch wrote:
> On Fri, 2006-11-17 at 21:25 +0100, Fredrik Lundh wrote:
>> > Some of the lat/long pairs that I have used seem to come out fine, but 
>> > some do not.  Because the mathmatics used with them involve complex 
>> > equations when determining distance and the like, any error gets 
>> > massively compounded before a final result is evident.
>>
>> sorry, but I don't think you have the slightest idea what you're doing, 
>> really.
>>
> 
> Sure, I do.  Let's say that I want to work with the latitude 
> 33.6907570.  In Python, that number can not be stored exactly without 
> the aid of decimal.Decimal().
> 
>  >>> 33.6907570
> 33.690756999999998
>  >>>

> As you can see, it loses accuracy after the 6th decimal place.  That's 
> not good enough:  I have 8 numbers that need to be exact, and I am only 
> getting six.  That error will propagate throughout any multiplication or 
> division problem.  The error /compounds/ itself:

Actually it doesn't loose accuracy until the final decimal place, which is 
probably much smaller than the accuracy you need unless you are doing 
theoretical research on very small time frames with ideal numbers.  Then, yes 
you may need to use either numeric or decimal which can support a much higher 
precision.  Numeric is much faster so I would try that first.

On the other hand, if you are writing an application that does practical 
calculations on real measured data, then you have two sources of errors to be 
concerned with.  One is the unseen error from the actual measurements which is 
probably much bigger than the error you are trying to avoid.  And the other is 
the minuscule error caused by the binary C representation.

For example if a device measures a value of 33.6907570,  it is a measurement 
that can be off by +- 0.0000005 (or more, depending on the accuracy of the 
device), compared with the error of 0.0000000000000001, it is huge.  So if you 
are not already taking into account the larger error, by rounding your results 
to a proper number of significant digits, then you may have a much bigger 
problem, and a much larger real error than you realize.

So, you first need to manage the errors introduced when the data is created.  By 
doing that, you will probably find it will also resolve the smaller error you 
are concerned about here.

Cheers,
    Ron