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 -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
