On 9/4/11 7:22 AM, Gilles Sadowski wrote:
> Hello Luc.
>
>>>>> [...]
>>>>>> 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'd just like to remind, after all the fuss, that the crux of the matter
> (leaving aside the additional flag issue) was to replace:
> ---CUT---
> final double c = divisor.getReal();
> final double d = divisor.getImaginary();
> if (c == 0.0 && d == 0.0) {
> return NaN;
> }
> ---CUT---
> with
> ---CUT---
> final double c = divisor.getReal();
> final double d = divisor.getImaginary();
> if (c == 0.0 && d == 0.0) {
> return (real == 0.0 && imaginary == 0.0) ? NaN : INF;
> }
> ---CUT---
>
> How this change could hurt existing users of "Complex" (and require a
> "clean" revert and endless arguing) is beyond me. There was a test case
> exercising the new behaviour and the old behaviour could be recovered easily
> if, in the end, the unobvious/inconsistent behaviour was to be retained
> (which would have entailed the addition in the Javadoc of a complete
> explanation as to why it was decided to be so).
>
>>> 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.
> I took it so because I've never seen such a thing occur for anyone else.
> Was there a security breach that warranted the urgent deletion?
I apologize, Gilles. I honestly thought I was helping. By not just
doing a revision-based revert, you missed the javadoc change that
left the code in an inconsistent state. I did not think you would
be offended by this. I am sorry.
>
>> 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.
> This is all the more reason to be careful about one's actions. Minimal
> respect for other team members should refrain from deleting their work,
> even if the usefulness is dubious.
>
>> 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.
> I agree; thank you for those appeasing words.
>
>
> Best regards,
> 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
