Wilhelm,
About your point on "benefit a very small number of cases" I paraphase yourself "...is in the code that is not in your image.": if we stick to only our personal experiences and don't think about the future users of the package, we'll arrive at a 'domestic' or 'local' solution which will be useful on another set of not too many number of cases and make Pharo less than an option (for work with this kind of needs) for people that still do not use Pharo.
I see you state your disagreements and do not explain on what grounds so I cannot elaborate, also as it seems the desire of the interested community to go ahead and keep the discussion on the wiki, I'll read what's there and see if is anything else I can contribute.
On a separate thread I'll put on a more general terms my thoughts on the broader theme of use of Smalltalk for more numeric intensive applications and what I think we could improve in Pharo to make easier for programmers that decide the use of this platform.
Em 16/08/2009 00:32, Schwab,Wilhelm K < bschwab@anest.ufl.edu > escreveu:
Cesar,
Storing integers and fractions for the real and imaginary parts of a complex number will be of benefit in a very small number of cases. Most uses of complex numbers involve transcendental functions that will not produce "nice" results in the general case.
Your closing paragraphs below, well, let's just say I disagree. If you and Ken, separately or together, put proposal(s) on the wiki, I will gladly respond with comments on the pages and/or counter proposal(s), and would be glad to work with Sig on same. As for this seemingly endless chain of email rehashing the same points, I'm done.
Bill
-----Original Message-----
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 9:04 PM
To: Ph aro-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Complex number support discussion
Em 15/08/2009 19:21, Igor Stasenko < siguctua@gmail.com > escreveu:
> 2009/8/16 :
> > 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...
[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 mem bers
> > 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.
>
> 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.
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
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project