Issue 940: (13/10) = 1.3 returns false

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
81 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Issue 940: (13/10) = 1.3 returns false

hernan.wilkinson
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Nicolas Cellier
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 <[hidden email]>:

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Nicolas Cellier
Oh, just something I forgot to mention:

ScaledDecimal should behave the way you expect.

1.3s1 = (13/10).
-> true.

1.3s2*1.3s2 = 1.69s2.
-> true
1.3 * 1.3 = 1.69.
-> false

Nicolas

2009/7/7 Nicolas Cellier <[hidden email]>:

> 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 <[hidden email]>:
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

hernan.wilkinson
In reply to this post by Nicolas Cellier
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 <[hidden email]> 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 <[hidden email]>:
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Ignacio Vivona-2
Why not the opposite? The default behavior is 13/10 = 1.3 yields true and the new behavior (13/10) asFloat = 1.3 equals false.
This kind of behavior is a real pain in languages like java, i are you bringing this to the smalltalk world?

2009/7/7 Hernan Wilkinson <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>:
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
Hope is for sissies (Gregory House, M.D.)

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Nicolas Cellier
In reply to this post by hernan.wilkinson
IMO no one should rely on (13/10) = 1.3, not even on (13/10) asFloat = 1.3.
Once you introduced a Float, you'd better forget about exact equality.

Do you expect 1.3*1.3 ~= 1.69 ?
I think it's better like this, because you learn to not overtrust
Float equality.
You learn quicker that you should not rely on it.

However if you give me real examples where this behaviour matters, my
ears and eyes are wide open.

cheers

Nicolas


P.S. there is an even more extreme solution: (1/2) ~= 0.5 because an
exact and an inexact representation cannot be compared exactly.

2009/7/7 Hernan Wilkinson <[hidden email]>:

> 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
> <[hidden email]> 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 <[hidden email]>:
>> > 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
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Nicolas Cellier
In reply to this post by Ignacio Vivona-2
2009/7/7 Ignacio Vivona <[hidden email]>:
> Why not the opposite? The default behavior is 13/10 = 1.3 yields true and
> the new behavior (13/10) asFloat = 1.3 equals false.
> This kind of behavior is a real pain in languages like java, i are you
> bringing this to the smalltalk world?
>

Hi Ignacio.
If you'd provide a rationale for the behaviour you're proposing we could argue.
Otherwise my answer would just be speculation.

If 1.3 is 13/10 explain why 1.3*1.3 is not 169/100.

As I told before, you should better use ScaledDecimals if you rely on
such assertions.

Cheers

Nicolas

> 2009/7/7 Hernan Wilkinson <[hidden email]>
>>
>> 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
>> <[hidden email]> 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 <[hidden email]>:
>>> > 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
>>> > [hidden email]
>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>> >
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>
> --
> Hope is for sissies (Gregory House, M.D.)
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Ignacio Vivona-2
The float problem is an implementation problem that i really dont care, i only want fast float operations when doing heavy calculation or 3D or something like that ... 1.3 should gimme an object modeling a real number

On Tue, Jul 7, 2009 at 5:26 PM, Nicolas Cellier <[hidden email]> wrote:
2009/7/7 Ignacio Vivona <[hidden email]>:
> Why not the opposite? The default behavior is 13/10 = 1.3 yields true and
> the new behavior (13/10) asFloat = 1.3 equals false.
> This kind of behavior is a real pain in languages like java, i are you
> bringing this to the smalltalk world?
>

Hi Ignacio.
If you'd provide a rationale for the behaviour you're proposing we could argue.
Otherwise my answer would just be speculation.

If 1.3 is 13/10 explain why 1.3*1.3 is not 169/100.

As I told before, you should better use ScaledDecimals if you rely on
such assertions.

Cheers

Nicolas

> 2009/7/7 Hernan Wilkinson <[hidden email]>
>>
>> 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
>> <[hidden email]> 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 <[hidden email]>:
>>> > 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
>>> > [hidden email]
>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>> >
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>
> --
> Hope is for sissies (Gregory House, M.D.)
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
Hope is for sissies (Gregory House, M.D.)

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

johnmci
In reply to this post by hernan.wilkinson
Let me step back and say, ok you are possibly breaking existing code,  
and causing all sorts of confusion for an
optimization change?  So where is the justification from the  
optimization viewpoint? Does it make browser
windows open in 1/2 the time?

If it takes more time milliseconds? to produce an answer that is what  
people expect, then t I think it's worth it.
Yes I understand that floats are inexact but people think they know  
how they work thus expect to be able to say
(13/10) = 1.3   without having to give clues with asFloat to indicate  
their intent.

Let me see
squeak 3.10.x   (13/10) = 1.3   true
Pharo 1037  (13/10) = 1.3   false
VisualWorks (13/10) = 1.3   true

I would classify this as a bug


On 7-Jul-09, at 10:43 AM, Hernan Wilkinson wrote:

> 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.

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Nicolas Cellier
In reply to this post by Ignacio Vivona-2
2009/7/7 Ignacio Vivona <[hidden email]>:
> The float problem is an implementation problem that i really dont care, i
> only want fast float operations when doing heavy calculation or 3D or
> something like that ... 1.3 should gimme an object modeling a real number
>

OK concerning fast, that's not the main talent of Squeak, but yes, it
could be worse with ScaledDecimals.

OK, an object modelling a real number, inexactly, is what you get, so
i do not see the problem.
Float representation is independant of the language and most likely
hardwired in your processor.
Whether it is exactly equal to (13/10) or not is an implementation
detail you should not bother with...
... until you try to attempt an exact equality test, but why would you?

Because you know the tradeoff is fast but inexact, you will rather use
something like (13/10) closeTo: 1.3, or better, provide your own
tolerance.
If you say you expect (13/10) = 1.3 exactly, then i say your
expectations are different: you want an exact representation, at the
price of longer computations, that's the deal.

The fact that Smalltalk let you the choose is already a great thing.

Last time I tried (13/10) == 1.3 in C, it was false :)

Nicolas

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Andres Valloud-4
In reply to this post by hernan.wilkinson
Hernan, floating point values are fractions of the form

+/- m * 2^k

for positive integers m of up to a certain number of bits.  Your example
requires

13/10 = m * 2^k

which is not possible.  In slow motion...

2^k = 13/10m

To get rid of 13, m must be 13*n...

2^k = 1/10n

Now, 1/10 = 1/5 * 1/2, so...

2^{k+1} = 1/5n

and then we reach

n 2^{k+1} = 1/5

which is absurd for integer n, k.

Andres.


Hernan Wilkinson wrote:

> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Andres Valloud-4
In reply to this post by johnmci
VisualWorks introduced LimitedPrecisionReal>>asFraction.  That message
returns the actual floating point value represented by the receiver.  Of
course, I messed up and forgot * self sign... but that's the idea (and
it's fixed for 7.7).  So, in reality, you should compare

13/10 = 1.3 asFraction

which will answer false, like it should.

Andres.


John M McIntosh wrote:

> Let me step back and say, ok you are possibly breaking existing code,
> and causing all sorts of confusion for an
> optimization change?  So where is the justification from the
> optimization viewpoint? Does it make browser
> windows open in 1/2 the time?
>
> If it takes more time milliseconds? to produce an answer that is what
> people expect, then t I think it's worth it.
> Yes I understand that floats are inexact but people think they know
> how they work thus expect to be able to say
> (13/10) = 1.3   without having to give clues with asFloat to indicate
> their intent.
>
> Let me see
> squeak 3.10.x   (13/10) = 1.3   true
> Pharo 1037  (13/10) = 1.3   false
> VisualWorks (13/10) = 1.3   true
>
> I would classify this as a bug
>
>
> On 7-Jul-09, at 10:43 AM, Hernan Wilkinson wrote:
>
>  
>> 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.
>>    
>
> --
> =
> =
> =
> ========================================================================
> John M. McIntosh <[hidden email]>   Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> =
> =
> =
> ========================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>  

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

hernan.wilkinson
In reply to this post by Nicolas Cellier
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 :-)


On Tue, Jul 7, 2009 at 5:18 PM, Nicolas Cellier <[hidden email]> wrote:
IMO no one should rely on (13/10) = 1.3, not even on (13/10) asFloat = 1.3.
Once you introduced a Float, you'd better forget about exact equality.

Do you expect 1.3*1.3 ~= 1.69 ?
I think it's better like this, because you learn to not overtrust
Float equality.
You learn quicker that you should not rely on it.

However if you give me real examples where this behaviour matters, my
ears and eyes are wide open.

cheers

Nicolas


P.S. there is an even more extreme solution: (1/2) ~= 0.5 because an
exact and an inexact representation cannot be compared exactly.

2009/7/7 Hernan Wilkinson <[hidden email]>:
> 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
> <[hidden email]> 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 <[hidden email]>:
>> > 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
>> > [hidden email]
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> >
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Stéphane Ducasse
In reply to this post by Andres Valloud-4
so andres what will be the value of
>> (13/10) = 1.3
in VW7.7

On Jul 7, 2009, at 11:18 PM, Andres Valloud wrote:

> VisualWorks introduced LimitedPrecisionReal>>asFraction.  That message
> returns the actual floating point value represented by the  
> receiver.  Of
> course, I messed up and forgot * self sign... but that's the idea (and
> it's fixed for 7.7).  So, in reality, you should compare
>
> 13/10 = 1.3 asFraction
>
> which will answer false, like it should.
>
> Andres.
>
>
> John M McIntosh wrote:
>> Let me step back and say, ok you are possibly breaking existing code,
>> and causing all sorts of confusion for an
>> optimization change?  So where is the justification from the
>> optimization viewpoint? Does it make browser
>> windows open in 1/2 the time?
>>
>> If it takes more time milliseconds? to produce an answer that is what
>> people expect, then t I think it's worth it.
>> Yes I understand that floats are inexact but people think they know
>> how they work thus expect to be able to say
>> (13/10) = 1.3   without having to give clues with asFloat to indicate
>> their intent.
>>
>> Let me see
>> squeak 3.10.x   (13/10) = 1.3   true
>> Pharo 1037  (13/10) = 1.3   false
>> VisualWorks (13/10) = 1.3   true
>>
>> I would classify this as a bug
>>
>>
>> On 7-Jul-09, at 10:43 AM, Hernan Wilkinson wrote:
>>
>>
>>> 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.
>>>
>>
>> --
>> =
>> =
>> =
>> =
>> =
>> =
>> =====================================================================
>> John M. McIntosh <[hidden email]>   Twitter:
>> squeaker68882
>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>> =
>> =
>> =
>> =
>> =
>> =
>> =====================================================================
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Nicolas Cellier
In reply to this post by johnmci
Hi John,
There is some misunderstanding here.
It just happens that I proposed an optimized implementation, but
optimizing was not my goal.
My goal was to be able to compare number exactly, that's all.

See http://bugs.squeak.org/view.php?id=3374 for funny examples of what
happens when comparison is based on inexact conversions.

Nicolas

2009/7/7 John M McIntosh <[hidden email]>:

> Let me step back and say, ok you are possibly breaking existing code,
> and causing all sorts of confusion for an
> optimization change?  So where is the justification from the
> optimization viewpoint? Does it make browser
> windows open in 1/2 the time?
>
> If it takes more time milliseconds? to produce an answer that is what
> people expect, then t I think it's worth it.
> Yes I understand that floats are inexact but people think they know
> how they work thus expect to be able to say
> (13/10) = 1.3   without having to give clues with asFloat to indicate
> their intent.
>
> Let me see
> squeak 3.10.x   (13/10) = 1.3   true
> Pharo 1037  (13/10) = 1.3   false
> VisualWorks (13/10) = 1.3   true
>
> I would classify this as a bug
>
>
> On 7-Jul-09, at 10:43 AM, Hernan Wilkinson wrote:
>
>> 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.
>
> --
> =
> =
> =
> ========================================================================
> John M. McIntosh <[hidden email]>   Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> =
> =
> =
> ========================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Stéphane Ducasse
In reply to this post by hernan.wilkinson

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

>
>
> On Tue, Jul 7, 2009 at 5:18 PM, Nicolas Cellier <[hidden email]
> > wrote:
> IMO no one should rely on (13/10) = 1.3, not even on (13/10) asFloat  
> = 1.3.
> Once you introduced a Float, you'd better forget about exact equality.
>
> Do you expect 1.3*1.3 ~= 1.69 ?
> I think it's better like this, because you learn to not overtrust
> Float equality.
> You learn quicker that you should not rely on it.
>
> However if you give me real examples where this behaviour matters, my
> ears and eyes are wide open.
>
> cheers
>
> Nicolas
>
>
> P.S. there is an even more extreme solution: (1/2) ~= 0.5 because an
> exact and an inexact representation cannot be compared exactly.
>
> 2009/7/7 Hernan Wilkinson <[hidden email]>:
> > 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
> > <[hidden email]> 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 <[hidden email]>:
> >> > 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
> >> > [hidden email]
> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >> >
> >>
> >> _______________________________________________
> >> Pharo-project mailing list
> >> [hidden email]
> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Nicolas Cellier
In reply to this post by Andres Valloud-4
Hi Andres,
That's great to see this addition, but it would have been even greater
to call this method #asExactFraction or #asTrueFraction to get some
minimal core API with other dialects...

Anyway, you see the kind of arguments you'll have to provide if you
ever want to follow the path you once proposed...

Cheers

Nicolas

2009/7/7 Andres Valloud <[hidden email]>:

> VisualWorks introduced LimitedPrecisionReal>>asFraction.  That message
> returns the actual floating point value represented by the receiver.  Of
> course, I messed up and forgot * self sign... but that's the idea (and
> it's fixed for 7.7).  So, in reality, you should compare
>
> 13/10 = 1.3 asFraction
>
> which will answer false, like it should.
>
> Andres.
>
>
> John M McIntosh wrote:
>> Let me step back and say, ok you are possibly breaking existing code,
>> and causing all sorts of confusion for an
>> optimization change?  So where is the justification from the
>> optimization viewpoint? Does it make browser
>> windows open in 1/2 the time?
>>
>> If it takes more time milliseconds? to produce an answer that is what
>> people expect, then t I think it's worth it.
>> Yes I understand that floats are inexact but people think they know
>> how they work thus expect to be able to say
>> (13/10) = 1.3   without having to give clues with asFloat to indicate
>> their intent.
>>
>> Let me see
>> squeak 3.10.x   (13/10) = 1.3   true
>> Pharo 1037  (13/10) = 1.3   false
>> VisualWorks (13/10) = 1.3   true
>>
>> I would classify this as a bug
>>
>>
>> On 7-Jul-09, at 10:43 AM, Hernan Wilkinson wrote:
>>
>>
>>> 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.
>>>
>>
>> --
>> =
>> =
>> =
>> ========================================================================
>> John M. McIntosh <[hidden email]>   Twitter:
>> squeaker68882
>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>> =
>> =
>> =
>> ========================================================================
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Nicolas Cellier
In reply to this post by johnmci
2009/7/7 John M McIntosh <[hidden email]>:

> Let me step back and say, ok you are possibly breaking existing code,
> and causing all sorts of confusion for an
> optimization change?  So where is the justification from the
> optimization viewpoint? Does it make browser
> windows open in 1/2 the time?
>
> If it takes more time milliseconds? to produce an answer that is what
> people expect, then t I think it's worth it.
> Yes I understand that floats are inexact but people think they know
> how they work thus expect to be able to say
> (13/10) = 1.3   without having to give clues with asFloat to indicate
> their intent.
>
> Let me see
> squeak 3.10.x   (13/10) = 1.3   true
> Pharo 1037  (13/10) = 1.3   false
> VisualWorks (13/10) = 1.3   true
>
> I would classify this as a bug
>
>

I repeat here my arguments:
Anyone depending on (13/10) = 1.3 is plain wrong...

Either you want fast and inexact floating point operation and should
not rely on exact equality (use #closeTo:).
Or you want (13/10) = 1.3 EXACTLY, and then should better use ScaledDecimal.
That's the deal, and it's quite independant from the language.

The false assertions that people are trying to push does not matter:
it's high time to educate.
My proposition has at least the merit to put a light on these
dangerous floating point strict equality tests
(I saw so many bugs like testing cos(pi/2) == 0).

And I'm still waiting for the hypothetical application that would
break because of this change.
That's the main point of interest.
In this case, we'll see if patching is necessary and easy.

Nicolas

P.S. concerning behaviour of conversion binary<->decimal
representation, I'm rather the one trying to unify Smalltalk.
Dolphin, gst and Pharo adopted some of my changes to behave as exactly
as we can, and thus behave the same.
Try this in your prefered dialect, I guess you will have some surprise.
123.4567890123d3 = (1234567890123/10000000).
123.4567890123d3 = (1234567890123/10000000) asFloat.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Andres Valloud-4
In reply to this post by Stéphane Ducasse
The answer is true on 7.6, and I don't think anything changed that for
7.7.  Historical background aside, I think it's wrong anyway... in the
hash book, exercise 7.20 asks to find two different fractions that are
equal to the same float.  In other words, if f is a float, and r1 and r2
are fractions, then r1 ~= r2 but r1 = f and r2 = f.  And those do exist...

Andres.


Stéphane Ducasse wrote:

> so andres what will be the value of
>  
>>> (13/10) = 1.3
>>>      
> in VW7.7
>
> On Jul 7, 2009, at 11:18 PM, Andres Valloud wrote:
>
>  
>> VisualWorks introduced LimitedPrecisionReal>>asFraction.  That message
>> returns the actual floating point value represented by the
>> receiver.  Of
>> course, I messed up and forgot * self sign... but that's the idea (and
>> it's fixed for 7.7).  So, in reality, you should compare
>>
>> 13/10 = 1.3 asFraction
>>
>> which will answer false, like it should.
>>
>> Andres.
>>
>>
>> John M McIntosh wrote:
>>    
>>> Let me step back and say, ok you are possibly breaking existing code,
>>> and causing all sorts of confusion for an
>>> optimization change?  So where is the justification from the
>>> optimization viewpoint? Does it make browser
>>> windows open in 1/2 the time?
>>>
>>> If it takes more time milliseconds? to produce an answer that is what
>>> people expect, then t I think it's worth it.
>>> Yes I understand that floats are inexact but people think they know
>>> how they work thus expect to be able to say
>>> (13/10) = 1.3   without having to give clues with asFloat to indicate
>>> their intent.
>>>
>>> Let me see
>>> squeak 3.10.x   (13/10) = 1.3   true
>>> Pharo 1037  (13/10) = 1.3   false
>>> VisualWorks (13/10) = 1.3   true
>>>
>>> I would classify this as a bug
>>>
>>>
>>> On 7-Jul-09, at 10:43 AM, Hernan Wilkinson wrote:
>>>
>>>
>>>      
>>>> 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.
>>>>
>>>>        
>>> --
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =====================================================================
>>> John M. McIntosh <[hidden email]>   Twitter:
>>> squeaker68882
>>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =====================================================================
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>>      
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>    
>
> .
>
>  

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Issue 940: (13/10) = 1.3 returns false

Andres Valloud-4
In reply to this post by Nicolas Cellier
On the other hand, VW already has asRational, and it doesn't do what
asFraction does.  To some extent, I think #asExactFraction and selectors
like that are misleading.  Why would anyone want #asImpreciseFraction,
or #asRationalMoreOrLess...

Nicolas Cellier wrote:

> Hi Andres,
> That's great to see this addition, but it would have been even greater
> to call this method #asExactFraction or #asTrueFraction to get some
> minimal core API with other dialects...
>
> Anyway, you see the kind of arguments you'll have to provide if you
> ever want to follow the path you once proposed...
>
> Cheers
>
> Nicolas
>
> 2009/7/7 Andres Valloud <[hidden email]>:
>  
>> VisualWorks introduced LimitedPrecisionReal>>asFraction.  That message
>> returns the actual floating point value represented by the receiver.  Of
>> course, I messed up and forgot * self sign... but that's the idea (and
>> it's fixed for 7.7).  So, in reality, you should compare
>>
>> 13/10 = 1.3 asFraction
>>
>> which will answer false, like it should.
>>
>> Andres.
>>
>>
>> John M McIntosh wrote:
>>    
>>> Let me step back and say, ok you are possibly breaking existing code,
>>> and causing all sorts of confusion for an
>>> optimization change?  So where is the justification from the
>>> optimization viewpoint? Does it make browser
>>> windows open in 1/2 the time?
>>>
>>> If it takes more time milliseconds? to produce an answer that is what
>>> people expect, then t I think it's worth it.
>>> Yes I understand that floats are inexact but people think they know
>>> how they work thus expect to be able to say
>>> (13/10) = 1.3   without having to give clues with asFloat to indicate
>>> their intent.
>>>
>>> Let me see
>>> squeak 3.10.x   (13/10) = 1.3   true
>>> Pharo 1037  (13/10) = 1.3   false
>>> VisualWorks (13/10) = 1.3   true
>>>
>>> I would classify this as a bug
>>>
>>>
>>> On 7-Jul-09, at 10:43 AM, Hernan Wilkinson wrote:
>>>
>>>
>>>      
>>>> 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.
>>>>
>>>>        
>>> --
>>> =
>>> =
>>> =
>>> ========================================================================
>>> John M. McIntosh <[hidden email]>   Twitter:
>>> squeaker68882
>>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>>> =
>>> =
>>> =
>>> ========================================================================
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>>      
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>    
> .
>
>  

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
12345