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 < siguctua@gmail.com > 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 < siguctua@gmail.com > 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 < 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
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-pr oject@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@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@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@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project