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.
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
