Decimal vs float

[Kay Schluehr]

Steven D'Aprano wrote:
> On Sat, 21 Jan 2006 03:48:26 +0000, Steve Holden wrote:
>
> > Steven D'Aprano wrote:
> >> On Fri, 20 Jan 2006 04:25:01 +0000, Bengt Richter wrote:
> >>
> >>
> >>>On Thu, 19 Jan 2006 12:16:22 +0100, =?ISO-8859-1?Q?Gerhard_H=E4ring?= <gh at ghaering.de> wrote:
> >>>[...]
> >>>
> >>>>floating points are always imprecise, so you wouldn't want them as an
> >>>
> >>>Please, floating point is not "always imprecise." In a double there are
> >>>64 bits, and most patterns represent exact rational values. Other than
> >>>infinities and NaNs, you can't pick a bit pattern that doesn't have
> >>>a precise, exact rational value.
> >>
> >>
> >> Of course every float has a precise rational value.
> >> 0.1000000000000000000001 has a precise rational value:
> >>
> >> 1000000000000000000001/10000000000000000000000
> >>
> >> But that's hardly what people are referring to. The question isn't whether
> >> every float is an (ugly) rational, but whether every (tidy) rational is a
> >> float. And that is *not* the case, simple rationals like 1/10 cannot be
> >> written precisely as floats no matter how many bits you use.
> >>
> >>
> >>>You can't represent all arbitarily chosen reals exactly as floats, that's true,
> >>>but that's not the same as saying that "floating points are always imprecise."
> >>
> >>
> >> "Always" is too strong, since (for example) 1/2 can be represented
> >> precisely as a float. But in general, for any "random" rational value N/M,
> >> the odds are that it cannot be represented precisely as a float. And
> >> that's what people mean when they say floats are imprecise.
> >>
> >>
> >>
> > And you thought Bengt didn't know that?
>
> I didn't know what to think.
>
> Given the question "I want 0.1, but my float has the value 0.100...01,
> why does Python have a bug?" comes up all the time, does it really help
> to point out that the float representing 0.100...01 is an exact rational
> -- especially without mentioning that it happens to be the *wrong* exact
> rational?

I concur and I wonder why CAS like e.g. Maple that represent floating
point numbers using two integers [1] are neither awkward to use nor
inefficient. According to the Python numeric experts one has to pay a
high tradeoff between speed and accuracy. But as it seems it just
compares two Python implementations ( float / decimal ) and does not
compare those to approaches in other scientific computing systems. By
the way one can also learn from Maple how accuracy can be adjusted
practically. I never heard users complaining about that. I recommend
reading the Maple docs that are very explicit about this.

Kay

[1] It is a little more complicated. Maple makes the distininction
between floats ( hardware ) and sfloats ( software ) but makes only
limited use of hardware floats:

"For Maple 9, a software floating-point number (see type[sfloat]) and a
general floating-point number (see type[float]) are considered to be
the same object. Maple hardware floating-point numbers can only exist
as elements of rtable (Arrays, Matrices, and Vectors) and internally
within the evalhf evaluator. See UseHardwareFloats."


"The UseHardwareFloats environment variable controls whether Maple's
hardware or software floating-point computation environment is used to
perform all floating-point operations.

This environment variable has influence only over computations done on
floating-point rtables (Arrays, Matrices and Vectors). In future
versions of Maple, UseHardwareFloats will be used to force all
floating-point computations to be performed in the hardware
floating-point environment.

The default value of UseHardwareFloats is deduced. The value deduced
tells Maple to deduce the computation environment (hardware or
software) from the current setting of the Digits environment variable:
if Digits <= evalhf(Digits) then hardware float computation is
performed; otherwise, the computation is performed in software. The
value of UseHardwareFloats can be changed by using the assignment
operator. "