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