Decimal() instead of float?

[Tim Peters]

[Michael B. Trausch]
>> 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.

[Terry Reedy]
> No, it loses accuracy in the 15th decimal place, which is the 17th digit.
> This is far more accurate than any measured latitude could be.
> If the above is a measurement, it represents anything from 33.69075695
> to 33.69075705.  The conversion error would have to be multiplied by some
> number of millions before it would be visible in the 7th decimal place
> (your last).
>
> Any trigonometric calculations will use an *approximate* value of pi and
> polynomial *approximations* of the theoretical functions.

The trend in "modern" math libraries is actually that sin(), cos() and
tan() return a result strictly less than 1 ULP off from the true
mathematical result (including "acting as if" they used an infinitely
precise value for pi).  It remains unclear what actual benefit there
is in, e.g., treating a sloppy argument like 2.31e273 "as if" it were
infinitely precise and reducing it by an infinitely precise value of
pi, /except/ that it allows making precise statements about the
accuracy of functions doing so.  In effect, this way all the blame
gets pinned on the user if they don't like the results ;-)

> Perhaps you have been given impossible conditions to fulfill.

I'm sure it's inconceivable to any programmer that management would
have an unreasonable expectation.