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 <bschwab@anest.ufl.edu> 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 needed.

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" <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

_______________________________________________ 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 <johnmci@smalltalkconsulting.com> 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

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

Ok, but that is a somewhat extreme example. The real value of the typed array classes is to handle large arrays and often ones destined for crunching by external code. So, the numbers you describe would end up being floats, because a C based algorithm could no more write into them than Smalltalk code. With a mere 10 elements, and doing all in Smalltalk to benefit from the automatic scaling to LargeInteger, an OrderedCollection works fine. While Smalltalk generally stinks at line-by-line computation, it is GREAT for allocating memory, asking a C library to read data into a block of memory, asking another library to do an FFT, calling something else to decide when to stop an iteration, asking yet another to plot it, ... The typed arrays will stay; they are critical to FFI. But in the spirit of the current thread, note that OrderedCollection does not automatically turn itself into one of them, so you can safely/easily ignore them if you don't do this type of work. 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 4:39 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion OK, I don't dispute the possible advantages of those specialized collections for certain problem domains (mainly due the need to FFI [a.k.a. "not reinvent the wheel]) and performance. BUT get a look on this: ia := IntegerArray new: 10. 1 to: 10 do: [:i | ia at: i put: (1000 raisedTo: i)] In the fourth element you'll get 'Improper store into indexable object', Smaltalk trivially promotes SmallIntegers: 1000 raisedTo: 4 -> 1000000000000 1000 class -> SmallInteger 1000000000000 class -> LargePositiveInteger If we need this raw performance and have to keep babysiting for overflow, isn't it better to have the algorithm altogether in the foreing library and just have a light wrapper class to it? After of all, we all agree that starting with the syntax Smalltalk is not really numerical oriented ;-) Em 14/08/2009 18:14, Schwab,Wilhelm K < bschwab@anest.ufl.edu > escreveu: 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 instal led, 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, t hat 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

It might generate an error vs. coerce, but the point is to compactly store an array of the indicated type. It's a lot like String vs. a collection of characters; both have their uses. ________________________________ 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 6:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion OK. IIUC then any Number when stored in a Array of these will be copied and coerced to the specific type, is it right? Em 14/08/2009 18:54, Schwab,Wilhelm K < bschwab@anest.ufl.edu > escreveu: Ok, but that is a somewhat extreme example. The real value of the typed array classes is to handle large arrays and often ones destined for crunching by external code. So, the numbers you describe would end up being floats, because a C based algorithm could no more write into them than Smalltalk code. With a mere 10 elements, and doing all in Smalltalk to benefit from the automatic scaling to LargeInteger, an OrderedCollection works fine. While Smalltalk generally stinks at line-by-line computation, it is GREAT for allocating memory, asking a C library to read data into a block of memory, asking another library to do an FFT, calling something else to decide when to stop an iteration, asking yet another to plot it, ... The typed arrays will stay; they are critical to FFI. But in the spirit of the current thread, note that OrderedCollection does not automatically turn itself into one of them, so you can safely/easily ignore them if you don't do this type of work. 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 4:39 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion OK, I don't dispute the possible advantages of those specialized collections for certain problem domains (mainly due the need to FFI [a.k.a. "not reinvent the wheel]) and performance. BUT get a look on this: ia := IntegerArray new: 10. 1 to: 10 do: [:i | ia at: i put: (1000 raisedTo: i)] In the fourth element you'll get 'Improper store into indexable object', Smaltalk trivially promotes SmallIntegers: 1000 raisedTo: 4 -> 1000000000000 1000 class -> SmallInteger 1000000000000 class -> LargePositiveInteger If we need this raw performance and have to keep babysiting for overflow, isn't it better to have the algorithm altogether in the foreing library and just have a light wrapper class to it? After of all, we all agree that starting with the syntax Smalltalk is not really numerical oriented ;-) Em 14/08/2009 18:14, Schwab,Wilhelm K < bschwab@anest.ufl.edu > escreveu: 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 l ike 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 i t does not break the base system when instal led, 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, t hat 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< br />http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

That's fine, but there are times when one wants to treat float arrays are big vectors, doing scalar multiplication and vector arithmetic; the plugin looks useful for such things, but most of it should just be extra behavior in FloatArray. -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Friday, August 14, 2009 4:59 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion Kedama - A massively-parallel tile-scriptable particle system http://www.is.titech.ac.jp/~ohshima/squeak/kedama/ It's part of eToys, if ship the KedamaPlugin and KedamaPlugin2 plugins with the macintosh carbon VM *cough* if etoys is being eradicated then KedamaFloatArray should be on a list somewhere On 14-Aug-09, at 1:41 PM, csrabak@bol.com.br wrote:

can someone tell me what a heck is an KedamaFloatArray??

-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 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

John, If I may be so presumptuous, the answer is to have people use #asComplex when they want complex results. -2 sqrt throws an error; -2 asComplex sqrt gives the complex (imaginary) result. Then we break no old code, we offer useful new features with minimal effort required to invoke them. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Friday, August 14, 2009 4:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion On 14-Aug-09, at 1:04 PM, Schwab,Wilhelm K wrote:

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

Ah, yes well I think I lost the 0.2 = (1/2) argument, so anything goes. I think the choice is either numbers + complex work as expected, or you just offer number then offer to load the complex logic as soon as someone wants -2 sqrt. Obviously the problem here is that for a vast range of programmers if you offer up -2 sqrt by default and it does not throw an exception they will be confused. Some of them likely have NO idea what a complex number is. Random thoughts. No-doubt there are abuses of math to string where people assume you have an integer like thing versus a complex number string. -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 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

+1 no globals, please :) 2009/8/15 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:

I really do not like the flag idea, because it is global.  What if there are two phases to something, one that uses complex numbers, and one that does not?  Since the complex numbers are the far less likely be needed and much newer feature to Smalltalk, the separate world design will be the cleaner and better accepted option.

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 7:16 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion

That's why I suggest (once Complex be loaded) a flag something like Smalltalk complexResultsOn and its counterpart to turn off be used instead.

Em 14/08/2009 20:53, John McIntosh < johnmci@smalltalkconsulting.com > escreveu:

Yes but we usually don't do explicit casting Like 2 asFloat * 3.0 We could but where does the implicit type conversion lie?

On 8/14/09, Schwab,Wilhelm K wrote:

...

John,

If I may be so presumptuous, the answer is to have people use #asComplex when they want complex results. -2 sqrt throws an error; -2 asComplex sqrt gives the complex (imaginary) result. Then we break no old code, we offer useful new features with minimal effort required to invoke them.

Bill

-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Friday, August 14, 2009 4:55 PM To: Pharo-project@lists.gforge.inria .fr Subject: Re: [Pharo-project] Complex number support discussion

On 14-Aug-09, at 1:04 PM, Schwab,Wilhelm K wrote:

...

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

Ah, yes well I think I lost the 0.2 = (1/2) argument, so anything goes.

I think the choice is either numbers + complex work as expected, or you just offer number then offer to load the complex logic as soon as someone wants -2 sqrt.

Obviously the problem here is that for a vast range of programmers if you offer up -2 sqrt by default and it does not throw an excepti on they will be confused. Some of them likely have NO idea what a complex number is.

Random thoughts.

No-doubt there are abuses of math to string where people assume you have an integer like thing versus a complex number string.

-- = = = ======================================================================== John M. McIntosh Twitter: squeaker68882 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

-- =========================================================================== 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

-- Best regards, Igor Stasenko AKA sig.

Nothing tricky: just that methods answering complex results should be defined only by things tha are already complex. -1 sqrt blows up; -1 asComplex answers i. There would be no imlicit conversion between real and complex, allowing the base system to perform as it does now and still allowing all the complex number crunching anyone wants to do. Does that help? 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: Saturday, August 15, 2009 11:08 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion I do agree on your gripe about the globality (in the first proposal of mine I mentioned that), but I don't grasp in fully the "separated world concept". Could you elaborate? Em 14/08/2009 21:42, Schwab,Wilhelm K < bschwab@anest.ufl.edu > escreveu: I really do not like the flag idea, because it is global. What if there are two phases to something, one that uses complex numbers, and one that does not? Since the complex numbers are the far less likely be needed and much newer feature to Smalltalk, the separate world design will be the cleaner and better accepted option. 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 7:16 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion That's why I suggest (once Complex be loaded) a flag something like Smalltalk complexResultsOn and its counterpart to turn off be used instead. Em 14/08/2009 20:53, John McIntosh < johnmci@smalltalkconsulting.com > escreveu: Yes but we usually don't do explicit casting Like 2 asFloat * 3.0 We could but where does the implicit type conversion lie? On 8/14/09, Schwab,Wilhelm K wrote:

John,

If I may be so presumptuous, the answer is to have people use #asComplex when they want complex results. -2 sqrt throws an error; -2 asComplex sqrt gives the complex (imaginary) result. Then we break no old code, we offer useful new features with minimal effort required to invoke them.

Bill

-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Friday, August 14, 2009 4:55 PM To: Pharo-project@lists.gforge.inria .fr Subject: Re: [Pharo-project] Complex number support discussion

On 14-Aug-09, at 1:04 PM, Schwab,Wilhelm K wrote:

...

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

Ah, yes well I think I lost the 0.2 = (1/2) argument, so anything goes.

I think the choice is either numbers + complex work as expected, or you just offer number then offer to load the complex logic as soon as someone wants -2 sqrt.

Obviously the problem here is that for a vast r ange of programmers if you offer up -2 sqrt by default and it does not throw an excepti on they will be confused. Some of them likely have NO idea what a complex number is.

Random thoughts.

No-doubt there are abuses of math to string where people assume you have an integer like thing versus a complex number string.

-- = = = ======================================================================== John M. McIntosh Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

_______________________________________________ Pharo-project mailing list & gt; 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

2009/8/15 <csrabak@bol.com.br>:

It helps to undestand your suggestion.

It does not help to make it Smalltalk friendly, my meaning of that being the "principle of least surprise".

least suprise for who? For you it could be the least surprise. For me, and for other people it would be a big surprise. So, please give a better/different reasoning, why in a presence of Complex numbers, a functions which operating with Real numbers should change their behavior. Integers are subset of Real set and Real is a subset of Complex, then one could happily write: Array new: 0.2i and following your reasoning, the above is good way to write a code and it should work well.

If complex math is to be allowed a natural consequence is that a lot of functions would return complex answers for real arguments.

How would then have Pharo Smalltalk behave in a case of computing a reactance: X = jωL?

anInductance being Number and complexFrequency obviously being Complex:

aReactance := anInductance * complexFrequency

Em 15/08/2009 13:55, Schwab,Wilhelm K < bschwab@anest.ufl.edu > escreveu:

Nothing tricky: just that methods answering complex results should be defined only by things tha are already complex.  -1 sqrt blows up; -1 asComplex answers i.  There would be no imlicit conversion between real and complex, allowing the base system to perform as it does now and still allowing all the complex number crunching anyone wants to do. Does that help? Bill

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

2009/8/15 <csrabak@bol.com.br>:

Igor,

I think I don't undersand your point. What is the mathematical significance of an Array of size 0.2i?

the significance is not mathematical, it is practical: how many hours one should spend fixing all 'surprises' which you can introduce if not carefully add Complex support. Let me remind you that Physics is not the only area where is mathematcal apparatus is used. In banking, people using a completely different mathematical apparatus, and i doubt that they using complex values to calculate sums on client's accounts. But i don't have any doubts that such applications require very stable and predictable math functions which operating mainly over real numbers.

Em 15/08/2009 14:35, Igor Stasenko < siguctua@gmail.com > escreveu:

2009/8/15 :

...

It helps to undestand your suggestion.

It does not help to make it Smalltalk friendly, my meaning of that being the "principle of least surprise".

least suprise for who? For you it could be the least surprise. For me, and for other people it would be a big surprise. So, please give a better/different reasoning, why in a presence of Complex numbers, a functions which operating with Real numbers should change their behavior.

Integers are subset of Real set and Real is a subset of Complex, then one could happily write:

Array new: 0.2i

and following your reasoning, the above is good way to write a code and it should work well.

...

If complex math is to be allowed a natural consequence is that a lot of functions would retur n complex answers for real arguments.

How would then have Pharo Smalltalk behave in a case of computing a reactance: X = jωL?

anInductance being Number and complexFrequency obviously being Complex:

aReactance := anInductance * complexFrequency

Em 15/08/2009 13:55, Schwab,Wilhelm K < bschwab@anest.ufl.edu > escreveu:

Nothing tricky: just that methods answering complex results should be defined only by things tha are already complex.  -1 sqrt blows up; -1 asComplex answers i.  There would be no imlicit conversion between real and complex, allowing the base system to perform as it does now and still allowing all the complex number crunching anyone wants to do. Does that help? Bill

_______________________________________________ Pharo-project mailing list Pharo-pr oject@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

_______________________________________________ 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

-- Best regards, Igor Stasenko AKA sig.

2009/8/15 <csrabak@bol.com.br>:

I agree with your first paragraph! However I don't see logical fitting to example you gave on an Array of 0.2i. . .

because of that: length := [ something sqrt ] on: Error do: [ 5 ]. array := Array new: length. which makes the code which worked before to be badly broken if you change the sqrt behavior to not produce error, when you supply negative value as receiver. Even how ridiculous it may look, some people could deliberately provide the 'wrong' values to functions, expecting them to fail and then to be catched later & handled appropriately. It could serve as a way to simplify the code or workaround.

Again Physics versus Banking, there is lot of physics that is done without need of complex numbers, and certainly in financial application I cannot foresee any need to have Complex loaded in an image (except if you need 'imaginary dollars' in some Ponzi scheme :-D )

never heard about Ponzi scheme.. :)

About the principle of least surprise (a.k.a. principle of least astonishment) I thinking about the Smalltalk environment.

In several programming languages 13 / 3 would return 4. In these languages this operation is on two integers and integer division gives you four.

In [Pharo] Smalltalk the result is Fraction.  We are used to this.

So once we have Fraction in the image (OK, just as think experiment. . .), we can have this automatic promotion of the result.  Same happens to the classic (aNumber factorial) example.

I see where you want to draw a parallel, but this is not the case with Complex. Simply because Fraction is a different representation of values from the same set - Real (or rational) numbers, but its not adds new dimensions and you are not jumping into a complex plane when using fractions. You can potentially pass the Fraction into any function(method) which expects a Real value. But you can't simply pass a Complex value to a function with expects and designed to operate with a Real values, because it would be theoretically/conceptually wrong. Just an example, where you can go conceptually wrong is to write something like: abusedComplex := Complex real: (2i) imaginary: (5i). and then use given value in operations which expecting the complex values and assuming that real & imaginary parts should not be complex in own turn. For the same reason i'm against implicit conversion to complex values as a result of functions which is also defined for real values.

Now. Again in other languages should a programmer want to be sure the result are less than a truncation she/he coud do:

13 / 3.0 or use some of the 'casting' mechanisms available to them. I see the asComplex need for operations where Complex has been alredy put in operation as similar to those casts.

You don't need casting with fractions because you don't change the mathematical meaning of the value. But complex values changing it.

Hope it is explicit now.

I hope i clarified my position too :)

Em 15/08/2009 17:36, Igor Stasenko < siguctua@gmail.com > escreveu:

2009/8/15 :

...

Igor,

I think I don't undersand your point. What is the mathematical significance of an Array of size 0.2i?

the significance is not mathematical, it is practical: how many hours one should spend fixing all 'surprises' which you can introduce if not carefully add Complex support.

Let me remind you that Physics is not the only area where is mathematcal apparatus is used. In banking, people using a completely different mathematical apparatus, and i doubt that they using complex values to calculate sums on client's accounts. But i don't have any doubts that such applications require very stable and predictable math functions which operating mainly over real numbers.

...

Em 15/08/2009 14:35, Igor Stasenko < siguctua@gmail.com > escreveu: & gt; 2009/8/15 :

...

It helps to undestand your suggestion.

It does not help to make it Smalltalk friendly, my meaning of that being the "principle of least surprise".

least suprise for who? For you it could be the least surprise. For me, and for other people it would be a big surprise. So, please give a better/different reasoning, why in a presence of Complex numbers, a functions which operating with Real numbers should change their behavior.

Integers are subset of Real set and Real is a subset of Complex, then one could happily write:

Array new: 0.2i

and following your reasoning, the above is good way to write a code and it should work well.

...

If complex math is to be allowed a natural consequence is that a lot of > ; functions would retur n complex answers for real arguments.

How would then have Pharo Smalltalk behave in a case of computing a reactance: X = jωL?

anInductance being Number and complexFrequency obviously being Complex:

aReactance := anInductance * complexFrequency

Em 15/08/2009 13:55, Schwab,Wilhelm K < bschwab@anest.ufl.edu > escreveu:

Nothing tricky: just that methods answering complex results should be defined only by things tha are already complex.  -1 sqrt blows up; -1 asComplex answers i.  There would be no imlicit conversion between real and complex, allowing the base system to perform as it does now and still allowing all the complex number crunching anyone wants to do. Does that help? Bill

_______________________________________________ Pharo-project mailing list Pharo-pr oject@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

_______________________________________________ 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

-- Best regards, Igor Stasenko AKA sig.

_______________________________________________ Pharo-project mailing list Phar o-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

-- Best regards, Igor Stasenko AKA sig.

Certainly complex can have integral values for its real and imaginary parts, but those will be of little use when computing the values of trancendental functions (which is most of what will be done). Sig and I have pointed out that Fraction has a lot more in common with Float than does Complex. This converation needs to move to the wiki in the form of proposals. 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: Saturday, August 15, 2009 5:05 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion Your first example is interesting. It boils down to two design aspects: If you need Complex numbers in the same application, you need to refactor the code to: length := (something positive) ifTrue:[something sqrt ] IfFalse: Error do: [ 5 ]. array := Array new: length. The application does not complex results at all and through the mechanism Pharo team will decide upon this kind of support will be disabled. About the remaining of discussion, we need to remember all the time Pharo [Smalltalk] is a programming environment that has come concrete in bits at some time in order to become operative (from this onset I think the abusedComplex should trow errors as adequate). The need for Fraction, Float and Integer in most programming languages (Smalltalk included) is more often than not for the sake of efficiency or simplification of the underlying code than for mathematical rigour. So as right as you are that 13/3 returning asFraction does not change the "mathematical meaning of the value" in Smalltalk this is a correct assertion, but in a lot of other environments it is not! They are different representations of numbers that have to be treated as such. In a lot languages I'm versed on, writing 5e100 can only mean an 80 bit float (in most HW) because it is the only way of storing such a beast. In Smalltalk you ask for the class of this and get LargePositiveInteger (Pharo). In Smalltalk 5e100 is syntatic sugar for not having to write one hundred zeros. So, when we decide in certain things in programming language you're making decisions on how to model certain aspects of the problem domain. Smalltalk in the arithmetical part decide to postpone as much as possible the loss of precision of the result. It is an expected behaviour in this language. Once you put Complex in the Smalltalk paradigm, I think we should preserve as much as possible this design decision made at the start of the language. From a programming POV -4 sqrt mapping from Real to Imaginary (Complex) is homologous to 13 / 3 giving a Fraction. Overall is a modeling of the world. BTW, this is why I think having Complex to only have Float members is not a nice design decision... Em 15/08/2009 18:27, Igor Stasenko < siguctua@gmail.com > escreveu: 2009/8/15 :

I agree with your first paragraph! However I don't see logical fitting to example you gave on an Array of 0.2i. . .

because of that: length := [ something sqrt ] on: Error do: [ 5 ]. array := Array new: length. which makes the code which worked before to be badly broken if you change the sqrt behavior to not produce error, when you supply negative value as receiver. Even how ridiculous it may look, some people could deliberately provide the 'wrong' values to functions, expecting them to fail and then to be catched later & handled appropriately. It could serve as a way to simplify the code or workaround.

Again Physics versus Banking, there is lot of physics that is done without need of complex numbers, and certainly in financial application I cannot foresee any need to have Complex loaded in an image (except if you need 'imaginary dollars' in some Ponzi scheme :-D )

never heard about Ponzi scheme.. :)

About the principle of least surprise (a.k.a. principle of least astonishment) I thinking about the Smalltalk environment.

In several programming languages 13 / 3 would return 4. In these languages this operation is on two integers and integer division gives you four.

In [Pharo] Smalltalk the result is Fraction. We are used to this.

So once we have Fraction in the image (OK, just as think experiment. . .), we can have this automatic promotion of the result. Same happens to the classic (aNumber factorial) example.

I see where you want to draw a parallel, but this is not the case with Complex. Simply because Fraction is a different represe ntation of values from the same set - Real (or rational) numbers, but its not adds new dimensions and you are not jumping into a complex plane when using fractions. You can potentially pass the Fraction into any function(method) which expects a Real value. But you can't simply pass a Complex value to a function with expects and designed to operate with a Real values, because it would be theoretically/conceptually wrong. Just an example, where you can go conceptually wrong is to write something like: abusedComplex := Complex real: (2i) imaginary: (5i). and then use given value in operations which expecting the complex values and assuming that real & imaginary parts should not be complex in own turn. For the same reason i'm against implicit conversion to complex values as a result of functions which is also defined for real values.

Now. Again in other languages sho uld a programmer want to be sure the result are less than a truncation she/he coud do:

13 / 3.0 or use some of the 'casting' mechanisms available to them. I see the asComplex need for operations where Complex has been alredy put in operation as similar to those casts.

You don't need casting with fractions because you don't change the mathematical meaning of the value. But complex values changing it.

Hope it is explicit now.

I hope i clarified my position too :)

Em 15/08/2009 17:36, Igor Stasenko < siguctua@gmail.com > escreveu:

2009/8/15 :

...

Igor,

I think I don't undersand your point. What is the mathematical significance of an Array of size 0.2i?

the significance is not mathematical, it is practical: how many hours one should s pend fixing all 'surprises' which you can introduce if not carefully add Complex support.

Let me remind you that Physics is not the only area where is mathematcal apparatus is used. In banking, people using a completely different mathematical apparatus, and i doubt that they using complex values to calculate sums on client's accounts. But i don't have any doubts that such applications require very stable and predictable math functions which operating mainly over real numbers.

...

Em 15/08/2009 14:35, Igor Stasenko < siguctua@gmail.com > escreveu: & gt; 2009/8/15 :

...

It helps to undestand your suggestion.

It does not help to make it Smalltalk friendly, my meaning of that being the "principle of least surprise".

least suprise for who? For you it could be the least surprise. For me, and for other people it would be a big surprise. So, please give a better/different reasoning, why in a presence of Complex numbers, a functions which operating with Real numbers should change their behavior.

Integers are subset of Real set and Real is a subset of Complex, then one could happily write:

Array new: 0.2i

and following your reasoning, the above is good way to write a code and it should work well.

...

If complex math is to be allowed a natural consequence is that a lot of ; functions would retur n complex answers for real arguments.

How would then have Pharo Smalltalk behave in a case of computing a reactance: X = jωL?>>> anInductance being Number and complexFrequency obviously being Complex:

aReactance := anInductance * complexFrequency

Em 15/08/2009 13:55, Schwab,Wilhelm K < bschwab@anest.ufl.edu > escreveu:

Nothing tricky: just that methods answering complex results should be defined only by things tha are already complex. -1 sqrt blows up; -1 asComplex answers i. There would be no imlicit conversion between real and complex, allowing the base system to perform as it does now and still allowing all the complex number crunching anyone wants to do. Does that help? Bill

_______________________________________________ Pharo-project mailing list Phar o-pr oject@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

_______________________________________________ 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

-- Best regards, Igor Stasenko AKA sig.

_______________________________________________ Pharo-project mailing list P har o-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

-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Em 15/08/2009 19:21, Igor Stasenko < siguctua@gmail.com > escreveu:

2009/8/16 <csrabak@bol.com.br>:

...

Your first example is interesting. It boils down to two design aspects:

If you need Complex numbers in the same application, you need to refactor the code to:

...

length := (something positive) ifTrue:[something sqrt ] IfFalse: Error do: [ 5 ].

i'm sure you meant length := (something positive) ifTrue:[something sqrt ] IfFalse: [ 5 ]

I'm not so sure ;-) I thought your block with a five inside some kind of error message, but this is not that important. It seems you get the spirit and considering my mistake on interpreting your example your correction is OK.

but then #positive is a test which defined as

positive ^ self > 0

and we getting back to discussion , what is the meaning of #> or #< operator for complex values.

NO!! Because all this discussion is being on the possibility of having an operation on a _non_ Complex number return a Complex result, so the test is kosher and you can go. _If_ you return an argument that something already was a complex number then all this argument is moot... [snipped]

...

Once you put Complex in the Smalltalk paradigm, I think we should preserve as much as possible this design decision made at the start of the language. From a programming POV -4 sqrt mapping from Real to Imaginary (Complex) is homologous to 13 / 3 giving a Fraction. Overall is a modeling of the world.

BTW, this is why I think having Complex to only have Float members is not a nice design decision...

ageed. Its can hold any values representing the value from a Real set. But as soon as one of its member start holding someting different (Complex) - you are in trouble.

It depends. My reasoning was that if we maintain the members as two numbers in Smalltalk sense and let the mechanisms choose the representation (actually the classes), a lot of possible problems with Complex numbers not coalescing back to real due non canceling of imaginary parts (due rounding errors) could be minimized. This could make Pharo Smalltalk more interesting than using other languages where all the problems with numerical accuracy have to be taken in account.

I simply wanted to illustrate you that passing values to code which not expecting the Complex values having same side effect as passing a Complex values to members of Complex value (real/imaginary) part, and state that its ok.

I'm sorry to inform you that until now you have not achieved your intent in showing me a robust case. . .

That's why its is good to have separation from functions which operating with reals only and can NEVER return anything else than real values from functions which can return complex values.

I maintain my opinion that this is not helpful to make Pharo (having an implementation like this) compelling for doing work with this kind of programming. For doing this way you rather do it in a spreadsheet application that has for any function a separate one for complex numbers: it works, but is cumbersome and makes code become bulkier. A strength of OO languages is polymorphism and Smalltalk adds to it dynamic typing. The separation you advocate make these advantages be lost. -- Cesar Rabak

2009/8/16 <csrabak@bol.com.br>:

Em 15/08/2009 19:21, Igor Stasenko < siguctua@gmail.com > escreveu:

...

2009/8/16 <csrabak@bol.com.br>:

...

Your first example is interesting.  It boils down to two design aspects:

If you need Complex numbers in the same application, you need to refactor the code to:

...

length := (something positive) ifTrue:[something sqrt ] IfFalse: Error do: [ 5 ].

i'm sure you meant length := (something positive) ifTrue:[something sqrt ] IfFalse: [ 5 ]

I'm not so sure ;-) I thought your block with a five inside some kind of error message, but this is not that important. It seems you get the spirit and considering my mistake on interpreting your example your correction is OK.

...

but then #positive is a test which defined as

positive ^ self > 0

and we getting back to discussion , what is the meaning of #> or #< operator for complex values.

NO!! Because all this discussion is being on the possibility of having an operation on a _non_ Complex number return a Complex result, so the test is kosher and you can go. _If_ you return an argument that something already was a complex number then all this argument is moot...

Let me restate where we started from. We started from point: Array new: 0.2i which simply shown that there are many places where complex numbers appearance (or even non-integer numbers) is undesirable. But since you insisting on introducing the functions which do implicit conversions under the hood, without real intent of developer, how he could be sure that above not happens? And then same, in next example: (something positive) ifTrue:[something sqrt ] IfFalse: [ 5 ] how you can be sure that 'something' is not complex number already, and therefore, sending #positive to it is meaningless?

[snipped]

...

...

Once you put Complex in the Smalltalk paradigm, I think we should preserve as much as possible this design decision made at the start of the language. From a programming POV -4 sqrt mapping from Real to Imaginary (Complex) is homologous to 13 / 3 giving a Fraction.  Overall is a modeling of the world.

BTW, this is why I think having Complex to only have Float members is not a nice design decision...

ageed. Its can hold any values representing the value from a Real set. But as soon as one of its member start holding someting different (Complex) - you are in trouble.

It depends.  My reasoning was that if we maintain the members as two numbers in Smalltalk sense and let the mechanisms choose the representation (actually the classes), a lot of possible problems with Complex numbers not coalescing back to real due non canceling of imaginary parts (due rounding errors) could be minimized.

This could make Pharo Smalltalk more interesting than using other languages where all the problems with numerical accuracy have to be taken in account.

Rounding errors plaguing the Real numbers in the same way, and i don't see much difference here. Where i see the difference is, that for real numbers you need to represent a single value (and no matter by what you representing it - because it is still Real value), while for complex number you need a two distinct values (but they could be represented by any real values you desire). But since you don't see such difference and advocating that complex is just a 'more generic' representation of real, an no-one should care where it seamlessly appears and when (because of implicit coercions), then give me the answer, where you want to stop: 1. Two different ways representing real value: 1/2 <=> 0.5 2. Two different ways representing ?same? value: 0.5 <=> 0.5 + 0i 3. Three different ways representing ?same? value: 0.5 <=> 0.5 + 0i <=> Complex real: (0.5 + 0i) imaginary: (0 + 0i) 4. Four different ways representing ?same? value: 0.5 <=> 0.5 + 0i <=> Complex real: (0.5 + 0i) imaginary: (0 + 0i) <=> Complex real: (0.5 + (Complex real: 0+ 0i imaginary: 0 + 0i)) imaginary: (0 + 0i) and so on...

...

I simply wanted to illustrate you that passing values to code which not expecting the Complex values having same side effect as passing a Complex values to members of Complex value (real/imaginary) part, and state that its ok.

I'm sorry to inform you that until now you have not achieved your intent in showing me a robust case. . .

...

That's why its is good to have separation from functions which operating with reals only and can NEVER return anything else than real values from functions which can return complex values.

I maintain my opinion that this is not helpful to make Pharo (having an implementation like this) compelling for doing work with this kind of programming.  For doing this way you rather do it in a spreadsheet application that has for any function a separate one for complex numbers: it works, but is cumbersome and makes code become bulkier.

A strength of OO languages is polymorphism and Smalltalk adds to it dynamic typing.

How polymorphism helps in making two different functions (one which producing an error on negative argument, while another producing a complex value) to be identified by a single message selector for a single class?

The separation you advocate make these advantages be lost.

-- Cesar Rabak

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

Btw, here is another argument why Complex is not part of Number class hierarchy. Here what reads the Magnitude class: I'm the abstract class Magnitude that provides common protocol for objects that have the ability to be compared along a ___linear dimension___, such as dates or times. Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as Character and LookupKey. --- Since complex values is not scalars and hence cannot be compared along a linear dimension, they could not be inherited from a Magnitude. Btw this comment seems veeery dated, because it refers to ArithmeticValue, which not present in current class hierarchy :) As you stated earlier that Real set is a subset of Complex, then if you want to see both of them lying in same class hierarchy, it could require a major redesign the class hierarchy to make Complex a base class, and Float/Integer a subclasses. Since subclasses are specialization of superclasses, and superclass always is more generic than any of its subclass. Others could step up and say: hey scalars could be seen as a specialized kind of vectors, and vectors could be seen as a specialized kind of matrices, so lets make Matrix to be the ultimate superclass, and then Vector, and then Scalar etc etc.. I can only guess, how far we can go with such generalization(s). -- Best regards, Igor Stasenko AKA sig.

2009/8/15 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:

Sig,

I don't know in what context you mean "scalars," but complex numbers are indeed used as the scalar field for vector spaces.  That is done both in (abstract) algegra and functional analysis - see Hilbert Space.  That said, I see what you mean and generally agree.  Definitely agreed about the linear dimension; complex does not fit in the magnitude hierarchy.

Yes, the scalar term is a bit ambiguous, so i'd better stop using it. The wiki gives a disambiguation (http://en.wikipedia.org/wiki/Scalar) and , by scalar i mean Scalar (computing), which defined as: In computing, a scalar is a variable or field that can hold only one value at a time; as opposed to composite variables like array, list, record, etc. In some contexts, a scalar value may be understood to be numeric. A scalar data type is the type of a scalar variable. For example, char, int, float, and double are the most common scalar data types in the C programming language. The origin of the term "scalar" in computing dates back to the 1970s, where the intended meaning was "opposite of vector", so as to distinguish from the idea of vector processing in computer processor design.

We also have to remember that there are pgragmatic aspects to this.  We have been over this several times now, so I think we should table this until Ken has time to write up his proposal.

Bill

-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Saturday, August 15, 2009 3:18 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion

Btw, here is another argument why Complex is not part of Number class hierarchy.

Here what reads the Magnitude class:

I'm the abstract class Magnitude that provides common protocol for objects that have the ability to be compared along a ___linear dimension___, such as dates or times. Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as Character and LookupKey.

---

Since complex values is not scalars and hence cannot be compared along a linear dimension, they could not be inherited from a Magnitude.

Btw this comment seems veeery dated, because it refers to ArithmeticValue, which not present in current class hierarchy :)

As you stated earlier that Real set is a subset of Complex, then if you want to see both of them lying in same class hierarchy, it could require a major redesign the class hierarchy to make Complex a base class, and Float/Integer a subclasses. Since subclasses are specialization of superclasses, and superclass always is more generic than any of its subclass.

Others could step up and say: hey scalars could be seen as a specialized kind of vectors, and vectors could be seen as a specialized kind of matrices, so lets make Matrix to be the ultimate superclass, and then Vector, and then Scalar etc etc..

I can only guess, how far we can go with such generalization(s).

-- Best regards, Igor Stasenko AKA sig.

_______________________________________________ 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

-- Best regards, Igor Stasenko AKA sig.