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.