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).

It probably won't surprise you much to find out that several of the
people who wrote the IEEE 754 standard were interested in interval
arithmetic, and that some of the features of the standard are intended
to support it.  For instance the architect of the algorithms that Intel
first used to implement 754, both in software and silicon, John Palmer,
designed an interval arithmetic package that ran on top of the Intel
subroutine library.

That said, I have to say that, while I agree that Float's should not be
simply comensurable with Integers, I'm not sure that equating floating
point arithmetic and interval arithmetic is a good idea.  Aside from the
performance impact, there's the principle of least surprise, as far as
results are concerned.  Right or wrong, users usually expect to see one
number resulting from an arithmetic operation, or sequence of
operations, so giving back an Interval by default is probably not a good
idea.  Also, it's not always the case that the middle of an interval returned
from an operation is equal (and just what does that mean in this
context, anyhow?) to the number that would result from applying that
operation to the two numbers representing the middles of the operands of
the interval operation.  So accuracy as well as precision becomes an issue.

One compromise would be to handle an IEEE imprecision exception by
redoing the offending operation as an interval operation, coercing the
operand numbers to intervals.  Chained calculations would have to be
rolled back and redone as a group for this to be at all useful.

>> Some people will get burnt when 1 ~= 1.0.  But then maybe they will
>> remember what floating point numbers and "equality" really are.  (Or
>> maybe they'll say "Smalltalk is stupid" and leave :))
>> 
>> Unfortunately, this viewpoint also makes comparison with < and > of
>> floats kinda strange.  It's possible for more than one Double to fit
>> in the range covered by a single Float.  How do you compare these
>> doubles to the float?  They should really not be =, <, or >.

They shouldn't be =, but why not have a ~ (damn, don't have an
"approximation relation" symbol on this keyboard) relation?  This is
equivalent to "compared equal, imprecisely", i.e., equal within the
range of precision of the more imprecise of the operands.  Then < and >
could always be precise, and would work as expected.

>> None of these concerns will mess up people employing good programming
>> practice.  If they want strict equalities, they should almost
>> certainly not be using floats.  If they want fuzzy comparisons, they
>> should just be using < and >.  And if they have mixed Doubles and
>> Floats, uh, hmm, well, they have to be careful.

But note that, per the above, if = isn't an imprecise operation, then <
and > have to be.  The slop has to fall somewhere.

>> It would be nice to have a version <>= that conceptually convert to
>> Double and use the midpoint of the represented region, they way the
>> standard <>= mostly (but not always) work now.  Just like String has =
>> and sameAs:.

See above.  This is probably not very useful because of the (invisible)
errors that would occur.
-----------------------------------------------------------------------------
"Designers are pretty bright people, however.  They can come up with a
plausible-sounding example for almost anything." - Donald Norman
-----------------------------------------------------------------------------
Bruce Cohen,                               |  email: cohenb at gemstone.com
GemStone Systems, Inc.                     |  phone: (503)533-3602
20575 NW Von Neumann Drive                 |  fax:   (503)629-8556
Beaverton, OR USA 97006                    |  web:   http://www.gemstone.com