Hi Nicolas,
�thank you for your answer. I'm aware of the float representation problems. But this new behavior sounds more confusing, at least to me... I mean, 1.3 is not a number with representation problems so why do we have to make this difference? I understand you are trying to avoid the problems sometimes floats generate, but I think that doing so we are loosing some abstraction from the number representation type.
� Correct me if I wrong, but doesn't this new behavior means that always, in any number comparison, we need to coerse the number to float? Because 1.3 asFraction = (13/10) returns false but 1.3 = (13/10) asFloat returns true... I mean, if we have a = b and the values of those variables are calculated by some process such that a is 1.3 and b is 13/10, the comparison will not work, so we need to explicitly write "a asFloat = b asFloat" just in case any of those variables reference a float, even though none of them will ever do... but then "(1/2) = 0.5" returns true... I don't know, I don't like it that much...
On Tue, Jul 7, 2009 at 3:56 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Hernan,
This is the new Behavior of Float comparison and it is desired.
1) 1.3 is represented in machine as
(1.3 significandAsInteger printStringRadix: 2) , '.0e' , (1.3 exponent
- Float precision + 1) printString.
-> '2r10100110011001100110011001100110011001100110011001101.0e-52'
Or if you prefer:
(1.3 asTrueFraction numerator printStringBase: 2) , '/' , (1.3
asTrueFraction denominator printStringBase: 2).
-> '10100110011001100110011001100110011001100110011001101/10000000000000000000000000000000000000000000000000000'
As you can see, this is quite different from 13/10.
However, you can test (13/10) asFloat = 1.3 and that happens to be
true, but that won't always be true.
2) comparing Float with strict equality is a dangerous game. Floating
point operation are inherently inexact and thus asserting an exact
equality is considered a bad practice.
3) basing comparisons and equality tests on inexact arithmetic rather
than on exact arithmetic leads to weird behaviours. See
http://bugs.squeak.org/view.php?id=3374
So i do not consider this fragment of code alone as a bug but as a feature.
There might be some code depending on the old behaviour that can
eventually break.
If you have such an example in true application, I'm interested.
I think we'd better fix such code to not rely on exact equality...
Cheers.
Nicolas
2009/7/7 Hernan Wilkinson <hernan.wilkinson@gmail.com>:
> _______________________________________________> I added this new issue that happens on the latest image.
> I'm posting it here because I think it is an important bug because it
> affects the number model.
> The problem is related with all fractions who's denominator is not power of
> two. (130/100 = 1.3 or 1/5 = 0.2, etc)
> (See
>
> Float>>adaptToFraction: rcvr andCompare: selector where it does
> � �....
> � �"Try to avoid asTrueFraction because it can cost"
> � � selector == #= ifTrue: [
> � � � rcvr denominator isPowerOfTwo ifFalse: [^false]].
>
> � �...)
>
>
> Hernan.
>
>
>
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project