It looks like KedamaFloatArray is doing things that belong in FloatArray. A subclass would be approrpiate if the vector operations are unusual in some way; a quick glance suggests that they are pretty reasonable and unlikely to clash with other implemetations. Re "any collection, any type," that is almost true. The typed array classes (like FloatArray) have a distinct advantage over say OrderedCollection: the garbage collector sees them as one object, which can be a big plus for performance. Think of a 1000x1000 matrix and the GC load is impressive. The other big advantage is that one has a hope of passing a FloatArray into a C FFT function (for example), but hardly a prayer of getting an external function to understand an Array full of Float instances. Does that help? Yes, there should be a WORDArray, DWORDArray, etc, and most certainly a COMPLEXArray, all aimed at large arrays (image and signal processing, etc.) and often combined with FFI for fast number crunching. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak@bol.com.br Sent: Friday, August 14, 2009 3:41 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion Wilhelm, In adition to the consensus about Complex, I would like to add that from a Smalltalk language point of view FloatArray (and any ensuing specialized arrays, IntegerArray I can understand but can someone tell me what a heck is an KedamaFloatArray?? :-) ) are a specialization that are orthogonal to the dynamic design of Smalltalk: Any collection in Smalltalk is supposed to hold any class of objects. If I understood the Pharo principles (I'm still digesting and attempting to form a roadmap in my head) those classes should not be part of Core Pharo but part of some specialized package Em 14/08/2009 17:04, Schwab,Wilhelm K < bschwab@anest.ufl.edu > escreveu: John, That is not far from the eveolving conscensous opinion - I think we can indeed claim to have a collective desire to leave integers and floats as they are. One concern I have about your suggestion is what happens when the user loads the complex package? Does existing code break? It would given Ken's proposal. There are alternatives, and they are discussed in this fairly extensive thread. Besides, someone wanting complex numbers will look for and load a package to support them, as long as it is good code. Complex is fine as far as it goes; some FFI magic to benefit from GSL functionality would be nice. We should also have an analog to FloatArray that has complex entries; again, a wrapper onto GSL would be a nice addition. I have no power over Ken; he can build what he wants. I would like to see his energy directed toward creating something we can all use. I suggest a layered proposal on the wiki and up or down votes on what becomes part of Pharo. If the vote(s) split, we have benevolent dictators to sort it out. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John McIntosh Sent: Friday, August 14, 2009 1:49 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion Why not have sqrt throw the exception and suggest that you could load the optional complex logic if you actual are working with complex numbers On 8/14/09, Schwab,Wilhelm K wrote:
Ken,
All of us will welcome something that can do sophisticed mathematics, provided it does not break the base system when installed, and has no/limited runtime penalty when not neede d.
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: Friday, August 14, 2009 10:38 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion
Schwab,Wilhelm K"
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 o f 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project