Re: [Pharo-project] #< if at first you dont succeed..
"Schwab,Wilhelm K" <bschwab@anest.ufl.edu>
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
Ken, You seem determined to have the behavior of Float change when the complex package is installed, and there are various objections to that from multiple people; those objections are well founded. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ken.Dickey Sent: Friday, August 14, 2009 10:38 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] #< if at first you dont succeed.. "Schwab,Wilhelm K" <bschwab@anest.ufl.edu>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 14, 2009, at 10:38 AM, Ken.Dickey wrote:
Squeak and Pharo already have some invompatabilities (e.g. not requiring #initialize after #new).
I'm sort of a newbie, can you elaborate on not requiring #initialize after #new somewhat, or point me to where it is documented, I searched around a little bit, but quickly got lost. Thanks! DZ
A default implementation of new on the class sends initialize to the instance by default. All you need to do is implement the initialize method if you want to. Cheers mike On Friday, August 14, 2009, Daniel P Zepeda <daniel@zepeda.ws> wrote:
On Aug 14, 2009, at 10:38 AM, Ken.Dickey wrote:
Squeak and Pharo already have some invompatabilities (e.g. not requiring #initialize after #new).
I'm sort of a newbie, can you elaborate on not requiring #initialize after #new somewhat, or point me to where it is documented, I searched around a little bit, but quickly got lost.
Thanks!
DZ
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
A newbie - welcome! We're always happy to spread the addiction. To find out for yourself, do this: 1) open a workspace, type Object new. 2) select the new text, right click and choose debug-it 3) step into #new, and note that it take you to ^self basicNew initialize At the risk of oversimplifying, that creates a no-frills instance and then invokes #initialize. Not all Smalltalks do this; it is either a bug or a feature depending on one's perspective, though I confess I have bigger things to worry about at present. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Daniel P Zepeda Sent: Friday, August 14, 2009 11:52 AM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Incompatibilities was: #< if at first you dont succeed.. On Aug 14, 2009, at 10:38 AM, Ken.Dickey wrote:
Squeak and Pharo already have some invompatabilities (e.g. not requiring #initialize after #new).
I'm sort of a newbie, can you elaborate on not requiring #initialize after #new somewhat, or point me to where it is documented, I searched around a little bit, but quickly got lost. Thanks! DZ _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
and besides, one could always redefine #new in subclasses to avoid calling #initialize 2009/8/14 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
A newbie - welcome! Â We're always happy to spread the addiction. Â To find out for yourself, do this:
 1) open a workspace, type Object new.  2) select the new text, right click and choose debug-it  3) step into #new, and note that it take you to     ^self basicNew initialize
At the risk of oversimplifying, that creates a no-frills instance and then invokes #initialize. Â Not all Smalltalks do this; it is either a bug or a feature depending on one's perspective, though I confess I have bigger things to worry about at present.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Daniel P Zepeda Sent: Friday, August 14, 2009 11:52 AM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Incompatibilities was: #< if at first you dont succeed..
On Aug 14, 2009, at 10:38 AM, Ken.Dickey wrote:
Squeak and Pharo already have some invompatabilities (e.g. not requiring #initialize after #new).
I'm sort of a newbie, can you elaborate on not requiring #initialize after #new somewhat, or point me to where it is documented, I searched around a little bit, but quickly got lost.
Thanks!
DZ
_______________________________________________ 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.
On Aug 14, 2009, at 5:38 PM, Ken.Dickey wrote:
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.
no this is the same in squeak and pharo since 3.7 Stef
participants (7)
-
csrabak＠bol.com.br -
Daniel P Zepeda -
Igor Stasenko -
Ken.Dickey -
Michael Roberts -
Schwab,Wilhelm K -
Stéphane Ducasse