Float bug toolkit: what the hash is this?
Lex Spoon
lex at cc.gatech.edu
Thu Feb 19 20:03:51 UTC 1998
Bruce Cohen writes:
> Lex Spoon <lex at cc.gatech.edu> writes:
> >> Why do we need to consider Float's as being exact, anway? If we
> >> think of Float's as representing a range of values, which is how you
> >> should usually be thinking when you compute with them anyway, then you
> >> get easy answers to all these problems. <>= still make sense between
> >> two floats. A Float should not be = to any Integer or Fraction, just
> >> like a Dictionary is ~= to any integer.
>
> You've just described interval arithmetic, in which each "number" is
> actually a range (an open or closed interval on the Reals, depending on
> the circumstances), and operations modify the values (and potentially
> the openness) of endpoints. The size of the interval may be changed by
> an operation (for instance, multiplication can cause an interval to get
> larger).
I was actually trying to suggest something smaller-scale. Keep the
float arithmetic the same, but change the official viewpoint of what a
Float represents.
By treating a Float as a small range (determined by the precision of
the number), one can decide a lot of the things in this debate.
Furthermore, it's close to the viewpoint people already use for
floating point numbers anyway, eg, when they say "x := 1.0 / 3.0".
The strange result is that 1 ~= 1.0. This has been proposed before,
though, so I'm just adding to the rationalization. :) One could have a
separate equality method for the traditional meaning of equality, so
that (1 tradEquals: 1.0).
Lex
More information about the Squeak-dev
mailing list
|