I'm running headlong into the dilemma of binary math representation, with
game-ending consequences, e.g.:
>>> 0.15
0.14999999999999999
Obviously, any attempts to manipulate this value, under the misguided
assumption that it is truly "0.15" are ill-advised, with inevitable bad results.
the particular problem I'm attempting to corral is thus:
>>> math.modf(18.15)
(0.14999999999999858, 18.0)
with some intermediate scrunching, the above snippet morphs to:
>>> (math.modf(math.modf(18.15)[0]*100)[0])/.6
1.6666666666664298
The last line should be zero, and needs to be for me to continue this algorithm.
Any of Python's help-aids that I apply to sort things out, such as formatting
(%), or modules like "decimal" do nothing more than "powder up" the display for
visual consumption (turning it into a string). The underlying float value
remains "corrupted", and any attempt to continue with the math adapts and
re-incorporates the corruption.
What I'm shooting for, by the way, is an algorithm that converts a deg/min/sec
formatted number to decimal degrees. It [mostly] worked, until I stumbled upon
the peculiar cases of 15 minutes and/or 45 minutes, which exposed the flaw.
What to do? I dunno. I'm throwing up my hands, and appealing to the "Council".
(As an [unconnected] aside, I have submitted this query as best I know how,
using plain text and the "tu...@..." address. There is something that either
I, or my yahoo.com mailer *or both* doesn't quite "get" about these mailings.
But, I simply do my best, following advice I've been offered via this forum.
Hope this --mostly-- works.)
>From the virtual desk of Lowell Tackett
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
