Ken, 1/2 = 0.5 comes close to making an important point, but it doesn't quite get there. However, inspect
0.1+0.1+0.1-0.3 Floating point is not always what it seems. By extension, I argue that computer-represented complex numbers are not always what they seem, only more so. Not only do they have the representation/precision quirks of floats, they are sometimes appropriate and sometimes indicative of nonsense. The line between those two cases is best left to the application programmer who will happily signal their desire to use complex numbers by inserting #asComplex. "Every number is-equivalent-to a complex number because 1 = (1 + 0i). [In the Scheme language every number _is_ a complex number, BTW]." The same is (AFAIK) true in matlab, but that does not make the machine number problems go away, at least not if one wants to use floating point coprocessors. Treating the real line as a subspace of complex plane is fine in a purely mathematical setting, but things get interesting once real-world data, and the occaisional non-representable number, start flying through an algorithm running on hardware. Also, matlab is not the first thing people think of when they want blazing speed, in part because of the way it treats numbers and because of its interpreted execution[*]. Intuition resulting from lots of exposure to mathematicians suggests that they consider this non-trivial but well-known. As a result, there are fleeting insights in exercises and other forums intended for teaching. That can make it difficult to get a clear answer. However, their official reading appears to be that while one can create total orders on the complex numbers, something will always suffer. That is probably because arbitrary decisions have to be made (what is greater than what, does the real or imaginary part get to break the tie?) and result in arbitrary behavior. A couple of IEEE sources state that orders on complex numbers are "meaningless." That means those most likely to take notice of the work will fault us for defining such an order. If I am reading this correctly, defining $< is making a promise we can't keep, or perhaps we simply should not try. You will be doing a great service if you can simply get all the arithmetic and transcendental functions to work properly on complex arguments. However, I think there are compelling reasons to *not* try to make the existing magnitudes coerce into complex numbers. If you can find something that claims to produce a sensible ordering of complex numbers, please post a reference. For now, my sense is that such a thing cannot exist. Bill [*] Interpreters can be fast, as Object Arts showed in nice paper some time back, but, matlab's is apparently not terribly quick. I base that on cautions I received from various sources in a recent exploration of Octave as a possible vehicle to solving a problem. -----Original Message----- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Ken.Dickey Sent: Wednesday, August 12, 2009 1:34 PM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Extending #< to compare all numbers Greetings, Since there is some discussion around comparing using#< let me try to explain the context of my thinking. I am approaching this as a programmer and a user of mathematics, not as a mathematician. I prefer the Principle of Least Surprise. I prefer simple, easy to explain rules and simple implementations. I expect the following expressions all to answer true. 1/2 = 0.5. 1 = 1 asComplex. 1 = (1 + 0i). "same as the previous line" 0 < 1. 0 < 1 asComplex. Every number is-equivalent-to a complex number because 1 = (1 + 0i). [In the Scheme language every number _is_ a complex number, BTW]. So to me, saying that 0 and (1 asComplex) are not comparable is saying that 0 and 1 are also not comparable, because I consider them numerically the same as (0+0i) and (1+0i). My observation is that I don't want to lose properties. If A and B are numbers, I want them to be comparable on the real number line -- no matter how many other dimensions I add. If B is to the right on the real number line from A, then I expect (A < B) to answer true. I expect this to be true NO MATTER HOW MANY DIMENSIONS I ADD. To put this in context, say that I have an object which is a "basket of measurements" at a place and time (say position, density, temperature, pressure). Now if I add a new dimension, say electrical conductivity, I do not expect temperature comparisons to stop working. I can still compare temperatures between objects which lack the conductivity slot/measurement and those which have them. OK. Now to the extension. I suspect this is the root of the (potential) controversy. I chose to say that if the real/x component of a 2d number is equal, then one number may be considered less than another if the imaginary/y value is less. This means that (0+0i) < (0+1i) holds. These are the properties (and test cases) I care about. Currently, the definition for Complex>>< is just this (see below). This implies that (3+0i) < (3+1i) holds, even though the x/real components are equal. I think that this is OK. What do you think? Are there simpler, least surprising definitions for Complex>>< ? What useful properties/invariants/tests would you add? [As unit tests] Thanks for your thoughtful input. -KenD --------------------------------Complex < other "self < other if other's real-part is to the right or the real-parts are equal and the oher's imaginary part is larger" | otherCpx | otherCpx := other asComplex. ^self real < otherCpx real or: [self real = otherCpx real and: [self imag < otherCpx imag]] --------------------------------- _______________________________________________ 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
