On 9/4/11 4:50 AM, Luc Maisonobe wrote: > Hi Gilles, > > Le 04/09/2011 12:28, Gilles Sadowski a écrit : >>>> [...] >>>>> 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). > > I'm on the fence on this. I like both specific handling on > infinities and NaN, and performances. In fact, I would very much > like to have a complex primitive type directly supported by the > language and following C99 conventions, but it does not seem to > happen anytime. > > In the recent changes in [math], we have introduced several > features to deal with infinities and NaNs, so I guess our current > focus is towards completeness and the extended Complex set is the > more consistent with this.
I am not so sure this is the best path and I am now wondering whether it may be best to revert to the "use simple computational formulas and let the chips fall where they may" approach that we used to have. The reason for this is that when you peel the onion, you find a whole lot of changes necessary to try to model the compactified space with any kind of mathematical reasonableness. Also, as Gilles points out, we have already added a fair amount of ad hoc stuff that has a performance cost. Finally, C99x does not do really do this and I worry about apps that really do want to maintain distinct infinities. Its too bad we don't have more vocal users who actually use this class in applications or any of the contributors to C99x who can chime in here. I know the new C++ spec was just ratified and I am not sure what the status of Annex G ended up there. When I last checked, it had not been accepted as a standard yet and it was not universally loved. Does anyone know? Here is a public link to a fairly recent draft [1]. There is also a fair amount of publicly available commentary (e.g. [2], [3], [4]). The draft spec is a little vague, but if you read the sample code, it looks like the intent for z/0 is to return a signed infinity (so my recollection that they are not really "simply" modelling the Riemann sphere is correct). There are some (apparently) strange treatments of NaNs as well - "recovering" infinities from them and collapsing some values onto inf + infi. The discussion in [2] brings out a little of the futility of trying to maintain complete mathematical consistency when implementing Complex functions in finite value spaces. This is what led me to the conclusion back in the 1.x days that it would be best to just stick with simple formulas and document clearly exactly what we compute. I guess another option is to do what some C compilers do, which is to enable some sort of "strict" compile time flag that could be turned on for strict spec compliance and off for performance. Another piece of research that we could do here is to look at what gcc and python and other packages do. I did a comparison against R and Colt before 1.1 [5], but I notice now that the current version of R is a little less "NaN-happy." Phil [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1494.pdf [2] http://drdobbs.com/cpp/184404993 [3] ftp://ftp.win.ua.ac.be/pub/preprints/03/criticism.pdf [4] http://www-uxsup.csx.cam.ac.uk/courses/Arithmetic/paper_99.pdf [5] http://wiki.apache.org/commons/math/1.1ReleasePlan > >> >> 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. > > Please, don't overreact on this, both of you. > > All of us, Gilles, Phil, Bill, Mikkel, Greg, Sébastien, Ted, > Dietmar and others are trying to have a good math library. All of > us have different goals, different main topics of interest and > different views. There are far more things we share than things we > disagree upon and we should focus on these commons things. > > *Nobody* should take a different view, or a criticism, or even a > -1 as a personal aggression. Text-based exchanges on a mailing > list lack tone, gesture, behavior that help understand the state > of mind of the peer with which we discuss. I have met both of you > personally; I appreciate both of you. I know for sure that we go > forward much efficiently when we cool down than when we argue on > personal or behavioral ground. > > Luc > >> >>>> [...] >> >> Gilles >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
