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: [email protected] [mailto:[email protected]] On Behalf Of Ken Dickey Sent: Saturday, August 29, 2009 3:43 PM To: [email protected] Subject: [Pharo-project] Complex Solutions >From: "Schwab,Wilhelm K" <[email protected]> ... >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 [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
