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