Complex number support discussion
Locked
123
123
 
|
Igor Stasenko
> P.S. diving into complex plane uncovers many potential pitfalls to those > who expecting a certain behavior of mathematical functions over a real > numbers. In first place square and square root. > It is good that with introduction of a complex numbers we can be sure that > x sqrt squared = x for any real x. > > The complex numbers gives us a impression that from now on, the square > function and squared root functions is reversable. But they are not for a > complex numbers. > In practice this means, that one, who using a complex math in his code, > should know well the properties of complex numbers, because this is not so > trivial as with real numbers & school algebra. And such people, basically > don't need the things with questionable or controversial behavior such as > #< operators on a complex plane. Then the aim of Complex package developer > should be to not introduce more confusion to people who is not using/learnt > the complex numbers, and leave attempts to help people who can - because > they could care for themselves well. I guess here I go to high school physics, where electricity and magnetism use complex numbers and relativity uses hyperbolic trig. [Perhaps 1st year physics if your high school did not cover this]. My own experience is that adapting to floating point lossage was far more painful for me than learning 2d mathematics. Again, we can remove Complex totally and make that, hyperbolic trig, ln, and so forth into loadable packages. I would recommend that the error reports for sqrt and ln (if kept) of negative numbers make mention that a loadable package exists to give the expected functionality. A minimal base image (lacking even tools, perhaps even Morphic) is certainly useful in the build process at some point. I suspect there are those who would make such an image even smaller by removing fractions and perhaps even floats. My own preference is to leverage meta-programming aspects (traits, live code, intelligent toolsets) because I think that is where Pharo/Squeak excels. I am certainly happy to pay additional computational cost for better approximations to math (e.g. interval mathematics) because I like the system to tell me where the deep and shallow waters are. A factor of two or even ten slower sounds like a lot, but as speeds continue to double every 18 months, getting the right answers rather than "the wrong answer fast" is why one puts up with slower runtime systems. $0.02, -KenD PS: Thanks all for the helpful suggestions on tightening up the math. I will take a closer look at the branch cuts and so forth. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-KenD
|
Re: Complex number support discussion
|
Ken,
A 2-10x performance hit is all the more reason why such a creation should be dormant unless specifically invoked - translation, no coercion into the controversial type. While there are uses for systems that are "smart" enough to give exact answers, most computation happens in a world of tolerances, with numbers that are not cherry picked for aesthetics. As somebody else (Sig perhaps) said, the behavior of the base system magnitude classes should not change when a different package is loaded. #asComplex is the gateway through which one can tell the system that complex numbers are expected and desired. The more you write, the more it becomes clear that there also would need to be a #asComplexSymbolic or something to invoke behavior one might expect from Maple and other symbolic systems. I strongly recommend starting with a numerical approach to a "closed system" of complex numbers. GSL provides much of what should be available, and can be mapped into Pharo by FFI/Alien. The result would get used. If you then want to compete with Maple and Mathematica, that really should be done separately. For examle, there are times when I use logs to estimate the number of digits required to hold a number, and if the argument is negative, I goofed and expect an error. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken.Dickey Sent: Thursday, August 13, 2009 12:09 PM To: [hidden email] Subject: [Pharo-project] Complex number support discussion Igor Stasenko > P.S. diving into complex plane uncovers many potential pitfalls to > those who expecting a certain behavior of mathematical functions over > a real numbers. In first place square and square root. > It is good that with introduction of a complex numbers we can be sure > that x sqrt squared = x for any real x. > > The complex numbers gives us a impression that from now on, the square > function and squared root functions is reversable. But they are not > for a complex numbers. > In practice this means, that one, who using a complex math in his > code, should know well the properties of complex numbers, because this > is not so trivial as with real numbers & school algebra. And such > people, basically don't need the things with questionable or > controversial behavior such as #< operators on a complex plane. Then > the aim of Complex package developer should be to not introduce more > confusion to people who is not using/learnt the complex numbers, and > leave attempts to help people who can - because they could care for themselves well. I guess here I go to high school physics, where electricity and magnetism use complex numbers and relativity uses hyperbolic trig. [Perhaps 1st year physics if your high school did not cover this]. My own experience is that adapting to floating point lossage was far more painful for me than learning 2d mathematics. Again, we can remove Complex totally and make that, hyperbolic trig, ln, and so forth into loadable packages. I would recommend that the error reports for sqrt and ln (if kept) of negative numbers make mention that a loadable package exists to give the expected functionality. A minimal base image (lacking even tools, perhaps even Morphic) is certainly useful in the build process at some point. I suspect there are those who would make such an image even smaller by removing fractions and perhaps even floats. My own preference is to leverage meta-programming aspects (traits, live code, intelligent toolsets) because I think that is where Pharo/Squeak excels. I am certainly happy to pay additional computational cost for better approximations to math (e.g. interval mathematics) because I like the system to tell me where the deep and shallow waters are. A factor of two or even ten slower sounds like a lot, but as speeds continue to double every 18 months, getting the right answers rather than "the wrong answer fast" is why one puts up with slower runtime systems. $0.02, -KenD PS: Thanks all for the helpful suggestions on tightening up the math. I will take a closer look at the branch cuts and so forth. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by KenDickey
Schwab,Wilhelm K" <[hidden email]>
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-KenD
|
Re: Complex number support discussion
|
|
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: [hidden email] [mailto:[hidden email]] On Behalf Of Ken.Dickey Sent: Friday, August 14, 2009 10:38 AM To: [hidden email] Subject: Re: [Pharo-project] Complex number support discussion Schwab,Wilhelm K" <[hidden email]> > 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]> 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: [hidden email] > [mailto:[hidden email]] On Behalf Of Ken.Dickey > Sent: Friday, August 14, 2009 10:38 AM > To: [hidden email] > Subject: Re: [Pharo-project] Complex number support discussion > > Schwab,Wilhelm K" <[hidden email]> >> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- =========================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Complex number support discussion
|
|
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: [hidden email] [mailto:[hidden email]] On Behalf Of John McIntosh Sent: Friday, August 14, 2009 1:49 PM To: [hidden email] 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 <[hidden email]> 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: [hidden email] > [mailto:[hidden email]] On Behalf Of > Ken.Dickey > Sent: Friday, August 14, 2009 10:38 AM > To: [hidden email] > Subject: Re: [Pharo-project] Complex number support discussion > > Schwab,Wilhelm K" <[hidden email]> >> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- =========================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 < [hidden email] > escreveu:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Complex number support discussion
|
|
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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Sent: Friday, August 14, 2009 3:41 PM To: [hidden email] 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 < [hidden email] > escreveu:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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. 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 < [hidden email] > escreveu:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Complex number support discussion
|
|
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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Sent: Friday, August 14, 2009 4:39 PM To: [hidden email] 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. 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 < [hidden email] > escreveu:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
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 <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by csrabak
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, [hidden email] wrote: > can someone tell me what a heck is an KedamaFloatArray?? > -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Complex number support discussion
|
|
In reply to this post by johnmci
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: [hidden email] [mailto:[hidden email]] On Behalf Of John M McIntosh Sent: Friday, August 14, 2009 4:55 PM To: [hidden email] 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 <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Complex number support discussion
|
|
In reply to this post by johnmci
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: [hidden email] [mailto:[hidden email]] On Behalf Of John M McIntosh Sent: Friday, August 14, 2009 4:59 PM To: [hidden email] 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, [hidden email] wrote: > can someone tell me what a heck is an KedamaFloatArray?? > -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
OK. IIUC then any Number when stored in a Array of these will be copied and coerced to the specific type, is it right?
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Complex number support discussion
|
|
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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Sent: Friday, August 14, 2009 6:07 PM To: [hidden email] 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?
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by KenDickey
> 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, Many thanks. I had missed the reference to "wiki" on http://pharo-project.org/community and did not see mention on http://pharo-project.org/documentation/faq or http://pharo-project.org/about/organization Up to now I had seen zero references to proper process. In particular, I would have followed http://code.google.com/p/pharo/wiki/HowToContribute rather than dumping code here. I'll be happy to use the wiki for a proposal. Other contributor newbie suggestions welcomed. If nobody tells me I don't know. Thanks again, -KenD _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-KenD
|
|
|
In reply to this post by Schwab,Wilhelm K
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 <[hidden email]> 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: [hidden email] > [mailto:[hidden email]] On Behalf Of John M > McIntosh > Sent: Friday, August 14, 2009 4:55 PM > To: [hidden email] > 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 <[hidden email]> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- =========================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
That's why I suggest (once Complex be loaded) a flag something like Smalltalk complexResultsOn and its counterpart to turn off be used instead.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Complex number support discussion
|
|
In reply to this post by KenDickey
Ken,
Sounds good. Again, I strongly suggest doing it in layers so that a base package can be installed without changing code that depends on current behavior. Then if you want to have another package on top of that to push the envelop, do so with our blessing. You might look at my proposal on streams. I honestly think that the breaking changes approach is the correct one, but it could be a tough sell, so I have a backup plan to allow me to work safely even if the big idea does not sell. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken.Dickey Sent: Friday, August 14, 2009 6:51 PM To: [hidden email] Subject: Re: [Pharo-project] Complex number support discussion > 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, Many thanks. I had missed the reference to "wiki" on http://pharo-project.org/community and did not see mention on http://pharo-project.org/documentation/faq or http://pharo-project.org/about/organization Up to now I had seen zero references to proper process. In particular, I would have followed http://code.google.com/p/pharo/wiki/HowToContribute rather than dumping code here. I'll be happy to use the wiki for a proposal. Other contributor newbie suggestions welcomed. If nobody tells me I don't know. Thanks again, -KenD _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |