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
> Anyway, as I said before, I'm not sure this change is a good
> decision, time will tell I guess, those are my two cents.
> Bye,
> Hernan
>
>
>
>
> On Tue, Jul 7, 2009 at 7:37 PM, Nicolas Cellier
> <[email protected]
> > wrote:
> 2009/7/7 Stéphane Ducasse <[email protected]>:
> >
> > On Jul 7, 2009, at 11:21 PM, Hernan Wilkinson wrote:
> >
> >> ok, but can you be sure that your objects are not handling floats?
> >> maybe the same code handles floats when you want speed and
> fractions
> >> when you want precision, I remember we did that once but I don't
> >> remember if we had to compare the numbers...
> >> I understand your point and I agree with you that erratic behavior
> >> should be avoided as much as possible, new programmers always get
> >> confused when two floats print the same but return false when
> >> compared, but do you agree with me that this new behavior make
> >> floats "less polymorphic" with numbers? and code more odd?... you
> >> see, people will have the same question as me, why (13/10) = 1.3
> >> returns false but (1/2) = 0.5 returns true?
> >> Maybe the solution has to be more drastic, and if we want to avoid
> >> people for comparing floats for equality, just not let them or
> >> return false always... or take the other road as Smalltalk had
> after
> >> now, that is: make the implementation detail as hide as possible,
> >> and if the programmer really cares about representation problems
> let
> >> him compare the numbers with a difference...
> >> Smalltalk has almost 30 years old and I have not seen any big
> >> problem related to comparing numbers, so why changing that? what do
> >> we gain with the change?... I'm still not sure that this change is
> >> for the better :-)
> >
> > :-)
> > yes I understand that point too :)
> > So please continue to discuss that we understand the deep pros and
> > cons. I think this is extremely healthy
> >
> > Stef
> >
>
> Except the polymorphism argument, this is more a principle of inertia.
> "Why did you change the browser, I want it back..."
>
> IMO, Smalltalk had not so many problems because it is not used for
> number crunching.
> Financial apps use ScaledDecimal where due and avoid the problem.
> I used it for crunching numbers, but I feel a bit alone :)
>
> Concerning polymorphism, I hope I demonstrated this is a false
> polymorphism because you get non transitive equality and numbers not
> well ordered.
>
> Anyway:
> | a b |
> a = 13/10.
> b= a asFloat.
> self assert: (a = b) ==> (a squared = b squared).
> self assert: (a = b) ==> (a fractionPart = b fractionPart).
> etc...
> They behave differently, really.
>
> Concerning (0.5) ~= (1/2) that might be a good idea.
> What stopped me was the implications it would have on inequality
> tests...
> 0.5 < (1/2). -> false
> 0.5 = (1/2). -> false
> 0.5 > (1/2). -> false
> So they are unordered... I prefer 0.5 = (1/2). -> true strategy mainly
> for this reason.
>
> Nicolas
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
