2009/8/16 <csrabak@bol.com.br>:
Your first example is interesting. It boils down to two design aspects:
If you need Complex numbers in the same application, you need to refactor the code to:
length := (something positive) ifTrue:[something sqrt ] IfFalse: Error do: [ 5 ].
i'm sure you meant length := (something positive) ifTrue:[something sqrt ] IfFalse: [ 5 ] but then #positive is a test which defined as positive ^ self > 0 and we getting back to discussion , what is the meaning of #> or #< operator for complex values.
array := Array new: length.
The application does not complex results at all and through the mechanism Pharo team will decide upon this kind of support will be disabled.
About the remaining of discussion, we need to remember all the time Pharo [Smalltalk] is a programming environment that has come concrete in bits at some time in order to become operative (from this onset I think the abusedComplex should trow errors as adequate).
The need for Fraction, Float and Integer in most programming languages (Smalltalk included) is more often than not for the sake of efficiency or simplification of the underlying code than for mathematical rigour.
So as right as you are that 13/3 returning asFraction does not change the "mathematical meaning of the value" in Smalltalk this is a correct assertion, but in a lot of other environments it is not! They are different representations of numbers that have to be treated as such.
In a lot languages I'm versed on, writing 5e100 can only mean an 80 bit float (in most HW) because it is the only way of storing such a beast. In Smalltalk you ask for the class of this and get LargePositiveInteger (Pharo). In Smalltalk 5e100 is syntatic sugar for not having to write one hundred zeros.
So, when we decide in certain things in programming language you're making decisions on how to model certain aspects of the problem domain.
Smalltalk in the arithmetical part decide to postpone as much as possible the loss of precision of the result. It is an expected behaviour in this language.
Once you put Complex in the Smalltalk paradigm, I think we should preserve as much as possible this design decision made at the start of the language. From a programming POV -4 sqrt mapping from Real to Imaginary (Complex) is homologous to 13 / 3 giving a Fraction. Overall is a modeling of the world.
BTW, this is why I think having Complex to only have Float members is not a nice design decision...
ageed. Its can hold any values representing the value from a Real set. But as soon as one of its member start holding someting different (Complex) - you are in trouble. I simply wanted to illustrate you that passing values to code which not expecting the Complex values having same side effect as passing a Complex values to members of Complex value (real/imaginary) part, and state that its ok. That's why its is good to have separation from functions which operating with reals only and can NEVER return anything else than real values from functions which can return complex values.
Em 15/08/2009 18:27, Igor Stasenko < siguctua@gmail.com > escreveu:
2009/8/15 :
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 represe ntation 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 sho uld 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 s pend 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 Phar o-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 P har 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.
_______________________________________________ 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.