commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] Complex division
Date Sun, 04 Sep 2011 11:50:31 GMT
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message