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