2014-07-12 0:40 GMT+02:00 Andres Valloud <avalloud@smalltalk.comcastbiz.net>:

I don't think it makes sense to compare floating point numbers to other types of numbers with #=... there's a world of approximations and other factors hiding behind #=, and the occasional true answer confuses more than it helps. ��On top of that, then you get x = y => x hash = y hash, and so the hash of floating point values "has" to be synchronized with integers, fractions, scaled decimals, etc... _what a mess_...

Yes, that's true, hash gets more complex.

But then, this has been discussed before:

{1/2 < 0.5. 1/2 = 0.5. 1/2 > 0.5} - > #(false false false).

IOW, they are unordered.

Are we ready to lose ordering of numbers?

Practically, this would have big impacts on code base.
I'm pretty sure a Squeak/Pharo image wouldn't survive that long to such a change

(well I tried it, the Pharo3.0 image survives, but Graphics are badly broken as I expected).

That's allways what made me favour casual equality to universal inequality.

Also should 0.1 = 0.1 ? In case those two floats have been produced by different path, different approximations they might not be equal...

(| a b | a := 0.1. b := 1.0e-20. a+b=a.)

I also prefer casual equality there too.

Those two mathematical expressions a+b and a are different but both floating point expressions share same floating point approximation, that's all what really counts because in the end, we cannot distinguish an exact from an inexact Float, nor two inexact Float.

We lost the history...

Also, the inexact flag is not attached to a Float, it's only the result of an operation.
Statistically, it would waste one bit for nothing, most floats are the result of an inexact operation.

But who knows, both might be the result of exact operations too ;)

��

On 7/11/14 10:46 , stepharo wrote:

I suggest you to read the Small number chapter of the Deep into Pharo.

Stef

On 11/7/14 15:53, Natalia Tymchuk wrote:

Hello.
��I found interesting thing:
Why it is like this?

Best regards,
Natalia