2009/7/8 Stéphane Ducasse <[email protected]>:
>
> On Jul 8, 2009, at 4:07 AM, Hernan Wilkinson wrote:
>
>> ok, let me start again.
>> 1) I created the issue because 13/10 = 1.3 works different in the
>> new pharo image that in vw, va, dolphin, squeak and the previous
>> pharo version, so I thought it was a bug
>> 2) I understand that comparing floats is not good and I also
>> understand the representation problems of floats
>> 3) I'm in favor of making changes. Changes are needed to make
>> progress although not all changes make progress
>>
>> But, Nicolas when you say
>> > Anyone depending on (13/10) = 1.3 is plain wrong...
>> I do not completely agree. You say that because you are thinking
>> like a programmer and you know that 1.3 is a float, but if you ask
>> the same question to an accountant, engineering, etc. they will say
>> that 13/10 is equal to 1.3. So, outside computers, 13/10 is equal to
>> 1.3, the same as 1/2 equals to 0.5 and so on.
>> Dan Ingalls followed a good design principle: to hide as much as
>> possible implementation details from the user and that is why
>> Smalltalk has such a great Number model that I did not see in
>> another language.
>> From my point of view, the implementation you are providing is not
>> quite following this principle or at least is making the float
>> representation problem more evident. If the last is the intention, I
>> think it should be consistent (i.e. 1/2 = 0.5 should return false
>> also) and provide specific messages to handle that decision too.
>> Or maybe the change has to be more profound, maybe changes like the
>> one suggested by Michael van der Gulik
>> are necessary, maybe we have to print ScaledDecimals as float are
>> printed now and print floats with a special representation to make
>> evident that is not a "normal" number...
>
> May be this would be good in fact.
>
> I was wondering why we could not have
> = comparison always been false?
>
> Stef
>
{(1/2) < 0.5.
(1/2) = 0.5.
(1/2) > 0.5.}. -> {false. false. false.}
We cannot order these two numbers.
Well, this will break some other expectations... Like (a >= b) = (a < b) not...
IMO, we would be shifting the model from inexact Floating point to
Interval arithmetic.
Again, this is a possibility, but I'd rather see this Behaviour in a
separate class, and let user select his own model.
IMO we must provide traditional Floating point arithmetic reflecting
the state of the art.
Nicolas
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
