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
--
http://mail.python.org/mailman/listinfo/python-list
