August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Complex number support discussion

by Schwab,Wilhelm K

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(a)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(a)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(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 14, 2009

Re: [Pharo-project] #< if at first you dont succeed..

by kend

Schwab,Wilhelm K > You seem determined to have the behavior of Float change when the complex > package is installed, and there are various objections to that from > multiple people; those objections are well founded. My interpretation of the responses I have received is "Change breaks History, we have a strong history" not "these suggestions are worse approximations to mathematics". I accept the first reasoning for Squeak. Squeak supports history (backward compatible) at the expense of, e.g., ANSI Smalltalk closures. Pharo has a slightly different goal set and speaks of "reinventing Smalltalk". I believe the changes I suggested better approximate mathematics and logic. I would prefer to see arguments that I am doing bad math, not that "doing better math is a change that we don't want". Once again, the discussion here implies that the Complex class should be removed from Pharo-Core into its own Package. ====== BTW, I fail too see the logic that (-4 sqrt) raises an exception but that (-3 ln) answers a NaN. I would expect both cases to raise exceptions. Any hints on why this is the case? Perhaps both cases should raise and exception with the option to load a/the Complex package? ====== Thanks again for your thoughtful consideration and input, -KenD

Aug. 14, 2009

Re: [Pharo-project] Create a changeset for an entire package?

by Schwab,Wilhelm K

Yeah, but I have some repositories hanging off of old images that would make for a good test - they're just not on this new box, at least not yet. Besides, this is better left to a MC expert. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br Sent: Friday, August 14, 2009 4:40 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Create a changeset for an entire package? Create a repo in your local disk and test your ideas as fast as they come! Em 14/08/2009 18:28, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: This sounds like something Monticello probably does. I **think** you could prepare an .mcz file and then others can place same in a repository, open that and browse the code w/o changing their image. I am striking out badly trying to find a quick place to test the idea, but perhaps an expert can teach us both something. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Friday, August 14, 2009 4:13 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Create a changeset for an entire package? Javier: You can use the change sorter which is in right button -> tools -> change sorter. There, in any of the panes you can see that there is a unnamed changeset with all of your changes. Then you can create a new changeset with right button -> "new changeset" and put a name: "XXXXchange". Then you can move from right to left or left to right any of the changes you want to include. Once you have in your changes all you want, right button on the changeset -> fileout. And in the directory where the image is, you will have a XXXXchange.cs. Does this help? Best, Mariano 2009/8/14 Javier PimÃ¡s <elpochodelagente(a)gmail.com</compose?to=elpochodelagente(a)gmail.com>> It seems fixing bugs is not the only hard part... I've a bunch of fixes for GLCanvas, and a small proposed change for the class browser but I can't find a way to export a diff of all the changed packages, nor a diff of an entire package nor a diff of a class so anybody can see the changes before commiting... Do I have to file out every class I changed? there has to some easier way. Thanks, Javier. -- Javier PimÃ¡s Ciudad de Buenos Aires _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<../../../undefined//compose?to=Pharo> http://lists.gforge.inria.f r/cgi-bin/mailman/listinfo/pharo-project<http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project>

Aug. 14, 2009

Re: [Pharo-project] Complex number support discussion

by John M McIntosh

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(a)bol.com.br wrote: > can someone tell me what a heck is an KedamaFloatArray?? > -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Aug. 14, 2009

Re: [Pharo-project] Complex number support discussion

by John M McIntosh

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(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Aug. 14, 2009

Re: [Pharo-project] Complex number support discussion

by Schwab,Wilhelm K

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(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br Sent: Friday, August 14, 2009 4:39 PM To: Pharo-project(a)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(a)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(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br Sent: Friday, August 14, 2009 3:41 PM To: Pharo-project(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > __________________________ _____________________ > Pharo-project mailing list > Pharo-project(a)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(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 14, 2009

Re: [Pharo-project] Create a changeset for an entire package?

by csrabak＠bol.com.br

Aug. 14, 2009

Re: [Pharo-project] Complex number support discussion

by csrabak＠bol.com.br

Aug. 14, 2009

Re: [Pharo-project] Create a changeset for an entire package?

by Schwab,Wilhelm K

This sounds like something Monticello probably does. I **think** you could prepare an .mcz file and then others can place same in a repository, open that and browse the code w/o changing their image. I am striking out badly trying to find a quick place to test the idea, but perhaps an expert can teach us both something. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Friday, August 14, 2009 4:13 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Create a changeset for an entire package? Javier: You can use the change sorter which is in right button -> tools -> change sorter. There, in any of the panes you can see that there is a unnamed changeset with all of your changes. Then you can create a new changeset with right button -> "new changeset" and put a name: "XXXXchange". Then you can move from right to left or left to right any of the changes you want to include. Once you have in your changes all you want, right button on the changeset -> fileout. And in the directory where the image is, you will have a XXXXchange.cs. Does this help? Best, Mariano 2009/8/14 Javier PimÃ¡s <elpochodelagente(a)gmail.com<mailto:elpochodelagente@gmail.com>> It seems fixing bugs is not the only hard part... I've a bunch of fixes for GLCanvas, and a small proposed change for the class browser but I can't find a way to export a diff of all the changed packages, nor a diff of an entire package nor a diff of a class so anybody can see the changes before commiting... Do I have to file out every class I changed? there has to some easier way. Thanks, Javier. -- Javier PimÃ¡s Ciudad de Buenos Aires _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 14, 2009

Re: [Pharo-project] Complex number support discussion

by Schwab,Wilhelm K

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(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br Sent: Friday, August 14, 2009 3:41 PM To: Pharo-project(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)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(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 14, 2009