2017-11-10 0:02 GMT+01:00 Henrik Sperre Johansen < [email protected]>:
> 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-J > uly/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 > > on the other hand, his original expectations are true when restricted in the world of floating point: (a isFloat & b isFloat & a isFinite & b isFinite) ==> (a-b)=0 = (a=b) so the astonishment is legitimate It's just that we have a more complex model in which above Smalltalk expression cannot hold with mixed arithmetic without breaking higher expectations... > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >
