2009/8/16 <csrabak@bol.com.br>:
Em 15/08/2009 19:21, Igor Stasenko < siguctua@gmail.com > escreveu:
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 ]
I'm not so sure ;-) I thought your block with a five inside some kind of error message, but this is not that important. It seems you get the spirit and considering my mistake on interpreting your example your correction is OK.
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.
NO!! Because all this discussion is being on the possibility of having an operation on a _non_ Complex number return a Complex result, so the test is kosher and you can go. _If_ you return an argument that something already was a complex number then all this argument is moot...
Let me restate where we started from. We started from point: Array new: 0.2i which simply shown that there are many places where complex numbers appearance (or even non-integer numbers) is undesirable. But since you insisting on introducing the functions which do implicit conversions under the hood, without real intent of developer, how he could be sure that above not happens? And then same, in next example: (something positive) ifTrue:[something sqrt ] IfFalse: [ 5 ] how you can be sure that 'something' is not complex number already, and therefore, sending #positive to it is meaningless?
[snipped]
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.
It depends. Â My reasoning was that if we maintain the members as two numbers in Smalltalk sense and let the mechanisms choose the representation (actually the classes), a lot of possible problems with Complex numbers not coalescing back to real due non canceling of imaginary parts (due rounding errors) could be minimized.
This could make Pharo Smalltalk more interesting than using other languages where all the problems with numerical accuracy have to be taken in account.
Rounding errors plaguing the Real numbers in the same way, and i don't see much difference here. Where i see the difference is, that for real numbers you need to represent a single value (and no matter by what you representing it - because it is still Real value), while for complex number you need a two distinct values (but they could be represented by any real values you desire). But since you don't see such difference and advocating that complex is just a 'more generic' representation of real, an no-one should care where it seamlessly appears and when (because of implicit coercions), then give me the answer, where you want to stop: 1. Two different ways representing real value: 1/2 <=> 0.5 2. Two different ways representing ?same? value: 0.5 <=> 0.5 + 0i 3. Three different ways representing ?same? value: 0.5 <=> 0.5 + 0i <=> Complex real: (0.5 + 0i) imaginary: (0 + 0i) 4. Four different ways representing ?same? value: 0.5 <=> 0.5 + 0i <=> Complex real: (0.5 + 0i) imaginary: (0 + 0i) <=> Complex real: (0.5 + (Complex real: 0+ 0i imaginary: 0 + 0i)) imaginary: (0 + 0i) and so on...
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.
I'm sorry to inform you that until now you have not achieved your intent in showing me a robust case. . .
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.
I maintain my opinion that this is not helpful to make Pharo (having an implementation like this) compelling for doing work with this kind of programming. Â For doing this way you rather do it in a spreadsheet application that has for any function a separate one for complex numbers: it works, but is cumbersome and makes code become bulkier.
A strength of OO languages is polymorphism and Smalltalk adds to it dynamic typing.
How polymorphism helps in making two different functions (one which producing an error on negative argument, while another producing a complex value) to be identified by a single message selector for a single class?
The separation you advocate make these advantages be lost.
-- Cesar Rabak
_______________________________________________ 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.