On 2017-11-09 15:50, Nicolas Cellier wrote:
This is out of context.
There is no such thing as Fraction type covered by IEEE 754 standard.
Yes, I agree. But we should still strive to model arithmetic embracing
the principle of least surprise. That's why in every arithmetic system
I'm aware of (with the exception of very old CPUs dating back several
decades), for finite x, y the
x = y if and only if x - y = 0
property holds.
Let's put it in another perspective: what's the usefulness of having
x = y
evaluate to false just to discover that
x - y
evaluates to 0, or the other way round?
Anyway relying upon Float equality should allways be subject to extreme
caution and examination
For example, what do you expect with plain old arithmetic in mind:
a := 0.1.
b := 0.3 - 0.2.
a = b
This will lead to (a - b) reciprocal = 3.602879701896397e16
If it is in a Graphics context, I'm not sure that it's the expected scale...
a = b evaluates to false in this example, so no wonder (a - b) evaluates
to a big number.
But the example is not plain old arithmetic.
Here, 0.1, 0.2, 0.3 are just a shorthands to say "the Floats closest to
0.1, 0.2, 0.3" (if implemented correctly, like in Pharo as it seems).
Every user of Floats should be fully aware of the implicit loss of
precision that using Floats entails.
So, using Floats to represent decimal numbers is the real culprit in
this example, not the underlying Float arithmetic, which is very well
defined from a mathematical point of view. In other words, using Floats
to emulate decimal arithmetic will frustrate anybody because Floats work
with limited precision binary arithmetic. Users wanting to engage in
decimal arithmetic should simply not use Floats. (That's the reason for
the addition of limited precision decimal arithmetic and numbers in the
IEEE 754-2008 standard.)
That said, this does not mean we should give up useful properties like
the one discussed above. Since we *can* ensure this property, we also
should, in the spirit of the principle of least surprise.
What's problematic in Pharo is that comparison works in one way while
subtraction works in another way but, mathematically, these operations
are essentially the same. So let's be consistent.
In the case of mixed-mode Float/Fraction operations, I personally prefer
reducing the Fraction to a Float because other commercial Smalltalk
implementations do so, so there would be less pain porting code to
Pharo, perhaps attracting more Smalltalkers to Pharo.
But the main point here, I repeat myself, is to be consistent and to
have as much regularity as intrinsically possible.
