On 2017-11-10 00:02, Henrik Sperre Johansen wrote: > raffaello.giulietti wrote >> On 2017-11-09 21:49, Stephane Ducasse wrote: >>> On Thu, Nov 9, 2017 at 5:34 PM, Nicolas Cellier >>> < > >> nicolas.cellier.aka.nice@ > >> > wrote: >>>> Note that this started a long time ago and comes up episodically >>>> http://forum.world.st/Fraction-equality-and-Float-infinity-problem-td48323.html >>>> http://forum.world.st/BUG-Equality-should-be-transitive-tc1404335.html >>>> https://lists.gforge.inria.fr/pipermail/pharo-project/2009-July/010496.html >>>> >>>> A bit like a "marronnier" (in French, a subject that is treated >>>> periodically >>>> by newspapers and magazines) >>> >>> Hi nicolas except that now we could a chapter describing some of the >>> answers :) >>> >> >> It's easy to make = behave as an equivalence if the two objects it >> operates on are of the same class. >> >> But it is well-known that it's hard when their classes are different, >> short of implementing = trivially in this case. >> >> This is to say that there's no real hope to make = an equivalence if the >> wish is to make it useful in the presence of different kind of objects. >> >> In the context of numeric computations, luckily, there is some hope when >> conversions, if possible at all, are all performed consistently. But the >> same conversions should then be applied for all operations, whether >> comparisons or subtractions, etc., to ensure more familiar properties. >> This is not currently the case in Pharo. >> >> >> >> Raffaello > > Personally, I rather like = being transitive across different types of > objects, which is the case with the current implementation.* > It would not be if, like you suggest, multiple Fractions = the same Float. > Take a moment to also reflect on what it would mean if, as the implication > goes, a float represents a range of numbers on the rational number line, > rather than a single point. > Taken to its logical conclusion, it follows you'd need to also redefine the > other mathematical operators to reflect this, as well as conversion to exact > numbers like Integers and Fractions being lossy, rather than the other way > around. > You could certainly build an interesting system of floats with such a > property (I can swear I've read a paper on one somewhere...), but it > wouldn't be the world of IEEE754 Floats we live in. > > Other properties one might deem beneficial, such as > a + b > a if b > 0, > or > (a + b) + c = a + (b + c) > are not true in the context of floats. Does that mean we need to fix them > too? > My 2c: It feels like you are asking Floats to be something they're not, and > the answer simply isn't to try and paint over issues and try and make them > look like something they're not. > > Cheers, > Henry > >
Personally, I could live without mixed arithmetic between unlimited and limited precision numbers: I would always be explicit in the conversions. They are so different in nature, like apples and oranges are. This also entails that I would accept that 1 = 1.0 evaluates to false, that 1 <= 1.0 throws an exception and all consequences of this. But this would be unacceptable for most Smalltalkers for many good reasons. And, as you point out, = and total ordering are easily preserved if Floats are converted to Fractions. But then please convert Floats to Fractions even when adding, multiplying, etc. To me a Float does not stand for an interval. It's just a real number that happens to have strange, unfamiliar operations that resemble the pure ones. Some familiar properties also hold for these strange operations, others do not.
