Hi dave thanks for your email because it makes me realizing something important: Computer float numbers are NOT math float numbers. Let us accept it.
> 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. I did not read the fix of nicolas as an optimization, more like a way to fix the wrong behavior of abstraction we offers. I would be in favor to remove = on floats to raise the awareness that it does not make sense. > 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. as programmer we should be expert to the point we understand float = is nonsense. > Saying that "you should know IEEE 754 float math" isn't helpful. > Skilled professionals > make mistakes with floating point math every day. Exact this is why we should not confort them in this attitude by having a system that make them think that float equality make sense. > Telling a child in grammar school that their program doesn't work > because they don't understand IEEE 754 math is equally absurd. But telling a kid: Floats are not real float numbers so do not use them as such. Once my math teacher asked us to computer a function limit and funnily when you type it on a computer at that time you would got a factor 7 between the math and computer. So we learned that there is a difference between math and computer. > 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. Exact. What nicolas is doing is not an optimization: this is fixing reality. Your hardware is real and it dictactes all the errors **you** will do, if the language does not offer you the right hardware abstraction. Computer float numbers are NOT math float numbers. Let us accept it. > > Dave > > -- > -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ > _______________________________________________ > 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
