2009/8/15 <csrabak@bol.com.br>:
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 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.
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 :)
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
_______________________________________________ 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.