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 <[email protected]>: > 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 > [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
