> > [...] > >> The mathematical question is do we view our class as representing > >> the extended complex numbers. If we agree that the answer to that > >> question is yes, > > If you say "no", then my understanding is that the "Complex" class does not > > represent the complex number concept, unless *all* operation that encounter > > infinities result in "undefined behaviour" (i.e. return NaN). > > Not necessarily. The Complex field does not include any "point at > infinity." There is a topological space that can be formed from the > Complex numbers by adding a point at infinity and extending > functions to include that point. This is what is sometimes called > the extended complex numbers and a common topology for the space is > represented by the Riemann Sphere. It is not obvious to me that it > is best for us to try to model this (sorry to repeat myself, but > this is the key point). If you really want to be *consistent* and > insist that it is a *bug* to return NaN for division by complex > zero, then you are insisting that we adopt this view. To be > consistent in that view, we need to change equals, all arithmetic > operations, and the exponential and trig functions as well. Our > implementations of those functions are based loosely on C99x, which > does not consistently represent the compactified space.
No, I'm not insisting that we adopt one or the other view. I'm insisting that by having an "INF", it looks like the class represents the extended complex numbers. In which case, it is a bug. My main point is to not treat only _selected_ infinities as equal, but either not treat any infinities at all (complex field; doing as if Java did not provide "Double.POSITIVE_INFINITY") or treat them _all_ to be equal (compactified sphere; consistency with Java "double"; self-consistency). > >> The added "isZero" attribute is part of the performance > >> hit. > > Really? How much? What tests? Can I emit the possibility that testing a > > "boolean" might be a tiny bit faster than testing equality with "0.0" > > twice? > > The hit is in the constructor, where every complex instance has to > run the code to set the property. > > > >> This, btw, is yet another reason to separate commits. > > OK, I take this as: You would have only "cleanly reverted" the Javadoc > > change, if it would have been separate. I'll thus commit back the rest. > > Please do not add back the extra property. If performance is so central that you can't suffer an additional flag, we should *seriously* consider dropping the other two flags "isNaN" and "isInfinite" and let the computational formulae do their work: In most use cases, the result will be correct (at least, as correct as returning NaN for division by zero) and the performance will be *greatly* enhanced (comparing to the cost of my additional flag which you seem to consider as the straw that broke the camel's back). Please explain the rationale behind your insistence for not fixing this tiny issue (I don't mean going for complete consistency with the "compactified" view but just return INF for division by zero) on the basis of performance but find it nice to have dozens of unnecessary checks (because they are useful only for limiting cases similar to division by zero). Let me add that I find quite rude your indiscriminate reverting of my work. Whatever criticism you have with my additions in the "main" area, that did not mean that you could erase the changes in the "test" area. As for your rule with "-1 a commit" I maintain that it was not warranted here, where you could simply remind me to change what had to be, without touching the rest. That would just mean being polite. There are recent examples where changes were made without a JIRA issue and without discussion here; what would you say if I were to go and revert those just because there is such a rule? I would also be glad to read the opinion of others on this administrative question. > > [...] Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
