July 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] FFI problem

by Mariano Martinez Peck

On Tue, Jul 7, 2009 at 10:04 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > Mariano Martinez Peck wrote: > >> Andreas: can you see new comments here: >> http://code.google.com/p/pharo/issues/detail?id=908 >> >> What do you think? >> > > Close, but not quite right ;-) The problem with your theory is that > Smalltalk recreateSpecialObjectsArray is specifically called from a > postscript in FFI-Kernel so there shouldn't be a problem with it. > > Unless of course there is something wrong with Monticello in Pharo ... let > me see. Yup. Looks like that's it. I just added a halt to > recreateSpecialObjectsArray then used ScriptLoader loadFFI and it's just not > being called. > > It would be interesting to see if the postscript is executed when you load > the FFI on your Unix machine (the one where you said it didn't crash). Thanks Andreas. I tried in Linux and recreateSpecialObjectsArray is not called when evaluating ScriptLoader loadFFI. I attach 3 files: - FFIFirstTime.png The results of FFI tests after evaluating ScriptLoader loadFFI - FFISecondTime.png The results of executing again FFI tests - FFIAfterRecreate: The results of executing the test after evaluating recreateSpecialObjectsArray (manually). Any idea? Cheers, Mariano > > > In any case, looks like I was right and it isn't an FFI problem but rather > a problem with Monticello. The workaround with the explicit > recreateSpecialObjectsArray will work but of course any other packages that > use postscripts will likely have similar issues. > > Cheers, > - Andreas >

July 8, 2009

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

by Andres Valloud

Nicolas Cellier wrote: > Ignacio, not sure your bank handle money with inexact floating point > arithmetic... > Note that it depends on the application... if pricing is inexact, then being off by $0.01 is fine. The big issue is the confusion between "1.3" as a floating point value, and "1.3" as the scaled decimal value. Andres.

July 8, 2009

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

by Andres Valloud

>> On a more positive note, according to our current plans, VW 7.7 will >> provide vastly improved IEEE arithmetic including proper support for INF >> and NaN. >> >> Andres. >> >> > > That's good news. > Concerning NaN and Inf, I wonder if really a great idea. This > introduces all sort of complexifications in the image. > > I don't know... I wouldn't call 7.7's state complex, given what you're getting. But... I guess you'll have to be the judge of that when it comes out :). > The main point of exceptional values is to avoid interrupting FP > computations and rather introduce sparse tests at strategic points in > code. It must be viewed as an optimization. > Knowing that Smalltalk has all sort of overhead on FP computations, I > wonder if adding a isFinite test in primitives at each operation and > raising an Exception immediately rather than differed at chosen points > was not a better compromise.... > In VW, you can choose between FP primitives that fail before answering INF or NaN, or primitives that will give you whatever the FPU says. This decision can be made at runtime. The default is the legacy behavior of prims that fail before answering INF or NaN. Andres.

July 8, 2009

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

by Nicolas Cellier

Ignacio, not sure your bank handle money with inexact floating point arithmetic... ScaledDecimal are made for that. When they want to "round" your account, they have more efficient rules (like the one named 'Frais Bancaires' in France). Such rules are more predictable and rarely with fractions but rather integer numbers of â¬, always negative ;) This apart, I personnally did not choose to sacrifice anything. Your hardware did this well before I put my hands on a keyboard. I think you mis-understand the point. I'm waiting the answer why 1.3*1.3 is different from 169/100. When you'll have discovered this, we'll talk about 13/10 = 1.3 on more serious bases. Nicolas 2009/7/8 Ignacio Vivona <altobarba(a)gmail.com>: > In school teachers told me that 13/10 = 1.3, applications that handle money > believe the same (at least the ones that i worked on) and then we have to > use some other implementation of numbers because the 3d guys (i also coded > some 3d stuff in C) and the speed guys want the default numbers to be fast > and inaccurate. Why not the opposite? If you want speed and you are willing > to sacrifices presition then use the implementation alternative. > > On Tue, Jul 7, 2009 at 9:43 PM, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net> wrote: >> >> The VW tests use something along the lines of >> >> self assert: aResult isWithin: anInteger ulpsFrom: anExpectedValue >> >> Igor Stasenko wrote: >> > As a compromise, >> > i propose adding: >> > >> > Float>>isAlmostZero >> > Â ^ self abs < Epsilon >> > >> > >> > And write tests like: >> > >> > (13/10) = 1.3 >> > >> > in form: >> > >> > ((13/10) - 1.3) isAlmostZero >> > >> > -- >> > 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 > > > > -- > Hope is for sissies (Gregory House, M.D.) > > _______________________________________________ > 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] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > >> Il y a mÃªme une infinitÃ© de Fractions r telles que >> f-0.5*ulp < r < f+0.5ulp >> >> > > Yes... find two with small integer numerators and denominators... bonus > points if you find fractions with small smallIntegers, too. > >> Anyway, Andres, tell me what how you can bear this VW behaviour I >> exposed to Michael L.S. >> >> 9.9999730e20 printString -> '1.0e21' >> 9.9999731e20 printString -> '9.99997e20' >> 9.9999731e20 >= 9.9999730e20. false >> >> To me, this is a clear violation of ISO/IEC 10967-2 >> http://www.cs.chalmers.se/~kent/ISOStandards/SC22/WG11/LIA-2/N424.ps >> I guess "we Smalltalk guys are smarter and did not change things for >> 30 years, so why bother now" is our best argument :) >> > > I don't know what the deal is with that. Â However, I am not surprised > that relying on print strings for floating point numbers leads to bogus > results. > I was trying to attack printString based on (log: 10) rounding error, but that is not the main problem. The main problem is 9.9999731e20 < 9.9999730e20: decimal->binary conversion is not monotonic. > On a more positive note, according to our current plans, VW 7.7 will > provide vastly improved IEEE arithmetic including proper support for INF > and NaN. > > Andres. > That's good news. Concerning NaN and Inf, I wonder if really a great idea. This introduces all sort of complexifications in the image. The main point of exceptional values is to avoid interrupting FP computations and rather introduce sparse tests at strategic points in code. It must be viewed as an optimization. Knowing that Smalltalk has all sort of overhead on FP computations, I wonder if adding a isFinite test in primitives at each operation and raising an Exception immediately rather than differed at chosen points was not a better compromise.... I guess the clients decide anyway... Will FP exceptions be programmable? > _______________________________________________ > 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] Issue 940: (13/10) = 1.3 returns false

by Ignacio Vivona

In school teachers told me that 13/10 = 1.3, applications that handle money believe the same (at least the ones that i worked on) and then we have to use some other implementation of numbers because the 3d guys (i also coded some 3d stuff in C) and the speed guys want the default numbers to be fast and inaccurate. Why not the opposite? If you want speed and you are willing to sacrifices presition then use the implementation alternative. On Tue, Jul 7, 2009 at 9:43 PM, Andres Valloud < avalloud(a)smalltalk.comcastbiz.net> wrote: > The VW tests use something along the lines of > > self assert: aResult isWithin: anInteger ulpsFrom: anExpectedValue > > Igor Stasenko wrote: > > As a compromise, > > i propose adding: > > > > Float>>isAlmostZero > > ^ self abs < Epsilon > > > > > > And write tests like: > > > > (13/10) = 1.3 > > > > in form: > > > > ((13/10) - 1.3) isAlmostZero > > > > -- > > 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 > -- Hope is for sissies (Gregory House, M.D.)

July 8, 2009

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

by Andres Valloud

The VW tests use something along the lines of self assert: aResult isWithin: anInteger ulpsFrom: anExpectedValue Igor Stasenko wrote: > As a compromise, > i propose adding: > > Float>>isAlmostZero > ^ self abs < Epsilon > > > And write tests like: > > (13/10) = 1.3 > > in form: > > ((13/10) - 1.3) isAlmostZero > > -- > 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

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

by Andres Valloud

> Il y a mÃªme une infinitÃ© de Fractions r telles que > f-0.5*ulp < r < f+0.5ulp > > Yes... find two with small integer numerators and denominators... bonus points if you find fractions with small smallIntegers, too. > Anyway, Andres, tell me what how you can bear this VW behaviour I > exposed to Michael L.S. > > 9.9999730e20 printString -> '1.0e21' > 9.9999731e20 printString -> '9.99997e20' > 9.9999731e20 >= 9.9999730e20. false > > To me, this is a clear violation of ISO/IEC 10967-2 > http://www.cs.chalmers.se/~kent/ISOStandards/SC22/WG11/LIA-2/N424.ps > I guess "we Smalltalk guys are smarter and did not change things for > 30 years, so why bother now" is our best argument :) > I don't know what the deal is with that. However, I am not surprised that relying on print strings for floating point numbers leads to bogus results. On a more positive note, according to our current plans, VW 7.7 will provide vastly improved IEEE arithmetic including proper support for INF and NaN. Andres.

July 8, 2009

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

by Nicolas Cellier

2009/7/8 Igor Stasenko <siguctua(a)gmail.com>: > As a compromise, > i propose adding: > > Float>>isAlmostZero > Â ^ self abs < Epsilon > > > And write tests like: > > (13/10) = 1.3 > > in form: > > ((13/10) - 1.3) isAlmostZero > Yes, there is already #closeTo: with an arbitrary tolerance (absolute or relative, depending if an operand isZero) and some weird side effects: 1.0 closeTo: (10 raisedTo: 310). -> true > -- > 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

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

by Igor Stasenko

As a compromise, i propose adding: Float>>isAlmostZero ^ self abs < Epsilon And write tests like: (13/10) = 1.3 in form: ((13/10) - 1.3) isAlmostZero -- Best regards, Igor Stasenko AKA sig.

July 8, 2009