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 <nicolas.cellier.aka.nice@gmail.com> wrote:
2009/7/7 Ignacio Vivona <altobarba@gmail.com>:
> 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 <hernan.wilkinson@gmail.com>
>>
>> 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
>
>
>
> --
> Hope is for sissies (Gregory House, M.D.)
>
> _______________________________________________
> 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



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