Complex neurotic
Locked
 
|
Q: What is the difference between a neurotic and a psychotic?
A: A psychotic really thinks 2+2 = 5 A neurotic knows 2+2 = 4, but just can't stand it. ;^) I really can't stand some of the oddities of Complex numbers in Squeak [Note Mantis bug 311 -- http://bugs.squeak.org/view.php?id=3311]. I would find the following to be more rational: 3 asComplex. "no change--> (3+0i)" 3 asComplex isNumber. "no change--> true" -1 asComplex < 1 asComplex. "--> true" -4 sqrt. "--> 2.0i" -3 ln. "--> (1.098612288668382+3.141592653589793i)" ((1/2) + 2.1i) sin arcSin. "--> (0.500000000000001+2.1i)" ((((1/2) + 2.1i) sin arcSin) roundTo: 0.000001) = ((1/2) + 2.1i). "--> true" ((((1/2) + 2.1i) tanH arcTanH) roundTo: 0.000001) = ((1/2) + 2.1i). "--> true" Attached is a change set which adds a number of tests for Complex and the changes for Complex which allow those tests to pass in Pharo1.0beta update: #10413. Note that Complex becomes a subclass of Magnitude. I thought it would be useful to post the code first for your thoughts and any code cleanups. As an occasional Smalltalk user, you may wish to correct some of my idioms. Please forgive an old newbie. Thanks in advance, -KenD [[hidden email]] PS: Yes this is MIT. I signed and sent in the copyright form.. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-KenD
|
NeoComplex.1.cs (28K)
|
AFAIK, one has to be careful ordering complex numbers:
http://www.physicspost.com/physicsforums/topic.asp-ARCHIVE=&TOPIC_ID=2779.htm If in doubt, I would #shouldNotImplement #< until we can get a conclusive answer. If you have defined it only for pure real or pure imaginary numbers (a little tricky with floating point though), then it clearly is ok; off those axes, I _think_ it breaks down. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken.Dickey Sent: Tuesday, August 11, 2009 6:50 PM To: [hidden email] Subject: [Pharo-project] Complex neurotic Q: What is the difference between a neurotic and a psychotic? A: A psychotic really thinks 2+2 = 5 A neurotic knows 2+2 = 4, but just can't stand it. ;^) I really can't stand some of the oddities of Complex numbers in Squeak [Note Mantis bug 311 -- http://bugs.squeak.org/view.php?id=3311]. I would find the following to be more rational: 3 asComplex. "no change--> (3+0i)" 3 asComplex isNumber. "no change--> true" -1 asComplex < 1 asComplex. "--> true" -4 sqrt. "--> 2.0i" -3 ln. "--> (1.098612288668382+3.141592653589793i)" ((1/2) + 2.1i) sin arcSin. "--> (0.500000000000001+2.1i)" ((((1/2) + 2.1i) sin arcSin) roundTo: 0.000001) = ((1/2) + 2.1i). "--> true" ((((1/2) + 2.1i) tanH arcTanH) roundTo: 0.000001) = ((1/2) + 2.1i). "--> true" Attached is a change set which adds a number of tests for Complex and the changes for Complex which allow those tests to pass in Pharo1.0beta update: #10413. Note that Complex becomes a subclass of Magnitude. I thought it would be useful to post the code first for your thoughts and any code cleanups. As an occasional Smalltalk user, you may wish to correct some of my idioms. Please forgive an old newbie. Thanks in advance, -KenD [[hidden email]] PS: Yes this is MIT. I signed and sent in the copyright form.. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by KenDickey
> AFAIK, one has to be careful ordering complex numbers:
I am aware of this. There are a large number of ways to define #< for complex numbers -- and a large number of problems with each of them. What I object to are bad behaviors for things which are perfectly well defined. Currently: -1 asComplex isNumber --> true 1 asComplex isNumber -> true -1 asComplex < 1 asComplex --> error -4 sqrt --> error -3 ln -> NaN > If in doubt, I would #shouldNotImplement #< until we can get a conclusive > answer. An answer to what? I wrote the test cases first and then did code to make the tests pass. I am certainly open to alternate definitions, but I think if an object answers true to isNumber it should behave as a number. What would you expect of the following? -1 asFloat < 1 asFloat. -1 asNumber < 1 asNumber. -1 asFraction < 1 asFraction. -1 asComplex < 1 asComplex. One can add checks and make off-axis complex numbers fail (why?), but why cause the last case above to fail? Smalltalk is known for reasonable behaviors. E.g in Java (1/2) + (1/3) + 1/6) can yield zero (integer division truncates). I much prefer to get an exact 1. Why should I expect complex numbers to be unreasonable? $0.02, -KenD _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-KenD
|
|
|
Perhaps #isNumber should answer false. I would be very careful about advertising an order that might not behave as people expect.
The example of -1 asComplex < 1 asComplex is simple enough, but anything that invokes dictionary ordering (or whatever other definition is used) will get tricky with questions of floating point precision. Also, Float has much more in common with Number than would Complex. A float can be approximated by a fraction; a Complex in general cannot. That alone might be justification for treating complex numbers as something different. Take the real or imaginary part or the modulus, and you have a number again. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken.Dickey Sent: Tuesday, August 11, 2009 9:46 PM To: [hidden email] Subject: Re: [Pharo-project] Complex neurotic > AFAIK, one has to be careful ordering complex numbers: I am aware of this. There are a large number of ways to define #< for complex numbers -- and a large number of problems with each of them. What I object to are bad behaviors for things which are perfectly well defined. Currently: -1 asComplex isNumber --> true 1 asComplex isNumber -> true -1 asComplex < 1 asComplex --> error -4 sqrt --> error -3 ln -> NaN > If in doubt, I would #shouldNotImplement #< until we can get a > conclusive answer. An answer to what? I wrote the test cases first and then did code to make the tests pass. I am certainly open to alternate definitions, but I think if an object answers true to isNumber it should behave as a number. What would you expect of the following? -1 asFloat < 1 asFloat. -1 asNumber < 1 asNumber. -1 asFraction < 1 asFraction. -1 asComplex < 1 asComplex. One can add checks and make off-axis complex numbers fail (why?), but why cause the last case above to fail? Smalltalk is known for reasonable behaviors. E.g in Java (1/2) + (1/3) + 1/6) can yield zero (integer division truncates). I much prefer to get an exact 1. Why should I expect complex numbers to be unreasonable? $0.02, -KenD _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by KenDickey
Hi guys
What I would love is the following: that we get a good Complex package! Since we can do method extensions in Smalltalk we can design a really nice Complex packages with its own tests. We could publish for now Complex into PharoTaskForces or create a PharoExternalPackages or whatever. What do you think? Stef On Aug 12, 2009, at 1:49 AM, Ken.Dickey wrote: > Q: What is the difference between a neurotic and a psychotic? > A: A psychotic really thinks 2+2 = 5 > A neurotic knows 2+2 = 4, but just can't stand it. ;^) > > I really can't stand some of the oddities of Complex numbers in Squeak > [Note Mantis bug 311 -- http://bugs.squeak.org/view.php?id=3311]. > > I would find the following to be more rational: > > 3 asComplex. "no change--> (3+0i)" > 3 asComplex isNumber. "no change--> true" > -1 asComplex < 1 asComplex. "--> true" > -4 sqrt. "--> 2.0i" > -3 ln. "--> (1.098612288668382+3.141592653589793i)" > ((1/2) + 2.1i) sin arcSin. "--> (0.500000000000001+2.1i)" > ((((1/2) + 2.1i) sin arcSin) roundTo: 0.000001) = ((1/2) + 2.1i). > "--> true" > ((((1/2) + 2.1i) tanH arcTanH) roundTo: 0.000001) = ((1/2) + 2.1i). > "--> true" > > Attached is a change set which adds a number of tests for Complex > and the > changes for Complex which allow those tests to pass in Pharo1.0beta > update: > #10413. Note that Complex becomes a subclass of Magnitude. > > I thought it would be useful to post the code first for your > thoughts and any > code cleanups. As an occasional Smalltalk user, you may wish to > correct some > of my idioms. Please forgive an old newbie. > > Thanks in advance, > -KenD [[hidden email]] > > PS: Yes this is MIT. I signed and sent in the copyright form.. > <NeoComplex.1.cs>_______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by KenDickey
2009/8/12 Ken.Dickey <[hidden email]>:
>> AFAIK, one has to be careful ordering complex numbers: > > I am aware of this. There are a large number of ways to define #< for complex > numbers -- and a large number of problems with each of them. > > What I object to are bad behaviors for things which are perfectly well > defined. > > Currently: > > -1 asComplex isNumber --> true > 1 asComplex isNumber -> true > -1 asComplex < 1 asComplex --> error > > -4 sqrt --> error and it should. Not many people using a complex numbers. And -4 is an integer number, not complex number (i hope this non-objectionable?). And sqrt function is not defined for real/integer numbers < 0 ,and should lead to error, period. If you change this behavior, some of code will fail to work correctly , definitely. But you are free to use something like: -4 asComplex sqrt > -3 ln -> NaN > same as above, use it as: -3 asComplex ln. >> If in doubt, I would #shouldNotImplement #< until we can get a conclusive >> answer. > > An answer to what? I wrote the test cases first and then did code to make the > tests pass. > > I am certainly open to alternate definitions, but I think if an object answers > true to isNumber it should behave as a number. > > What would you expect of the following? > > -1 asFloat < 1 asFloat. > -1 asNumber < 1 asNumber. > -1 asFraction < 1 asFraction. > -1 asComplex < 1 asComplex. > i personally, don't see any reason why bother defining an ordering operator for non-scalar value(s). Complex numbers is not scalars and ordering operator having a little sense on vectors (however you can find its defined in Point protocol). I really wonder, where #<, #> could be used for Point(s), or vectors in general? And there always will be questions how to define them. As for complex numbers, i wonder , what is correct answer in comparison between real number and any complex number (and moreover, what is the mathematical meaning of such comparison?), because if you introducing it, you can expect someone to compare occasionally: (a * x) < (b * x) where a,b,x could be either complex or real numbers, and #* behavior could turn the complex number to real for one side, but not for another one. > > One can add checks and make off-axis complex numbers fail (why?), but why > cause the last case above to fail? > > Smalltalk is known for reasonable behaviors. E.g in Java (1/2) + (1/3) + 1/6) > can yield zero (integer division truncates). I much prefer to get an exact > 1. > > Why should I expect complex numbers to be unreasonable? > They shoudn't, just keep real numbers be reasonable in parallel :) > $0.02, > -KenD > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Sig,
+1+0.000000001i :) The small imaginary part is due to my concern over calling complex numbers "non-scalars." In what sense do you mean that? They are indeed used as a field of scalars for vector spaces. That sticking point aside, they are different, and I agree they would be best treated somewhat separately, so that -1 sqrt is an error, -1 asComplex sqrt gives a complex (pure imaginary) result. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko Sent: Wednesday, August 12, 2009 3:16 AM To: [hidden email] Subject: Re: [Pharo-project] Complex neurotic 2009/8/12 Ken.Dickey <[hidden email]>: >> AFAIK, one has to be careful ordering complex numbers: > > I am aware of this. There are a large number of ways to define #< for > complex numbers -- and a large number of problems with each of them. > > What I object to are bad behaviors for things which are perfectly well > defined. > > Currently: > > -1 asComplex isNumber --> true > 1 asComplex isNumber -> true > -1 asComplex < 1 asComplex --> error > > -4 sqrt --> error and it should. Not many people using a complex numbers. And -4 is an integer number, not complex number (i hope this non-objectionable?). And sqrt function is not defined for real/integer numbers < 0 ,and should lead to error, period. If you change this behavior, some of code will fail to work correctly , definitely. But you are free to use something like: -4 asComplex sqrt > -3 ln -> NaN > same as above, use it as: -3 asComplex ln. >> If in doubt, I would #shouldNotImplement #< until we can get a >> conclusive answer. > > An answer to what? I wrote the test cases first and then did code to > make the tests pass. > > I am certainly open to alternate definitions, but I think if an object > answers true to isNumber it should behave as a number. > > What would you expect of the following? > > -1 asFloat < 1 asFloat. > -1 asNumber < 1 asNumber. > -1 asFraction < 1 asFraction. > -1 asComplex < 1 asComplex. > i personally, don't see any reason why bother defining an ordering operator for non-scalar value(s). Complex numbers is not scalars and ordering operator having a little sense on vectors (however you can find its defined in Point protocol). I really wonder, where #<, #> could be used for Point(s), or vectors in general? And there always will be questions how to define them. As for complex numbers, i wonder , what is correct answer in comparison between real number and any complex number (and moreover, what is the mathematical meaning of such comparison?), because if you introducing it, you can expect someone to compare occasionally: (a * x) < (b * x) where a,b,x could be either complex or real numbers, and #* behavior could turn the complex number to real for one side, but not for another one. > > One can add checks and make off-axis complex numbers fail (why?), but > why cause the last case above to fail? > > Smalltalk is known for reasonable behaviors. E.g in Java (1/2) + > (1/3) + 1/6) can yield zero (integer division truncates). I much > prefer to get an exact 1. > > Why should I expect complex numbers to be unreasonable? > They shoudn't, just keep real numbers be reasonable in parallel :) > $0.02, > -KenD > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by KenDickey
St?phane Ducasse <[hidden email]> > What I would love is the following: that we get a good Complex package! > Since we can do method extensions in Smalltalk we can design a really > nice Complex > packages with its own tests. > We could publish for now Complex into PharoTaskForces or create a > PharoExternalPackages or whatever. If you point me to the package docs, I am happy to make a package. Note that the Complex cuts across a number of classes [Point,Float,Number,Object]. Is the desired behavior that (-1 sqrt) raise and exception when the Complex package is not loaded but return 1i when loaded? I presume that we could simply add the hyperbolic trig functions (and some tests) to Float? -KenD _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-KenD
|
|
|
Ken,
The desired behavior appears to be that -1 sqrt raises an error regardless of the complex package; -1 asComplex sqrt works when the package is installed. Sig, is that a fair statement of your position? Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken.Dickey Sent: Wednesday, August 12, 2009 9:59 AM To: [hidden email] Subject: Re: [Pharo-project] Complex neurotic St?phane Ducasse <[hidden email]> > What I would love is the following: that we get a good Complex package! > Since we can do method extensions in Smalltalk we can design a really > nice Complex > packages with its own tests. > We could publish for now Complex into PharoTaskForces or create a > PharoExternalPackages or whatever. If you point me to the package docs, I am happy to make a package. Note that the Complex cuts across a number of classes [Point,Float,Number,Object]. Is the desired behavior that (-1 sqrt) raise and exception when the Complex package is not loaded but return 1i when loaded? I presume that we could simply add the hyperbolic trig functions (and some tests) to Float? -KenD _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by KenDickey
KenD> > Currently:
> > > > -1 asComplex isNumber --> true > > ?1 asComplex isNumber -> true > > -1 asComplex < 1 asComplex --> error > > > > -4 sqrt --> error Igor Stasenko <[hidden email]>> > and it should. > Not many people using a complex numbers. And -4 is an integer number, > not complex number (i hope this non-objectionable?). And sqrt function > is not defined for real/integer numbers < 0 ,and should lead to error, > period. > If you change this behavior, some of code will fail to work correctly > , definitely. > But you are free to use something like: > -4 asComplex sqrt So you prefer (1 asFraction / 2) -> 1/2 , where (1/2) gives an error because 1 and 2 are not fractions? (-1 sqrt) is the definition of 1i . Other dynamic languages I use [Scheme, Lisp] which define complex numbers all give square roots of negative numbers. I am trying to approach the Principle of Least Surprise here. Computers are very bad at math, but we have learned painfully to work around this. I would like pre-computer high school math to "just work". IEEE Floats only guarantee the wrong answer fast, IMHO. I would like square roots of negative numbers to work like they did before I got a computer! 8^) 8^O 8^{ Cheers, -KenD _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-KenD
|
|
|
Ken,
Your 1/2 example is hyperbole. As I said earlier, 0.5 and 1/2 are far more related (rationals being dense in the reals and all that) than are 1/2 and 0.5+0.0i. Complex numbers are inherently different from the magnitudes that we normally use, and I think you will come to agree if you think about the various coercions that would naturally follow from what you propose. A well-rounded package for complex numbers would be greatly appreciated, but I fear we would regret fully wiring it into the magnitude hierarchy. There are times when taking the square root of a negative number means the algorithm has gone wrong and an error is appropriate; other times getting a complex answer is business as usual. Demanding that the programmer use #asComplex to enter a closed system of complex numbers and associated operators solves the problem of deciding between the two worlds. Trying to do their thining for them will backfire. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken.Dickey Sent: Wednesday, August 12, 2009 10:11 AM To: [hidden email] Subject: Re: [Pharo-project] Complex neurotic KenD> > Currently: > > > > -1 asComplex isNumber --> true > > ?1 asComplex isNumber -> true > > -1 asComplex < 1 asComplex --> error > > > > -4 sqrt --> error Igor Stasenko <[hidden email]>> > and it should. > Not many people using a complex numbers. And -4 is an integer number, > not complex number (i hope this non-objectionable?). And sqrt function > is not defined for real/integer numbers < 0 ,and should lead to error, > period. > If you change this behavior, some of code will fail to work correctly > , definitely. > But you are free to use something like: > -4 asComplex sqrt So you prefer (1 asFraction / 2) -> 1/2 , where (1/2) gives an error because 1 and 2 are not fractions? (-1 sqrt) is the definition of 1i . Other dynamic languages I use [Scheme, Lisp] which define complex numbers all give square roots of negative numbers. I am trying to approach the Principle of Least Surprise here. Computers are very bad at math, but we have learned painfully to work around this. I would like pre-computer high school math to "just work". IEEE Floats only guarantee the wrong answer fast, IMHO. I would like square roots of negative numbers to work like they did before I got a computer! 8^) 8^O 8^{ Cheers, -KenD _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by KenDickey
Em 11/08/2009 23:45, Ken.Dickey escreveu:
> > AFAIK, one has to be careful ordering complex numbers: > > I am aware of this. There are a large number of ways to define < for complex > numbers -- and a large number of problems with each of them. > > What I object to are bad behaviors for things which are perfectly well > defined. > > Currently: > > -1 asComplex isNumber --> true > 1 asComplex isNumber -> true Those are well defined. > -1 asComplex < 1 asComplex --> error > This now would only be "well definede" if you make a painstakingly checking that the imaginary part is equal as well. . . > -4 sqrt --> error > -3 ln -> NaN Most applications do not work in Complex but rather in Real (in the sense of 'non imaginary') corpus, so the only way to evade this conundrum would be to have a System wide setting (which I frown at) or a per package (better even if could do in a way to circumscribe to application level), like a Number>>complexResultsAllowed Number>>complexResultsNotAllowed pair, to allow or disallow the results come in Complex or not. > > > If in doubt, I would #shouldNotImplement #< until we can get a conclusive > > answer. > > An answer to what? I wrote the test cases first and then did code to make the > tests pass. > > I am certainly open to alternate definitions, but I think if an object answers > true to isNumber it should behave as a number. The problem is that the result to this answer is arbitrary and result of Smalltalk modeling, not a thesis in type theory or Mathematics... The same kind of "countersense" happens today in Matrix. It is located in the Collections-Unordered package, but we have the following: Matrix>>isSequenceable "LIE so that arithmetic on matrices will work. What matters for arithmetic is not that there should be random indexing but that the structure should be stable and independent of the values of the elements. #isSequenceable is simply the wrong question to ask." ^true Depending upon what kind of rigour you want to defend you'l find the comment "funny" or something else ;-). > > What would you expect of the following? > > -1 asFloat < 1 asFloat. true > -1 asNumber < 1 asNumber. true > -1 asFraction < 1 asFraction. true > -1 asComplex < 1 asComplex. an exception. > > > One can add checks and make off-axis complex numbers fail (why?), but why > cause the last case above to fail? > Because even in pure mathematics there is not a ordering for Complex numbers. In problem domain (like certain problems in Electrical Engineering, for example) -1 asComplexSubclass < 1 asComplexSubclass. would return 'false' and -1 asComplexSubclass = 1 asComplexSubclass. could return 'true'. > Smalltalk is known for reasonable behaviors. E.g in Java (1/2) + (1/3) + 1/6) Not missing the oportunity of the pun, this is Complex case to obtain reasonable behaviour :-D _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
+1
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by KenDickey
I don't want to seem I turned the rant mode, on, but: Last statement makes so little sense as saying the "expected" thing is that 4 sqrt should return a tuple #(2.0 -2.0) because it happened before we had computers.... The "Principle of Least Surprise" should be taken in the context of the Smalltalk language history. For an argument based in mathematical package, if you open a "R" (a statistical package based in ATT's S language) repl and do the similar call you get: > sqrt(-2) Specific mathematical packages like Maxima, Scilab and Octave have flags to control the behaviour for this case. HTH
Em 12/08/2009 12:11, Ken.Dickey < [hidden email] > escreveu:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
2009/8/12 Schwab,Wilhelm K <[hidden email]>:
> Ken, > > The desired behavior appears to be that -1 sqrt raises an error regardless of the complex package; -1 asComplex sqrt works when the package is installed. Sig, is that a fair statement of your position? > Right. The presence of Complex numbers should not change any existing behavior of non-complex numbers. > Bill > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken.Dickey > Sent: Wednesday, August 12, 2009 9:59 AM > To: [hidden email] > Subject: Re: [Pharo-project] Complex neurotic > > > St?phane Ducasse <[hidden email]> >> What I would love is the following: that we get a good Complex package! >> Since we can do method extensions in Smalltalk we can design a really >> nice Complex > packages with its own tests. >> We could publish for now Complex into PharoTaskForces or create a >> PharoExternalPackages or whatever. > > If you point me to the package docs, I am happy to make a package. Note that the Complex cuts across a number of classes [Point,Float,Number,Object]. > > Is the desired behavior that (-1 sqrt) raise and exception when the Complex package is not loaded but return 1i when loaded? > > I presume that we could simply add the hyperbolic trig functions (and some > tests) to Float? > > -KenD > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |