Schwab,Wilhelm K" <bschwab@anest.ufl.edu>
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, My apologies for mixing a personal "philosophy discussion" into the Complex header. Â The Complex implementation does not suffer from the performance hit mentioned and as I stated earlier, I have no current desire to make Pharo into Mathematica. Â I would welcome a package which did this, however. -KenD