On Tue, Apr 20, 2010 at 11:58 AM, Lowell Tackett <lowelltack...@yahoo.com>wrote:
> 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.
>
That is not precisely correct - modf first converts decimal to a float and
then applies the calculation. Try this instead:
def modf(mydecimal):
num = decimal.Decimal('1.0')
return (mydecimal%num, mydecimal//num)
On my machine this returns (with
In [18]: modf(d)
Out[18]: (Decimal('0.15'), Decimal('18'))
Which are easily converted.
In [30]: (modf(modf(d)[0]*100)[0])/decimal.Decimal('.6')
Out[30]: Decimal('0.0')
So your problem with decimal isn't that it lacks the precision you're
seeking - you're simply converting it to a float /before/ performing the
calculations, which makes turning it into a decimal in the first place
pretty much useless.
HTH,
Wayne
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
