2017-11-10 1:18 GMT+01:00 <raffaello.giulietti@lifeware.ch>:
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.
It would be tempting, but a priori I don't believe it would be sustainable. What is nice in Smalltalk is that we can just try. (a bit less easy for int+float because it's hardwired in the primitives and maybe the JIT too)
So in current Pharo, if I just define Fraction>>adaptToFloat: f andSend: m ^f isFinite ifTrue: [f asFraction perform: m with: self] ifFalse: [f perform: m with: self asFloat] and symmetric in Float>>adaptToFraction: f andSend: m ^self isFinite ifTrue: [f perform: m with: self asFraction] ifFalse: [f asFloat perform: m with: self] then World does not seem to fall apart... We would need to measure if noticeable slow down happens