- Pharo-dev - lists.pharo.org

[Pharo-project] NaN thoughts

by Torsten Bergmann

When cleaning up things would it be useful to have infinit arithmetic too? See http://www.squeaksource.com/Infinity.html Bye Torsten -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

July 8, 2009

Re: [Pharo-project] NaN thoughts (Was: Re: Issue 940: (13/10) = 1.3 returns false)

by Andres Valloud

Well, but on the other hand, what happens when you do things like 1.0 + NaN or NaN + 1.0? It should work... Igor Stasenko wrote: > 2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > >> Would NaN be polymorphic with floats? >> >> > Do you mean , be a part of Number/Float class hierarchy? > Answer is: no. > Because NotANumber is not a number :) > > -- > Best regards, > Igor Stasenko AKA sig. > >

July 8, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

2009/7/8 danil osipchuk <danil.osipchuk(a)gmail.com>: >>> >>> I repeat here my arguments: >>> Anyone depending on (13/10) = 1.3 is plain wrong... >>> >> +1. >> I dealt with 3D rendering/linear algebra using floats in the past , >> and i can say just one: >> - never write the code which compares the floats to be equal to some >> exact value. >> It makes no sense in practice, because of inexact nature of floats. > > +1 me too > Code like '(13/10) = 1.3' just jumps at you if you have been bitten by > this before. > In languages of APL Â branch (which are traditionally used for > intensive calculations) the comparison of real numbers is 'tolerant': > that is two numbers are considered equal if their relative difference > is less than some predefined small value: > Â a = b isTrue if: Â |a-b|/max(a,b) < Epsilon > Sorry, I can't help talking :) Of course, this model does not preserve good properties like = being transitive. a := 1.0 - (0.5*Epsilon). b := 1.0. c := 1.0 + (0.5*Epsilon). self assert: (a = b) & (b = c) ==> (a = c). So I'd rather stick to a keyword selector like fuzzyEqual: Again, this definition corresponds more to an Interval arithmetic model. RealInterval >> fuzzyEqual: b ^(self intersectionWith: b) notEmpty Smalltalk has both exact (Integer/Fraction/ScaledDecimals) and inexact (Float) arithmetic, and the semantic of = will vary from exactEqual: to fuzzyEqual:. RealInterval >> exactEqual: b "always false, if a or b are inexact" ^a isExact and: [b isExact and: [a bounds exactEqual: b bounds]] RealInterval >> isExact "self is exact if Card(self) = 1" ^a bounds min exactEqual: a bounds max Don't confuse with = that could simply mean that they represent the same interval RealInterval >> = b ^a bounds exactEqual: b bounds I did not care much of polymorphism (coercion, double dispatching or whatever), but you get the idea. You can also use probability distributions if it better fits your model, but mathematical background might be a bit short... Nicolas > http://www.jsoftware.com/help/primer/tolerance.htm > http://jsoftware.com/help/dictionary/d000.htm > > Creators of these languages put a lot of considiration into this and > it I think they got it right. > It may be too radical to redefine comparison of real values in > Smalltalk (although it still makes sense to do so in practical terms) > but the discussed test is just a blind shot into a sky. The user > should be discouraged to rely on a such comparison. > > regards, > Â Danil > >> As we know, if two vectors is perpendicular, then their dot product is zero. >> But it is almost always non-zero on hardware, especially when you >> transform vectors or compute them using data, which already contains a >> degree of precision error! >> So, i learned that comparing dot product with zero makes no sense, >> instead you'd better test it with something like: >> >> abs(float) < epsilon >> where epsilon is very small number. >> >> So, i don't understand, why its so important for such kind of equality >> tests to work right at all - because you hardly will use such tests in >> practice. >> >>> 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 >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 8, 2009

Re: [Pharo-project] NaN thoughts (Was: Re: Issue 940: (13/10) = 1.3 returns false)

by Igor Stasenko

2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > Would NaN be polymorphic with floats? > Do you mean , be a part of Number/Float class hierarchy? Answer is: no. Because NotANumber is not a number :) -- Best regards, Igor Stasenko AKA sig.

July 8, 2009

Re: [Pharo-project] [OT] Google Chrome OS

by Igor Stasenko

2009/7/8 Marcus Denker <denker(a)acm.org>: > > On 08.07.2009, at 12:11, Torsten Bergmann wrote: > >> Interesting: a new OS will soon be in town >> >> http://googleblog.blogspot.com/2009/07/introducing-google-chrome-os.html >> > > "The software architecture is simple â Google Chrome running within a > new windowing system on top of a Linux kernel." > > wow. magic. > We already came a little further: SqueakNos runs on top of nothing :) Its just requires a GRUB loader, which often used by linuxes to boot their OS. > Â Â Â Â Marcus > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

July 8, 2009

Re: [Pharo-project] NaN thoughts (Was: Re: Issue 940: (13/10) = 1.3 returns false)

by Andres Valloud

Would NaN be polymorphic with floats? Igor Stasenko wrote: > Btw, Nicolas, > > in some past, i have proposed to exclude NaN from Float(s) at all by making: > NaN is a singleton instance of class NotANumber > and change all VM floating point primitives to return such singleton > in case if computation result is NaN. > > NotANumber says for itself: > > NaN isNumber == false > > What do you think about it? (Opinion of others is valuable too). > > 2009/7/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > >> 2009/7/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >>> 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 >>> >>> >> {(1/2) < 0.5. >> (1/2) = 0.5. >> (1/2) > 0.5.}. -> {false. false. false.} >> >> We cannot order these two numbers. >> Well, this will break some other expectations... Like (a >= b) = (a < b) not... >> IMO, we would be shifting the model from inexact Floating point to >> Interval arithmetic. >> Again, this is a possibility, but I'd rather see this Behaviour in a >> separate class, and let user select his own model. >> IMO we must provide traditional Floating point arithmetic reflecting >> the state of the art. >> >> Nicolas >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > . > >

July 8, 2009

[Pharo-project] [OT] Google Chrome OS

by Torsten Bergmann

>wow. magic. Thats why I've put the ";)" behind "Check the VMMaker engines" Bye Torsten -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

July 8, 2009

[Pharo-project] NaN thoughts (Was: Re: Issue 940: (13/10) = 1.3 returns false)

by Igor Stasenko

Btw, Nicolas, in some past, i have proposed to exclude NaN from Float(s) at all by making: NaN is a singleton instance of class NotANumber and change all VM floating point primitives to return such singleton in case if computation result is NaN. NotANumber says for itself: NaN isNumber == false What do you think about it? (Opinion of others is valuable too). 2009/7/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/7/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> 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 >> > > {(1/2) < 0.5. > (1/2) = 0.5. > (1/2) > 0.5.}. -> {false. false. false.} > > We cannot order these two numbers. > Well, this will break some other expectations... Like (a >= b) = (a < b) not... > IMO, we would be shifting the model from inexact Floating point to > Interval arithmetic. > Again, this is a possibility, but I'd rather see this Behaviour in a > separate class, and let user select his own model. > IMO we must provide traditional Floating point arithmetic reflecting > the state of the art. > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

July 8, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

2009/7/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > 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 > {(1/2) < 0.5. (1/2) = 0.5. (1/2) > 0.5.}. -> {false. false. false.} We cannot order these two numbers. Well, this will break some other expectations... Like (a >= b) = (a < b) not... IMO, we would be shifting the model from inexact Floating point to Interval arithmetic. Again, this is a possibility, but I'd rather see this Behaviour in a separate class, and let user select his own model. IMO we must provide traditional Floating point arithmetic reflecting the state of the art. Nicolas

July 8, 2009

Re: [Pharo-project] [OT] Google Chrome OS

by Marcus Denker

On 08.07.2009, at 12:11, Torsten Bergmann wrote: > Interesting: a new OS will soon be in town > > http://googleblog.blogspot.com/2009/07/introducing-google-chrome-os.html > "The software architecture is simple â Google Chrome running within a new windowing system on top of a Linux kernel." wow. magic. Marcus

July 8, 2009