[Pharo-project] Complex number support discussion

[Ken.Dickey]

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.

[Schwab,Wilhelm K]

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: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Ken.Dickey
Sent: Thursday, August 13, 2009 12:09 PM
To: Pharo-project at lists.gforge.inria.fr
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.

[Ken.Dickey]

Schwab,Wilhelm K" <bschwab at anest.ufl.edu>

Post by 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 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

[Schwab,Wilhelm K]

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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Ken.Dickey
Sent: Friday, August 14, 2009 10:38 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion

Schwab,Wilhelm K" <bschwab at anest.ufl.edu>

Post by 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 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

[John McIntosh]

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

Post by Schwab,Wilhelm K
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 at lists.gforge.inria.fr
[mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Ken.Dickey
Sent: Friday, August 14, 2009 10:38 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion
Schwab,Wilhelm K" <bschwab at anest.ufl.edu>

Post by 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 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Schwab,Wilhelm K]

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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of John McIntosh
Sent: Friday, August 14, 2009 1:49 PM
To: Pharo-project at 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

Post by Schwab,Wilhelm K
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 at lists.gforge.inria.fr
[mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Ken.Dickey
Sent: Friday, August 14, 2009 10:38 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion
Schwab,Wilhelm K" <bschwab at anest.ufl.edu>

Post by 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 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090814/d97160b3/attachment.html>

[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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Friday, August 14, 2009 3:41 PM
To: Pharo-project at 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 at 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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of John McIntosh
Sent: Friday, August 14, 2009 1:49 PM
To: Pharo-project at 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

Post by Schwab,Wilhelm K
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 at lists.gforge.inria.fr
[mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Ken.Dickey
Sent: Friday, August 14, 2009 10:38 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion
Schwab,Wilhelm K"

Post by 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090814/37fbb481/attachment.html>

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090814/69c95b54/attachment.html>

[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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Friday, August 14, 2009 4:39 PM
To: Pharo-project at 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 at 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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Friday, August 14, 2009 3:41 PM
To: Pharo-project at 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 at 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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of John McIntosh
Sent: Friday, August 14, 2009 1:49 PM
To: Pharo-project at 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

Post by Schwab,Wilhelm K
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 at lists.gforge.inria.fr
[mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Ken.Dickey
Sent: Friday, August 14, 2009 10:38 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion
Schwab,Wilhelm K"

Post by 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
__________________________ _____________________
Pharo-project mailing list
Pharo-project at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090814/60dacbc1/attachment.html>

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090814/678a9a22/attachment.html>

[Schwab,Wilhelm K]

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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Friday, August 14, 2009 6:07 PM
To: Pharo-project at 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 at 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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Friday, August 14, 2009 4:39 PM
To: Pharo-project at 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 at 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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Friday, August 14, 2009 3:41 PM
To: Pharo-project at 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 at 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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of John McIntosh
Sent: Friday, August 14, 2009 1:49 PM
To: Pharo-project at 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

Post by Schwab,Wilhelm K
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 at lists.gforge.inria.fr
[mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Ken.Dickey
Sent: Friday, August 14, 2009 10:38 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion
Schwab,Wilhelm K"

Post by 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 at lists.gforge.inria. fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
__________________________ _____________________
Pharo-project mailing list
Pharo-project at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr< br />http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090814/074eb7e6/attachment.html>

[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

Post by Schwab,Wilhelm K
can someone tell me what a heck is an KedamaFloatArray??

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

[Schwab,Wilhelm K]

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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of John M McIntosh
Sent: Friday, August 14, 2009 4:59 PM
To: Pharo-project at 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

Post by Schwab,Wilhelm K
can someone tell me what a heck is an KedamaFloatArray??

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

[John M McIntosh]

Post by Schwab,Wilhelm K
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 at smalltalkconsulting.com> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================

[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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of John M McIntosh
Sent: Friday, August 14, 2009 4:55 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion

Post by Schwab,Wilhelm K
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 at smalltalkconsulting.com> Twitter:
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================

[John McIntosh]

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

Post 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 at lists.gforge.inria.fr
[mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of John M
McIntosh
Sent: Friday, August 14, 2009 4:55 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion

Post by Schwab,Wilhelm K
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.
--
=
=
=
========================================================================
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090814/568c473f/attachment.html>

[Schwab,Wilhelm K]

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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Friday, August 14, 2009 7:16 PM
To: Pharo-project at 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 at 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?

Post 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 at lists.gforge.inria.fr
[mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of John M
McIntosh
Sent: Friday, August 14, 2009 4:55 PM
To: Pharo-project at lists.gforge.inria .fr
Subject: Re: [Pharo-project] Complex number support discussion

Post by Schwab,Wilhelm K
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.
--
=
=
=
========================================================================
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
_______________________________________________
Pharo-project mailing list
Pharo-project at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090814/0fec517e/attachment.html>

[Igor Stasenko]

+1
no globals, please :)

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 at lists.gforge.inria.fr
[mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of
csrabak at bol.com.br
Sent: Friday, August 14, 2009 7:16 PM
To: Pharo-project at 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.
Yes but we usually don't do explicit casting Like 2 asFloat * 3.0
We could but where does the implicit type conversion lie?

Post 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 at lists.gforge.inria.fr
[mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of John M
McIntosh
Sent: Friday, August 14, 2009 4:55 PM
To: Pharo-project at lists.gforge.inria .fr
Subject: Re: [Pharo-project] Complex number support discussion

Post by Schwab,Wilhelm K
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.
--
=
=
=
========================================================================
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
_______________________________________________
Pharo-project mailing list
Pharo-project at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/82b6f469/attachment.html>

[Schwab,Wilhelm K]

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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Saturday, August 15, 2009 11:08 AM
To: Pharo-project at 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 at 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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Friday, August 14, 2009 7:16 PM
To: Pharo-project at 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 at 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?

Post 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 at lists.gforge.inria.fr
[mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of John M
McIntosh
Sent: Friday, August 14, 2009 4:55 PM
To: Pharo-project at lists.gforge.inria .fr
Subject: Re: [Pharo-project] Complex number support discussion

Post by Schwab,Wilhelm K
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.
--
=
=
=
========================================================================
squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
_______________________________________________
Pharo-project mailing list

& gt; Pharo-project at lists.gforge.inria.fr

Post by Schwab,Wilhelm K
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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/2e7d20db/attachment.html>

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/8c2dff95/attachment.html>

[Igor Stasenko]

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?
aReactance := anInductance * complexFrequency
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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/2b20ba00/attachment.html>

[Igor Stasenko]

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.

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
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?
aReactance := anInductance * complexFrequency
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 at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/2d250164/attachment.html>

[Igor Stasenko]

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
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 :)

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.
& gt;

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

&gt ; 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?
aReactance := anInductance * complexFrequency
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 at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/cbbbd585/attachment.html>

[Schwab,Wilhelm K]

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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Saturday, August 15, 2009 5:05 PM
To: Pharo-project at 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...

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
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 :)

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.
& gt;

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
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?>>>
aReactance := anInductance * complexFrequency
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 at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/0928ef04/attachment.html>

[Igor Stasenko]

Post by Schwab,Wilhelm K
If you need Complex numbers in the same application, you need to refactor
length := (something positive) ifTrue:[something sqrt ] IfFalse: Error do: [
5 ].

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

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.

Post by Schwab,Wilhelm K
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...

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.

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.

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.

Post by Schwab,Wilhelm K

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

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.
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
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 :)

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.
& gt;

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
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?
aReactance := anInductance * complexFrequency
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 at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at 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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[csrabak]

Post by Igor Stasenko

Post by Schwab,Wilhelm K
If you need Complex numbers in the same application, you need to refactor
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.

Post by Igor Stasenko
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]

Post by Igor Stasenko

Post by Schwab,Wilhelm K
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.

Post by Igor Stasenko
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. . .

Post by Igor Stasenko
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

[Schwab,Wilhelm K]

Cesar,

Storing integers and fractions for the real and imaginary parts of a complex number will be of benefit in a very small number of cases. Most uses of complex numbers involve transcendental functions that will not produce "nice" results in the general case.

Your closing paragraphs below, well, let's just say I disagree. If you and Ken, separately or together, put proposal(s) on the wiki, I will gladly respond with comments on the pages and/or counter proposal(s), and would be glad to work with Sig on same. As for this seemingly endless chain of email rehashing the same points, I'm done.

Bill



-----Original Message-----
From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Saturday, August 15, 2009 9:04 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion

Post by Igor Stasenko

Post by Schwab,Wilhelm K
If you need Complex numbers in the same application, you need 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.

Post by Igor Stasenko
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]

Post by Igor Stasenko

Post by Schwab,Wilhelm K
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.

Post by Igor Stasenko
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. . .

Post by Igor Stasenko
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

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090816/e2a99c82/attachment.html>

[Schwab,Wilhelm K]

I have indeed listed my objections - several times; you simply seem to not want to acknowledge the objections. Please make your pososal on the wiki, and Sig and I will respond in kind.

Bill

________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Sunday, August 16, 2009 3:01 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion


Wilhelm,

About your point on "benefit a very small number of cases" I paraphase yourself "...is in the code that is not in your image.": if we stick to only our personal experiences and don't think about the future users of the package, we'll arrive at a 'domestic' or 'local' solution which will be useful on another set of not too many number of cases and make Pharo less than an option (for work with this kind of needs) for people that still do not use Pharo.

I see you state your disagreements and do not explain on what grounds so I cannot elaborate, also as it seems the desire of the interested community to go ahead and keep the discussion on the wiki, I'll read what's there and see if is anything else I can contribute.

On a separate thread I'll put on a more general terms my thoughts on the broader theme of use of Smalltalk for more numeric intensive applications and what I think we could improve in Pharo to make easier for programmers that decide the use of this platform.

Em 16/08/2009 00:32, Schwab,Wilhelm K < bschwab at anest.ufl.edu > escreveu:

Cesar,

Storing integers and fractions for the real and imaginary parts of a complex number will be of benefit in a very small number of cases. Most uses of complex numbers involve transcendental functions that will not produce "nice" results in the general case.

Your closing paragraphs below, well, let's just say I disagree. If you and Ken, separately or together, put proposal(s) on the wiki, I will gladly respond with comments on the pages and/or counter proposal(s), and would be glad to work with Sig on same. As for this seemingly endless chain of email rehashing the same points, I'm done.

Bill



-----Original Message-----
From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Saturday, August 15, 2009 9:04 PM
To: Ph aro-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion

Post by Igor Stasenko

Post by Schwab,Wilhelm K
If you need Complex numbers in the same application, you need 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.

Post by Igor Stasenko
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]

Post by Igor Stasenko

Post by Schwab,Wilhelm K
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 mem bers
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.

Post by Igor Stasenko
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. . .

Post by Igor Stasenko
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


___ ____________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090816/c4283a3a/attachment.html>

[Igor Stasenko]

Post by csrabak

Post by Igor Stasenko

Post by Schwab,Wilhelm K
If you need Complex numbers in the same application, you need to refactor
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.

Post by Igor Stasenko
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?

Post by csrabak
[snipped]

Post by Igor Stasenko

Post by Schwab,Wilhelm K
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...

Post by csrabak

Post by Igor Stasenko
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. . .

Post by Igor Stasenko
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?

Post by csrabak
The separation you advocate make these advantages be lost.
--
Cesar Rabak
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Schwab,Wilhelm K]

One programmer's expectation is another's broken code, so "surprise" is not a good standard. Perserving long-standing behavior is. Your multiplication example is esaily handled by double-dispatch, and that would not violate "no implicit coercion" because one of the participants is already complex.


________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Saturday, August 15, 2009 12:18 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion


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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/92a5ff94/attachment.html>

[Igor Stasenko]

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).

[Schwab,Wilhelm K]

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.

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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor Stasenko
Sent: Saturday, August 15, 2009 3:18 PM
To: Pharo-project at 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.

[Igor Stasenko]

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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor Stasenko
Sent: Saturday, August 15, 2009 3:18 PM
To: Pharo-project at 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.
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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

[Schwab,Wilhelm K]

Interesting!



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

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 at lists.gforge.inria.fr
[mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor
Stasenko
Sent: Saturday, August 15, 2009 3:18 PM
To: Pharo-project at 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.
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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
Best regards,
Igor Stasenko AKA sig.

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/73bd91cd/attachment.html>

[Igor Stasenko]

In the context of Complex numbers scalar can be used to call the Real
http://en.wikipedia.org/wiki/Vector_space. Also a vector space can be
created starting from a complex Field instead of Real one.
So in this conversation Igor's use of scalar scales well :-)

Yup.
But it is unlikely, that in operations where you expecting scalars or
some exact kind (real or complex) ,
you can freely substitute a different kind(s) of scalars - like
n-dimention vectors or even matrices and be sure that your code works
correctly as before.

Post by Schwab,Wilhelm K
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)
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
nume ric. 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.

Post by Schwab,Wilhelm K
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 at lists.gforge.inria.fr
[mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor
Stasenko
Sent: Saturday, August 15, 2009 3:18 PM
To: Pharo-project at 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.
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 at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list

&g t; Pharo-project at lists.gforge.inria.fr

Post by Schwab,Wilhelm K
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/020e3856/attachment.html>

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/e4281a83/attachment.html>

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/f4806bf2/attachment.html>

[Schwab,Wilhelm K]

Sorry, I do not follow, but I am saying that

3 * 4i

makes every bit as much sense as

2/3 * 4.2

and would be implemented by the same mechanism. The programmer's desire to admit comlex and floating point results, respectfully, is clear from the objects that appear in the calculation. However, spuriously injecting complex numbers into what might be real-only computation will as often as not be unhelpful, and a "surprise."


Bill


________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Saturday, August 15, 2009 3:28 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion


So we have to establish when Number>>i will bring an imaginary (hint [for example]: just when Complex is loaded) or something else due programmer discretion?

Or your proposal is that double-dispatch only occur if we have Imaginary new: aNumber?

Em 15/08/2009 15:26, Schwab,Wilhelm K < bschwab at anest.ufl.edu > escreveu:

One programmer's expectation is another's broken code, so "surprise" is not a good standard. Perserving long-standing behavior is. Your multiplication example is esaily handled by double-dispatch, and that would not violate "no implicit coercion" because one of the participants is already complex.

________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Saturday, August 15, 2009 12:18 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion

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

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/489e5ebd/attachment.html>

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/c18d530e/attachment.html>

[Schwab,Wilhelm K]

When I write 2i, I am not really thinking of #i, though one would not doubt end up with that as a way to create complex numbers. To be clear, I have considered and am (currently) opposed to implicit conversions to complex by any elementary or special functions. That propbably reduces to "no" methods of Number and sub-classes answering Complex results. The exceptions would be #asComplex and arithmetic operators.


________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Saturday, August 15, 2009 4:29 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion


Yes, these are the simple to discuss cases as the Number>>i message has been explicitly put.

The core of the discussion is the result of certain operations which once complex number support had been switched on should need all the explicit conversions or more application wide (I do agree that system wide flags are to be avoided) suffices to indicate that programmer's desire.

Em 15/08/2009 17:38, Schwab,Wilhelm K < bschwab at anest.ufl.edu > escreveu:

Sorry, I do not follow, but I am saying that
3 * 4i
makes every bit as much sense as
2/3 * 4.2
and would be implemented by the same mechanism. The programmer's desire to admit comlex and floating point results, respectfully, is clear from the objects that appear in the calculation. However, spuriously injecting complex numbers into what might be real-only computation will as often as not be unhelpful, and a "surprise."

Bill

________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Saturday, August 15, 2009 3:28 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion

So we have to establish when Number>>i will bring an imaginary (hint [for example]: just when Complex is loaded) or something else due programmer discretion?

Or your proposal is that double-dispatch only occur if we have Imaginary new: aNumber?

Em 15/08/2009 15:26, Schwab,Wilhelm K < bschwab at anest.ufl.edu > escreveu:

One programmer's expectation is another's broken code, so "surprise" is not a good standard. Perserving long-standing behavior is. Your multiplication example is esaily handled by double-dispatch, and that would not violate "no implicit coercion" because one of the participants is already complex.

________________________________
From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of csrabak at bol.com.br
Sent: Saturday, August 15, 2009 12:18 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion

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

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090815/f42a17af/attachment.html>

[Ken.Dickey]

Post by Schwab,Wilhelm K
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

[Schwab,Wilhelm K]

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: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Ken.Dickey
Sent: Friday, August 14, 2009 6:51 PM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion

Post by Schwab,Wilhelm K
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

[Ken.Dickey]

gor Stasenko <siguctua at gmail.com>

Post by Igor Stasenko
Array new: 0.2i

Again, how is this different in pattern from dealing with
? Array new: 1/2
? Array new: -17
?...
??

-KenD

PS: ?Complex real: (0.5 + 0i) imaginary: (0 + 0i)
Complex can only have instances of Number as components. ?The lack of checks
is an error.

[csrabak]

An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20090816/992cc22c/attachment.html>