Ken, A 2-10x performance hit is all the more reason why such a creation should be dormant unless specifically invoked - translation, no coercion into the controversial type. While there are uses for systems that are "smart" enough to give exact answers, most computation happens in a world of tolerances, with numbers that are not cherry picked for aesthetics. As somebody else (Sig perhaps) said, the behavior of the base system magnitude classes should not change when a different package is loaded. #asComplex is the gateway through which one can tell the system that complex numbers are expected and desired. The more you write, the more it becomes clear that there also would need to be a #asComplexSymbolic or something to invoke behavior one might expect from Maple and other symbolic systems. I strongly recommend starting with a numerical approach to a "closed system" of complex numbers. GSL provides much of what should be available, and can be mapped into Pharo by FFI/Alien. The result would get used. If you then want to compete with Maple and Mathematica, that really should be done separately. For examle, there are times when I use logs to estimate the number of digits required to hold a number, and if the argument is negative, I goofed and expect an error. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ken.Dickey Sent: Thursday, August 13, 2009 12:09 PM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Complex number support discussion Igor Stasenko
P.S. diving into complex plane uncovers many potential pitfalls to those who expecting a certain behavior of mathematical functions over a real numbers. In first place square and square root. It is good that with introduction of a complex numbers we can be sure that x sqrt squared = x for any real x.
The complex numbers gives us a impression that from now on, the square function and squared root functions is reversable. But they are not for a complex numbers. In practice this means, that one, who using a complex math in his code, should know well the properties of complex numbers, because this is not so trivial as with real numbers & school algebra. And such people, basically don't need the things with questionable or controversial behavior such as #< operators on a complex plane. Then the aim of Complex package developer should be to not introduce more confusion to people who is not using/learnt the complex numbers, and leave attempts to help people who can - because they could care for themselves well.
I guess here I go to high school physics, where electricity and magnetism use complex numbers and relativity uses hyperbolic trig. [Perhaps 1st year physics if your high school did not cover this]. My own experience is that adapting to floating point lossage was far more painful for me than learning 2d mathematics. Again, we can remove Complex totally and make that, hyperbolic trig, ln, and so forth into loadable packages. I would recommend that the error reports for sqrt and ln (if kept) of negative numbers make mention that a loadable package exists to give the expected functionality. A minimal base image (lacking even tools, perhaps even Morphic) is certainly useful in the build process at some point. I suspect there are those who would make such an image even smaller by removing fractions and perhaps even floats. My own preference is to leverage meta-programming aspects (traits, live code, intelligent toolsets) because I think that is where Pharo/Squeak excels. I am certainly happy to pay additional computational cost for better approximations to math (e.g. interval mathematics) because I like the system to tell me where the deep and shallow waters are. A factor of two or even ten slower sounds like a lot, but as speeds continue to double every 18 months, getting the right answers rather than "the wrong answer fast" is why one puts up with slower runtime systems. $0.02, -KenD PS: Thanks all for the helpful suggestions on tightening up the math. I will take a closer look at the branch cuts and so forth. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project