Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Date: Sun, 4 Sep 2011 16:22:37 +0200
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] Complex division
Message-ID: <20110904142237.GQ19625@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: 
 <595751345.14537.1315042209838.JavaMail.tomcat@hel.zones.apache.org>
 <4E624383.5070902@gmail.com>
 <20110903211753.GM19625@dusk.harfang.homelinux.org>
 <4E62A255.3080202@gmail.com>
 <20110904000640.GN19625@dusk.harfang.homelinux.org>
 <4E62D3AC.2060205@gmail.com>
 <20110904102803.GO19625@dusk.harfang.homelinux.org>
 <4E636607.7060004@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4E636607.7060004@free.fr>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-DCC-scarlet.be-Metrics: eir 20001; Body=1 Fuz1=1 Fuz2=1
X-Virus-Scanned: clamav-milter 0.97.1-exp at eir
X-Virus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

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?

> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org