[Pharo-project] Complex Solutions
From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> ... I have not been over all of it, but I have found that Real>>arcCosH and #arcTanH can answer a Complex. I would rather not have to say it, but I do not get the sense that you have taken our concerns seriously. We want the errors from Float when the domains are violated. A mere #asComplex can be dividing line that puts the programmer in conrol.
Thanks. I had not caught these.
On this next minor point I can be talked out of it, but I would much prefer #cosh etc. to #cosH; it's easier to type and matches all conventional notation that I have seen.
I am trying to follow camelCase as I understand it. One rubric from user interfaces is that things which are distinct should *look* distinct. I personally perfer cosH to cosh because I know it is not a typo. That I really mean cosH not cos. Let me know the proper thing to do here.
Number>>angle should probably be called #argument, though I would argue that it should not exist as it is another example of implicit (however benign) coercion to complex numbers.
I am trying to follow conventions here for other languages which support Complex data types [primarily Common Lisp and, Scheme]. An angle in radians is what is returned. Wny not call the function returning an angle to be #angle ? Again, let me know the proper thing to do in Smalltalk.
Complex>>angle looks like it will answer zero for a value of zero?? AFAIK, there should be no direction for a zero vector. In a way, it is splitting hairs because exact comparisons of floats are dubious, but it probably should raise an error for zero.
I am following ANSI X3J13 (they had a formal vote which declared the angle of zero to be zero). Let me know of a better refrerence. [The problem with standards is that there are so many to chose from ;^].
Object Arts has long looked down on #as* and #is* methods. With my bias toward their views confessed, #isComplex and #isNumberOrComplex realy should not exist, and even if they do, what are they doing in Object? #isNumberOrComplex raises concerns that there is too much blending of Complex into floats.
According to my recollection of _Squeak by Example_, #isFoo is a standard ideom for a class #Foo. #isNumberOrComplex is used to make double dispatch work in #=, now that Complex instances answer false to isNumber. Do you have a better solution here? #isNumberOrComplex was added to Object to make the test relatively cheap (#= is used a lot, yes?). If Complex does not interoperate, at least to some extent, with Floats how would it be useful for anything? Smalltalk without polymorphism ??? Better solutions?
There are various uses of Taylor series corrections and some things that are computed directly in terms of exponentials. My hunch is that robust scientific libraries will (hopefully) do these things well, and most of the transcendental functions, especially over complex numbers, should come from them when possible and reasonable. The results will likely be faster and probably more accurate than what we can do in Smalltalk.
I agree that a better global solution for numbers is desired. This is an attempt for a small tweak to simply fix the problems I outlined. These problems exist in the current code base. Thank you again for taking the time to look at this, -KenD
Ken, On #cosH vs. #cosh, etc.,I do not like what you have done, but it's hardly cause to start a war. I would be more inclined to agree with your no-typo argument if you spelled out hyperbolic. We write cos and cosh; I see no advantage to typing cosH, which could just as easily be errant as cosh. #angle vs. #argument. The terminology of modulus and argument is heavily drilled into engineers and physisists, so I would go with that inertia vs. anything from Scheme or Lisp. ============= "If Complex does not interoperate, at least to some extent, with Floats how would it be useful for anything? Smalltalk without polymorphism ???" That's not it at all. Sig and I hav been very clear on using polymorphism to get he expected behavior in each world, and how it can extend to (for example) exponentials of matrices. I don't know how to make it more clear that we have done. We object to implicit coercion which works against anyone interested only in real results. ============= ===============
Complex>>angle looks like it will answer zero for a value of zero?? Complex>>AFAIK, there should be no direction for a zero vector. In a way, it is splitting hairs because exact comparisons of floats are dubious, but it probably should raise an error for zero.
I am following ANSI X3J13 (they had a formal vote which declared the angle of zero to be zero). Let me know of a better refrerence. [The problem with standards is that there are so many to chose from ;^]. =============== ANSI is the same group that put an end to time as we know it in 2037 (maybe 2038); if you thought y2k was a mess, just wait until time_t wraps. Zero vectors (and complex numbers act as vectors in this case) have no direction, and ANSI's vote does not change that. Many times you have shown a desire to make things more mathematically correct; ANSI is just plain wrong here. The only argument in their favor is that the distinction might be slightly vacant because computing a truly zero result is very unlikely in a floating point world. 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: Saturday, August 29, 2009 3:43 PM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Complex Solutions
From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> ... I have not been over all of it, but I have found that Real>>arcCosH and #arcTanH can answer a Complex. I would rather not have to say it, but I do not get the sense that you have taken our concerns seriously. We want the errors from Float when the domains are violated. A mere #asComplex can be dividing line that puts the programmer in conrol.
Thanks. I had not caught these.
On this next minor point I can be talked out of it, but I would much prefer #cosh etc. to #cosH; it's easier to type and matches all conventional notation that I have seen.
I am trying to follow camelCase as I understand it. One rubric from user interfaces is that things which are distinct should *look* distinct. I personally perfer cosH to cosh because I know it is not a typo. That I really mean cosH not cos. Let me know the proper thing to do here.
Number>>angle should probably be called #argument, though I would argue Number>>that it should not exist as it is another example of implicit (however benign) coercion to complex numbers.
I am trying to follow conventions here for other languages which support Complex data types [primarily Common Lisp and, Scheme]. An angle in radians is what is returned. Wny not call the function returning an angle to be #angle ? Again, let me know the proper thing to do in Smalltalk.
Complex>>angle looks like it will answer zero for a value of zero?? Complex>>AFAIK, there should be no direction for a zero vector. In a way, it is splitting hairs because exact comparisons of floats are dubious, but it probably should raise an error for zero.
I am following ANSI X3J13 (they had a formal vote which declared the angle of zero to be zero). Let me know of a better refrerence. [The problem with standards is that there are so many to chose from ;^].
Object Arts has long looked down on #as* and #is* methods. With my bias toward their views confessed, #isComplex and #isNumberOrComplex realy should not exist, and even if they do, what are they doing in Object? #isNumberOrComplex raises concerns that there is too much blending of Complex into floats.
According to my recollection of _Squeak by Example_, #isFoo is a standard ideom for a class #Foo. #isNumberOrComplex is used to make double dispatch work in #=, now that Complex instances answer false to isNumber. Do you have a better solution here? #isNumberOrComplex was added to Object to make the test relatively cheap (#= is used a lot, yes?). If Complex does not interoperate, at least to some extent, with Floats how would it be useful for anything? Smalltalk without polymorphism ??? Better solutions?
There are various uses of Taylor series corrections and some things that are computed directly in terms of exponentials. My hunch is that robust scientific libraries will (hopefully) do these things well, and most of the transcendental functions, especially over complex numbers, should come from them when possible and reasonable. The results will likely be faster and probably more accurate than what we can do in Smalltalk.
I agree that a better global solution for numbers is desired. This is an attempt for a small tweak to simply fix the problems I outlined. These problems exist in the current code base. Thank you again for taking the time to look at this, -KenD _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Em 30/08/2009 13:36, Schwab,Wilhelm K < bschwab@anest.ufl.edu > escreveu:
Ken,
On #cosH vs. #cosh, etc.,I do not like what you have done, but it's hardly cause to start a war. I would be more inclined to agree with your no-typo argument if you spelled out hyperbolic. We write cos and cosh; I see no advantage to typing cosH, which could just as easily be errant as cosh.
#angle vs. #argument. The terminology of modulus and argument is heavily drilled into engineers and physisists, so I would go with that inertia vs. anything from Scheme or Lisp.
============= "If Complex does not interoperate, at least to some extent, with Floats how would it be useful for anything? Smalltalk without polymorphism ???"
That's not it at all. Sig and I hav been very clear on using polymorphism to get he expected behavior in each world, and how it can extend to (for example) exponentials of matrices. I don't know how to make it more clear that we have done. We object to implicit coercion which works against anyone interested only in real results. =============
Let me see if I understand your point then: it is OK in your view that we can do: 1i squared. retuning "-1 + 0i" so a Complex, but (1i squared) sqrt. raises an error? Or should we follow your logic and even when the imaginary part of a Complex is zero it should not be automatically converted in a real number? Please not that once the programmer wrote: 1i whatever he already made her/his choice to use Complex numbers, right?
=============== >Complex>>angle looks like it will answer zero for a value of >zero?? >Complex>>AFAIK, there should be no direction for a zero > vector. In a way, it is splitting hairs because exact > comparisons of floats are dubious, but it probably should > raise an error for zero.
I am following ANSI X3J13 (they had a formal vote which declared the angle of zero to be zero). Let me know of a better refrerence. [The problem with standards is that there are so many to chose from ;^]. ===============
ANSI is the same group that put an end to time as we know it in 2037 (maybe 2038); if you thought y2k was a mess, just wait until time_t wraps. Zero vectors (and complex numbers act as vectors in this case) have no direction, and ANSI's vote does not change that. Many times you have shown a desire to make things more mathematically correct; ANSI is just plain wrong here. The only argument in their favor is that the distinction might be slightly vacant because computing a truly zero result is very unlikely in a floating point world.
Oh well, interesting way of looking at things: a non sequitur comment on size of time_t and a dismissal of an agreed upon Standard. You'll have a lot of problem using complex numbers as you want if you don't follow IEEE and ANSI stipulations on the angle of certain operations when voltage is squared to calculate power or the angle of it (which follows the angle of the load) as there is more than a single mathematical correct answer. Back to mathematical purity, then we have a conundrum: as Ken wrote several times Complex is considered a superset of Real numbers in mathematics is Smalltalk class hierarchy that "decided" to consider Number as a subclass of Magnitude that has to respond to #<, but this is not necessary in mathematics in general, no reference about number theory you find such necessary condition.
==================== Let me see if I understand your point then: it is OK in your view that we can do: 1i squared. retuning "-1 + 0i" so a Complex, but (1i squared) sqrt. raises an error? ==================== You apparently do NOT understand. 1i squared would answer a Complex, so it would respond favorably to #sqrt. ================== Or should we follow your logic and even when the imaginary part of a Complex is zero it should not be automatically converted in a real number? ================== Yes. It's not "even when" - just don't do conversions when (you think) floating points numbers match. ============ 1i whatever he already made her/his choice to use Complex numbers, right? ============ Right. So don't try to turn it back into a Float and all will be well. -----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: Sunday, August 30, 2009 4:27 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex Solutions Em 30/08/2009 13:36, Schwab,Wilhelm K < bschwab@anest.ufl.edu > escreveu:
Ken,
On #cosH vs. #cosh, etc.,I do not like what you have done, but it's hardly cause to start a war. I would be more inclined to agree with your no-typo argument if you spelled out hyperbolic. We write cos and cosh; I see no advantage to typing cosH, which could just as easily be errant as cosh.
#angle vs. #argument. The terminology of modulus and argument is heavily drilled into engineers and physisists, so I would go with that inertia vs. anything from Scheme or Lisp.
============= "If Complex does not interoperate, at least to some extent, with Floats how would it be useful for anything? Smalltalk without polymorphism ???"
That's not it at all. Sig and I hav been very clear on using polymorphism to get he expected behavior in each world, and how it can extend to (for example) exponentials of matrices. I don't know how to make it more clear that we have done. We object to implicit coercion which works against anyone interested only in real results. =============
Let me see if I understand your point then: it is OK in your view that we can do: 1i squared. retuning "-1 + 0i" so a Complex, but (1i squared) sqrt. raises an error? Or should we follow your logic and even when the imaginary part of a Complex is zero it should not be automatically converted in a real number? Please not that once the programmer wrote: 1i whatever he already made her/his choice to use Complex numbers, right?
=============== >Complex>>angle looks like it will answer zero for a value of >zero?? >Complex>>AFAIK, there should be no direction for a zero > vector. In a way, it is splitting hairs because exact > comparisons of floats are dubious, but it probably should > raise an error for zero.
I am following ANSI X3J13 (they had a formal vote which declared the angle of zero to be zero). Let me know of a better refrerence. [The problem with standards is that there are so many to chose from ;^]. ===============
ANSI is the same group that put an end to time as we know it in 2037 (maybe 2038); if you thought y2k was a mess, just wait until time_t wraps. Zero vectors (and complex numbers act as vectors in this case) have no direction, and ANSI's vote does not change that. Many times you have shown a desire to make things more mathematically correct; ANSI is just plain wrong here. The only argument in their favor is that the distinction might be slightly vacant because computing a truly zero result is very unlikely in a floating point world.
Oh well, interesting way of looking at things: a non sequitur comment on size of time_t and a dismissal of an agreed upon Standard. You'll have a lot of problem using complex numbers as you want if you don't follow IEEE and ANSI stipulations on the angle of certain operations when voltage is squared to calculate power or the angle of it (which follows the angle of the load) as there is more than a single mathematical correct answer. Back to mathematical purity, then we have a conundrum: as Ken wrote several times Complex is considered a superset of Real numbers in mathematics is Smalltalk class hierarchy that "decided" to consider Number as a subclass of Magnitude that has to respond to #<, but this is not necessary in mathematics in general, no reference about number theory you find such necessary condition. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Em 30/08/2009 18:37, Schwab,Wilhelm K < bschwab@anest.ufl.edu escreveu:
==================== Let me see if I understand your point then: it is OK in your view that we can do: 1i squared. retuning "-1 + 0i" so a Complex, but (1i squared) sqrt. raises an error? ==================== You apparently do NOT understand. 1i squared would answer a Complex, so it would respond favorably to #sqrt.
Bill on the *present* state of affairs, Ken's description of the problem stands as *I* wrote, not as your analysis. Please observe carefully that once 1i is squared it "becomes back" a non complex number '-1'. THIS is the asymmetry I'm writing about.
================== Or should we follow your logic and even when the imaginary part of a Complex is zero it should not be automatically converted in a real number? ================== Yes. It's not "even when" - just don't do conversions when (you think) floating points numbers match.
OK, then we agree that any operation on a Complex should not coalesce it to non complex anymore.
============ 1i whatever he already made her/his choice to use Complex numbers, right? ============ Right. So don't try to turn it back into a Float and all will be well.
Yes. I see consistency with, although I still think the other way is better :-)
participants (3)
-
csrabak＠bol.com.br -
Ken Dickey -
Schwab,Wilhelm K