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

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

by David Goehrig

On Wed, Jul 8, 2009 at 5:30 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > I guess you gonna miss pretty soon those imperfect inexact Float of > the unreasonnable people. > Nicolas please read what I wrote: If you're defining the default behavior of numbers in the system, the principle of "thou shall not commit premature optimization" should come into play. If you're that desperately in need of floating point speed, you're also probably capable of applying that and other optimization techniques accordingly, as befits your problem. The case of the core drawing engine is a special case. You would optimize this case specially, knowing full well that it is a critical system loop that affects the performance of everything else. But turning around and saying that because this core loop requires optimization, that this optimization technique should be the default is a total non sequitur. One special case does not define what the general case should be. When making a fundamental design decision as to what a sane default is, you need to look at what the non-expert using the system will expect. Saying that "you should know IEEE 754 float math" isn't helpful. Skilled professionals make mistakes with floating point math every day. Telling a child in grammar school that their program doesn't work because they don't understand IEEE 754 math is equally absurd. Design decisions should not be driven by implementation optimization requirements. Doing so only places the incidental preferences of the system implementors over the needs of those who will use it. Dave -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/

July 9, 2009

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

by Hernan Wilkinson

> Â Then, people will ask "why does > my algorithm give result x when written in C, but y when written in > Squeak?". It happens already... :-) > > Hernan Wilkinson wrote: >> >> >> >> Â Â > [...] and if you write 1.3, the object that represents that number >> Â Â > is not going to be an instance of float but of scaledecimal or >> Â Â > fraction or whatever, but not float... >> >> Â Â That only solves the issue of representing literals because: >> >> >> Â Â > and all operations are made with exact representation. >> >> >> >> Â Â cannot be done for all operations: obvious ones like square root, log, >> Â Â sin, etc and less obvious ones like #squared where you run out of >> Â Â enough bits to maintain precision (in fixed-width implementations). >> >> >> not really... root, log, sin, etc could be messages that only inexact >> numbers know how to answer , so you want "2 sqrt", Â do "2 asFloat >> sqrt", but for +, *, /, etc. they work as expected. >> We can also have better representations for number like pi. Why pi is >> instance of Float and not Pi? If pi is instance of Pi, then cos(pi/2) >> = 0 could be true... just a quick hack: >> Pi>>/ aNumber >> >> Â ^ Fraction numerator: self denominator: aNumber Â "Or maybe an object >> representing that Pi has been divided/multiplied, etc >> >> Fraction>>cos >> >> Â ^ numerator cosDividedWith: denominator >> >> Pi>>cosDividedWith: denominator >> >> Â ^denominator = 2 ifTrue: [ 0 ] ifFalse: [ ... ] >> >> and so on >> >> >> >> >> Â Â R >> Â Â - >> >> >> Â Â _______________________________________________ >> Â Â Pharo-project mailing list >> Â Â Pharo-project(a)lists.gforge.inria.fr >> Â Â <mailto:Pharo-project@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] Tests

by Michael Roberts

yes i will do. just a bit busy ;-) but it's great to see a bunch of new tests in the image. I will post my scripts onto the wiki and perhaps someone can review for inclusion in the image - needs a bit of work. i would like a single click that writes out the test run in google wiki format then anyone can upload baseline results. we could then host this on a server somewhere etc.... cheers mike On Mon, Jul 6, 2009 at 9:26 PM, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: > Yes mike so if you can check that it would just great. > > On Jul 6, 2009, at 7:44 PM, Michael Roberts wrote: > >> Sure it's a good thing. We should make sure our test output is telling >> the truth.,... >> Mike >> On Monday, July 6, 2009, Damien Cassou <damien.cassou(a)gmail.com> >> wrote: >>> On Sun, Jul 5, 2009 at 12:36 PM, Adrian Lienhard<adi(a)netstyle.ch> >>> wrote: >>>> Running the tests in the latest core (10371), I get the following >>>> results: >>>> 5154 run, 5133 passes, 2 expected failures, 17 failures, 2 errors >>>> >>>> Comparing to the last result in 10292cl [1]: >>>> 3029 run, 2956 passes, 2 expected failures, 24 failures, 47 errors >>>> >>>> >>>> I wonder how it is possible to get from 3029 to 5154 tests? >>> >>> More tests, less problems, why do you care? :-) > > > _______________________________________________ > 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] doing bad things to Dictionaries.

by Michael Roberts

ok well the context wasn't clear to be honest. Best thing to do is to create an issue on the tracker and try and describe a test case for invoking the problem. This is in preference to just patching code that doesn't look right. thanks, Mike 2009/7/8 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > It certainly is not a generally applicable methodÂ for DictionaryÂ (not > all/most keys will not understand #beginsWith:), but for some senders, it > might make sense, as it (I think)Â does for SystemDictionary.Â Â It would > bother me lessÂ as a loose method packaged as part of something that "needs" > it, but I would be inclined to deprecate/clean it if it is intended as part > of the collection protocol.Â Clients/senders could always define something > like #dictionary:hasKeyBeginningWith:. > > One of the great things about Smalltalk is the ability to add methods to > system classes.Â This is probably not the best use of that freedom.Â Has > this been of _any_ help? :) > > Bill > > > ________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David > Goehrig > Sent: Wednesday, July 08, 2009 12:33 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] doing bad things to Dictionaries. > > On Wed, Jul 8, 2009 at 1:06 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: >> >> Why do you assume all keys of dictionarys understand beginsWith: ? > > I don't. Someone else did. Â I just added a nil check to the code. Â There's > probably bigger issues with this code. > Dave > > -- > -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ > > _______________________________________________ > 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

This kind of approach will introduce discontinuity problems when the FPU is asked to calculate sin(x) when x is close to zero... IME, most platforms offer a different answer to that kind of stuff. IIRC, SGI was the only platform I found with "natural" tan(x) behavior. If you introduce "better" behavior, then the work somebody else did to ensure smoothness of results could be broken. Then, people will ask "why does my algorithm give result x when written in C, but y when written in Squeak?". Hernan Wilkinson wrote: > > > > > [...] and if you write 1.3, the object that represents that number > > is not going to be an instance of float but of scaledecimal or > > fraction or whatever, but not float... > > That only solves the issue of representing literals because: > > > > and all operations are made with exact representation. > > > > cannot be done for all operations: obvious ones like square root, log, > sin, etc and less obvious ones like #squared where you run out of > enough bits to maintain precision (in fixed-width implementations). > > > not really... root, log, sin, etc could be messages that only inexact > numbers know how to answer , so you want "2 sqrt", do "2 asFloat > sqrt", but for +, *, /, etc. they work as expected. > We can also have better representations for number like pi. Why pi is > instance of Float and not Pi? If pi is instance of Pi, then cos(pi/2) > = 0 could be true... just a quick hack: > Pi>>/ aNumber > > ^ Fraction numerator: self denominator: aNumber "Or maybe an object > representing that Pi has been divided/multiplied, etc > > Fraction>>cos > > ^ numerator cosDividedWith: denominator > > Pi>>cosDividedWith: denominator > > ^denominator = 2 ifTrue: [ 0 ] ifFalse: [ ... ] > > and so on > > > > > R > - > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@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

David Goehrig wrote: > IEEE754 run contrary to all of my 18 years of sudying math and using > rational numbers. I find that a bit difficult to accept because numerical analysis courses in colleges and universities describe floating point arithmetic as a basis for the material. Really: without knowing how floating point arithmetic works, then it's going to be considerably harder to do applied math work. Also, I don't see how anybody could mount an argument against floating point arithmetic on math grounds when e.g.: Knuth devotes a significant number of pages of The Art of Computer Programming to them. Not to say that Knuth has to be right, but... Andres.

July 8, 2009

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

by Nicolas Cellier

Dave, I certainly share your opinion about these german discussions. They are ridiculous indeed. But then mathematics are ridiculous too. Who cares about maths in real life? And IT, except among these circles of geeks, common, isn't it a wonderful way to waste our time? In squeak kernel, it happens that floats are used in graphics (and sounds but who cares) Not sure the optimization is premature but yes, we don't need them: we have a rectangular grid of pixels after all, so the most elementary Morphic geometry problem that don't have a solution in Q as you might have learned in your 18 years of studying math, will have an approximate solution in Q, and that's what we are interested in to just draw a Form. Now I challenge you to solve all these little geometry problem in integer arithmetic and remove Float from a Squeak image. If brave enough, you can attempt to use the AlgebraicNumber from MathMorph, just for beauty, then approximate with a Fraction and let BitBlt round to the nearest pixel at the end. I guess you gonna miss pretty soon those imperfect inexact Float of the unreasonnable people. Then you will realize that these pixels are just hardware detail and that you should better work at a higher level where you need those algebraic and other irrational numbers. Unfortunately, even if you manage to create a beautiful computer algebra system with exact representation of these mathematical beings, it will still be a pain to descend to hardware. Of course, if you just want to use your math strength to add decimal numbers, as your examples show, that's were these ScaledDecimal fit perfectly. If you just want to tell every body to use ScaledDecimal where they expect ScaledDecimal, that's a good point, and I join my voice. But if you consider Float are unecessary optimizations except for some engineers like me, I can't agree. You must be using Squeak in console mode ;) Nicolas 2009/7/8 David Goehrig <dave(a)nexttolast.com>: > I love these sorts of ridiculous > arguments,Â becauseÂ theÂ problemÂ isÂ fundamentallyÂ aÂ questionÂ ofÂ design. > DoÂ youÂ design accountingÂ forÂ theÂ expectationsÂ ofÂ reasonableÂ people, or do > you design for programmers :) > Seriously, there's a bigger question here > thanÂ shouldÂ youÂ orÂ shouldÂ youÂ notÂ compareÂ fractionsÂ andÂ reals. > TheÂ questionÂ isÂ "forÂ whomÂ isÂ PharoÂ written?" > IEEE754 Â run contrary to all of my 18 years of sudying math and using > rational numbers. > I expect the semantics 1/10 = 10/100 = 100/1000 = 1/2*1/5 = 0.5 * 0.2 based > on math in Q. > This is no different from expecting 0.1 + 0.2 = 0.3 and not 0.29999999.... > If you're building software intended for ordinary people, programmers who > rarely do computational mathematics, and for > educational use, then defaulting to arbitrary precision scaled math is the > right way to go, as it matches the expectations of the audience. > If you're defining the default behavior of numbers in the system, the > principle of "thou shall not commit premature optimization" should come into > play. Â If you'reÂ that desperately in need of floating point speed, you're > also probably capable of applying that and other optimizationÂ techniques > accordingly, as befits your problem. > Consider IEEE754 floats as optimization for a specific class of application, > but a de-optimization for all other uses. > Now if you're only designing Pharo for people who program IEEE754 float > intensive applications, then by all means, go right ahead and make them the > default. > > Dave > -- > -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ > > _______________________________________________ > 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] byte codes, parse-tree walking, etc.

by StÃ©phane Ducasse

BTW we should make sure that it is easy to load VMMaker the last time I got a problem with Genie plugin. stef On Jul 8, 2009, at 9:43 PM, Igor Stasenko wrote: > 2009/7/8 Cameron Sanders <camsanders01(a)roadrunner.com>: >> 1) What classes should I look at to learn about the byte-code >> generation? >> > I think you'd better look at NewCompiler. > Don't look at compiler implementation in its current state :) > >> 2) What are good examples of code that handles/manipulates/processes >> the byte-code? e.g. like the code used for searching for symbol >> references in the byte-code, what is that called? (Is that >> MethodFinder stuff?) >> > There is InstructionStream, and of course see CompiledMethod itself. > >> 2.b) And what is the name (& path) of the C module that >> actually >> implements the VM case statement (or whatever dispatch is used)? >> > VMMaker is _smalltalk_ package which implements such dispatch, and > then translated to C & compiled to get a VM binary. > Look for VMMaker package at squeaksource.com > >> 3. Once upon a time there was some code that processed Slang ... >> but I >> have no idea whether that code is in Pharo, or completely antiquated >> in all versions. (And if gone from Pharo, what should I look for and >> in which version of Squeak?) >> >> A list of a few classes (in current use) would be greatly >> appreciated. >> > VMMaker: Interpreter, ObjectMemory > Image: Compiler/Parser (but better look a NewCompiler) > InstructionStream, ContextPart, CompiledMethod > >> Thanks in advance, >> Cam >> PS: reading through list archives can be painful, as they often >> either >> build on known information, or if you back up too far, the material - >> you later learn- is completely antiquated. >> >> _______________________________________________ >> 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

Re: [Pharo-project] Annoying bug: UndefinedObject(Object)>>doesNotUnderstand: #mimeTypes

by Mariano Martinez Peck

Yes. It is attached in the bug report: http://code.google.com/p/pharo/issues/detail?id=945 On Wed, Jul 8, 2009 at 1:43 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > do you have the stack trace? > > Stef > On Jul 8, 2009, at 3:55 PM, Mariano Martinez Peck wrote: > > > This bug is really annoying. I am in windows, using 10371. Both: > > Pharo and PharoCore, have the same problem. > > > > To reproduce: > > > > 1) Go to squeak > > 2) alt + tab to switch to another windows > > 3) alt + tab again to come back to squeak > > > > At that moment, we you get the focus in Squeak you will get TWO DNU. > > They are the same. > > > > I attach SqueakDebug.log > > > > Please consider this for 1.0 because it is unusable. > > > > I created the ticket: > http://code.google.com/p/pharo/issues/detail?id=945 > > > > Cheers, > > > > Mariano > > _______________________________________________ > > 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] byte codes, parse-tree walking, etc.

by Cameron Sanders

Awesome, thanks for the leads! -Cam On Jul 8, 2009, at 3:43 PM, Igor Stasenko wrote: ... > VMMaker is _smalltalk_ package which implements such dispatch, and > then translated to C & compiled to get a VM binary. > Look for VMMaker package at squeaksource.com ...

July 8, 2009