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 < [hidden email] > escreveu:

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


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

> John,
>
> If I may be so presumptuous, the answer is to have people use #asComplex
> when they want complex results. -2 sqrt throws an error; -2 asComplex sqrt
> gives the complex (imaginary) result. Then we break no old code, we offer
> useful new features with minimal effort required to invoke them.
>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of John M
> McIntosh
> Sent: Friday, August 14, 2009 4:55 PM
> To: [hidden email] .fr
> Subject: Re: [Pharo-project] Complex number support discussion
>
>
> On 14-Aug-09, at 1:04 PM, Schwab,Wilhelm K wrote:
>
>> John,
>>
>> That is not far from the eveolving conscensous opinion - I think we
>> can indeed claim to have a collective desire to leave integers and
>> floats as they are. One concern I have about your suggestion is what
>> happens when the user loads the complex package? Does existing code
>> break? It would given Ken's proposal. There are alternatives, and
>> they are discussed in this fairly extensive thread.
>>
>> Besides, someone wanting complex numbers will look for and load a
>> package to support them, as long as it is good code. Complex is fine
>> as far as it goes; some FFI magic to benefit from GSL functionality
>> would be nice. We should also have an analog to FloatArray that has
>> complex entries; again, a wrapper onto GSL would be a nice addition.
>>
>> I have no power over Ken; he can build what he wants. I would like to
>> see his energy directed toward creating something we can all use. I
>> suggest a layered proposal on the wiki and up or down votes on what
>> becomes part of Pharo. If the vote(s) split, we have benevolent
>> dictators to sort it out.
>>
>> Bill
>
> Ah, yes well I think I lost the 0.2 = (1/2) argument, so anything goes.
>
> I think the choice is either numbers + complex work as expected, or you just
> offer number then offer to load the complex logic as soon as someone wants
> -2 sqrt.
>
> Obviously the problem here is that for a vast range of programmers if you
> offer up -2 sqrt by default and it does not throw an excepti on they will be
> confused. Some of them likely have NO idea what a complex number is.
>
> Random thoughts.
>
> No-doubt there are abuses of math to string where people assume you have an
> integer like thing versus a complex number string.
>
>
> --
> =
> =
> =
> ========================================================================
> John M. McIntosh Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> =
> =
> =
> ========================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 < [hidden email] > 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Friday, August 14, 2009 7:16 PM
To: [hidden email]
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 < [hidden email] > escreveu:

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


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

> John,
>
> If I may be so presumptuous, the answer is to have people use #asComplex
> when they want complex results. -2 sqrt throws an error; -2 asComplex sqrt
> gives the complex (imaginary) result. Then we break no old code, we offer
> useful new features with minimal effort required to invoke them.
>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of John M
> McIntosh
> Sent: Friday, August 14, 2009 4:55 PM
> To: [hidden email] .fr
> Subject: Re: [Pharo-project] Complex number support discussion
>
>
> On 14-Aug-09, at 1:04 PM, Schwab,Wilhelm K wrote:
>
>> John,
>>
>> That is not far from the eveolving conscensous opinion - I think we
>> can indeed claim to have a collective desire to leave integers and
>> floats as they are. One concern I have about your suggestion is what
>> happens when the user loads the complex package? Does existing code
>> break? It would given Ken's proposal. There are alternatives, and
>> they are discussed in this fairly extensive thread.
>>
>> Besides, someone wanting complex numbers will look for and load a
>> package to support them, as long as it is good code. Complex is fine
>> as far as it goes; some FFI magic to benefit from GSL functionality
>> would be nice. We should also have an analog to FloatArray that has
>> complex entries; again, a wrapper onto GSL would be a nice addition.
>>
>> I have no power over Ken; he can build what he wants. I would like to
>> see his energy directed toward creating something we can all use. I
>> suggest a layered proposal on the wiki and up or down votes on what
>> becomes part of Pharo. If the vote(s) split, we have benevolent
>> dictators to sort it out.
>>
>> Bill
>
> Ah, yes well I think I lost the 0.2 = (1/2) argument, so anything goes.
>
> I think the choice is either numbers + complex work as expected, or you just
> offer number then offer to load the complex logic as soon as someone wants
> -2 sqrt.
>
> Obviously the problem here is that for a vast r ange of programmers if you
> offer up -2 sqrt by default and it does not throw an excepti on they will be
> confused. Some of them likely have NO idea what a complex number is.
>
> Random thoughts.
>
> No-doubt there are abuses of math to string where people assume you have an
> integer like thing versus a complex number string.
>
>
> --
> =
> =
> =
> ========================================================================
> John M. McIntosh Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> =
> =
> =
> ========================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list

& gt; [hidden email]
> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 < [hidden email] > 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Friday, August 14, 2009 7:16 PM
To: [hidden email]
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 < [hidden email] > escreveu:

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


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

> John,
>
> If I may be so presumptuous, the answer is to have people use #asComplex
> when they want complex results. -2 sqrt throws an error; -2 asComplex sqrt
> gives the complex (imaginary) result. Then we break no old code, we offer
> useful new features with minimal effort required to invoke them.
>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of John M
> McIntosh
> Sent: Friday, August 14, 2009 4:55 PM
> To: [hidden email] .fr
> Subject: Re: [Pharo-project] Complex number support discussion
>
>
> On 14-Aug-09, at 1:04 PM, Schwab,Wilhelm K wrote:
>
>> John,
>>
>> That is not far from the eveolving conscensous opinion - I think we
>> can indeed claim to have a collective desire to leave integers and
>> floats as they are. One concern I have about your suggestion is what
>> happens when the user loads the complex package? Does existing code
>> break? It would given Ken's proposal. There are alternatives, and
>> they are discussed in this fairly extensive thread.
>>
>> Besides, someone wanting complex numbers will look for and load a
>> package to support them, as long as it is good code. Complex is fine
>> as far as it goes; some FFI magic to benefit from GSL functionality
>> would be nice. We should also have an analog to FloatArray that has
>> complex entries; again, a wrapper onto GSL would be a nice addition.
>>
>> I have no power over Ken; he can build what he wants. I would like to
>> see his energy directed toward creating something we can all use. I
>> suggest a layered proposal on the wiki and up or down votes on what
>> becomes part of Pharo. If the vote(s) split, we have benevolent
>> dictators to sort it out.
>>
>> Bill
>
> Ah, yes well I think I lost the 0.2 = (1/2) argument, so anything goes.
>
> I think the choice is either numbers + complex work as expected, or you just
> offer number then offer to load the complex logic as soon as someone wants
> -2 sqrt.
>
> Obviously the problem here is that for a vast r ange of programmers if you
> offer up -2 sqrt by default and it does not throw an excepti on they will be
> confused. Some of them likely have NO idea what a complex number is.
>
> Random thoughts.
>
> No-doubt there are abuses of math to string where people assume you have an
> integer like thing versus a complex number string.
>
>
> --
> =
> =
> =
> ========================================================================
> John M. McIntosh Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> =
> =
> =
> ========================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list

& gt; [hidden email]
> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 < [hidden email] > 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

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 < [hidden email] > 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

Igor,

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

Em 15/08/2009 14:35, Igor Stasenko < [hidden email] > escreveu:

2009/8/15 :
> It helps to undestand your suggestion.
>
> It does not help to make it Smalltalk friendly, my meaning of that being the
> "principle of least surprise".
>
least suprise for who?
For you it could be the least surprise.
For me, and for other people it would be a big surprise.
So, please give a better/different reasoning, why in a presence of
Complex numbers, a functions
which operating with Real numbers should change their behavior.

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

Array new: 0.2i

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

> If complex math is to be allowed a natural consequence is that a lot of
> functions would retur n complex answers for real arguments.
>
> How would then have Pharo Smalltalk behave in a case of computing a
> reactance: X = jωL?
>
> anInductance being Number and complexFrequency obviously being Complex:
>
> aReactance := anInductance * complexFrequency
>
> Em 15/08/2009 13:55, Schwab,Wilhelm K < [hidden email] > escreveu:
>
> Nothing tricky: just that methods answering complex results should be
> defined only by things tha are already complex.  -1 sqrt blows up; -1
> asComplex answers i.  There would be no imlicit conversion between real and
> complex, allowing the base system to perform as it does now and still
> allowing all the complex number crunching anyone wants to do. Does that
> help?
> Bill
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-pr [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 < [hidden email] > 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Saturday, August 15, 2009 12:18 PM
To: [hidden email]
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 < [hidden email] > 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

Yes this is strong reasoning.  In fact nowadays a similar argument is used to explain why a hierarchy of geometric plane figures shall not have Circle as subclass of Ellipse (same for Square versus Rectangle). See http://en.wikipedia.org/wiki/Circle-ellipse_problem for an elaboration.

It follows from the "Liskov Substitution Principle".

Em 15/08/2009 17:17, Igor Stasenko < [hidden email] > escreveu:

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

Here what reads the Magnitude class:

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

---

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

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

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

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

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

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 < [hidden email] > 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Saturday, August 15, 2009 12:18 PM
To: [hidden email]
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 < [hidden email] > 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

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

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 )

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.

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

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

Hope it is explicit now.

Em 15/08/2009 17:36, Igor Stasenko < [hidden email] > escreveu:

2009/8/15 :
> Igor,
>
> I think I don't undersand your point. What is the mathematical significance
> of an Array of size 0.2i?
>
the significance is not mathematical, it is practical: how many hours
one should spend fixing all 'surprises' which
you can introduce if not carefully add Complex support.

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

> Em 15/08/2009 14:35, Igor Stasenko < [hidden email] > escreveu:
& gt;

> 2009/8/15 :
>> It helps to undestand your suggestion.
>>
>> It does not help to make it Smalltalk friendly, my meaning of that being
>> the
>> "principle of least surprise".
>>
> least suprise for who?
> For you it could be the least surprise.
> For me, and for other people it would be a big surprise.
> So, please give a better/different reasoning, why in a presence of
> Complex numbers, a functions
> which operating with Real numbers should change their behavior.
>
> Integers are subset of Real set and Real is a subset of Complex, then
> one could happily write:
>
> Array new: 0.2i
>
> and following your reasoning, the above is good way to write a code
> and it should work well.
>
>> If complex math is to be allowed a natural consequence is that a lot of
>> ; functions would retur n complex answers for real arguments.
>>
>> How would then have Pharo Smalltalk behave in a case of computing a
>> reactance: X = jωL?
>>
>> anInductance being Number and complexFrequency obviously being Complex:
>>
>> aReactance := anInductance * complexFrequency
>>
>> Em 15/08/2009 13:55, Schwab,Wilhelm K < [hidden email] > escreveu:
>>
>> Nothing tricky: just that methods answering complex results should be
>> defined only by things tha are already complex.  -1 sqrt blows up; -1
>> asComplex answers i.  There would be no imlicit conversion between real
>> and
>> complex, allowing the base system to perform as it does now and still
>> allowing all the complex number crunching anyone wants to do. Does that
>> help?
>> Bill
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-pr [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
Phar [hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 < [hidden email] > 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Saturday, August 15, 2009 3:28 PM
To: [hidden email]
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 < [hidden email] > 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Saturday, August 15, 2009 12:18 PM
To: [hidden email]
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 < [hidden email] > 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

In the context of Complex numbers scalar can be used to call the Real numbers as complex numbers are homomorphous to 2 dimension vectos see: 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 :-)

Em 15/08/2009 17:49, Igor Stasenko < [hidden email] > escreveu:

2009/8/15 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)
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
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.

>
> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
> Sent: Saturday, August 15, 2009 3:18 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Complex number support discussion
>
> Btw, here is another argument why Complex is not part of Number class hierarchy.
>
> Here what reads the Magnitude class:
>
> I'm the abstract class Magnitude that provides common protocol for objects that have the ability to be compared along a ___linear dimension___, such as dates or times.
> Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as Character and LookupKey.
>
> ---
>
> Since complex values is not scalars and hence cannot be compared along a linear dimension, they could not be inherited from a Magnitude.
>
> Btw this comment seems veeery dated, because it refers to ArithmeticValue, which not present in current class hierarchy :)
>
> As you stated earlier that Real set is a subset of Complex, then if you want to see both of them lying in same class hierarchy, it could require a major redesign the class hierarchy to make Complex a base class, and Float/Integer a subclasses.
> Since subclasses are specialization of superclasses, and superclass always is more generic than any of its subclass.
>
> Others could step up and say: hey scalars could be seen as a specialized kind of vectors, and vectors could be seen as a specialized kind of matrices, so lets make Matrix to be the ultimate superclass, and then Vector, and then Scalar etc etc..
>
> I can only guess, how far we can go with such generalization(s).
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list

&g t; [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project