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