Ken,
I think I can see your point, but I propose you a practical experiment. In your Pharo image on the Workspace do it:
-1 inspect
You should get a SmallInteger. Now SmallInteger behaviour is flag as error when you attempt sqrt on it. Complex introduction on the image should not silently change this behaviour.
Every Smalltalk implementation I'm aware of, and IIRC ANSI compliant included, do that way, so in the context of Smalltalk it's unexpected these results start to come as Complex.
Em 14/08/2009 12:38, Ken.Dickey < [email protected] > escreveu:
"Schwab,Wilhelm K"
> Treating reals as complex (giving them a zero imaginary part) is a bad
> idea. Reasons include:
>
> (1) need float and double for FFI
??
> (2) compatibility with other dialects
Squeak and Pharo already have some invompatabilities (e.g. not requiring
#initialize after #new). I do agree that dialect compatibility is a good
thing in general.
> (3) avoid wasting space to hold unneeded imaginary parts
No need for extra space.
Number>>real
^self
Number>>imaginary
^0
> Sig is correct to point out that sometimes one wants to do purely real
> arithmetic with the domains of various functions restricted as appropriate.
> Complex numbers should be separate from reals.
I think that this might be approached differently.
Thought experiment.
I have a Smalltalk without negative numbers (How can you take something away
from nothing? Screen pixels start at 0...@0 I can't draw pixels off-screen! If I
get "negative" pixels I have to check every pixel calculation to see if I am
on screen or not.).
So now I make a package which supplies NegativeNumbers.
The argument is that this changes the behavior which people rely on (breaks
existing code) and that nobody uses these imaginary negative things anyway.
Should one not allow this package?
Note that again, for consistency, I suggest that making Complex a package
implies removing the current Complex implementation. If a Complex package
exists, I expect (-1 sqrt) to give 1i.
My intent is for consistency. Packages allow for completeness. Can we both
be happy?
$0.02,
-KenD
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
