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, 11 Sep 2011 23:50:45 +0200
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [Math] Two "Complex" classes?
Message-ID: <20110911215045.GT19625@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>
 <1315219512.8953.10.camel@knuffelchen>
 <1315224930.8953.18.camel@knuffelchen>
 <20110905142136.GT19625@dusk.harfang.homelinux.org>
 <1315318764.6274.5.camel@knuffelchen>
 <20110910215127.GO19625@dusk.harfang.homelinux.org>
 <4E6CC3E0.3000804@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4E6CC3E0.3000804@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-DCC-scarlet.be-Metrics: eir 20002; 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

On Sun, Sep 11, 2011 at 07:21:20AM -0700, Phil Steitz wrote:
> On 9/10/11 2:51 PM, Gilles Sadowski wrote:
> > Hello.
> >
> > Coming back to this with a simple idea that may hopefully satisfy everyone.
> >
> > What do you think of having one class that performs all operations by
> > directly applying the computational formulae, without worrying about NaN
> > or infinities. This would be represent the complex field, would be simple
> > and most efficient for general use (not involving limiting cases), would be
> > documented as "producing undefined results in limiting cases" or "producing
> > the results expected from direct application of the formulae". The latter
> > would probably automatically keep track of all combinations of NaNs and
> > infinities (as seems to be the case in Octave).
> >
> > In a subclass of the above one, we would attempt to get a completely
> > consistent representation of the extended complex numbers (one point at
> > infinity). It would thus contain all the special handling of the limiting
> > cases of the current "Complex" class (plus all the missing ones and related
> > bug fixes).
> 
> I agree that to make everyone happy we are going to have to do
> something like this, but I would suggest that either we need a third
> implementation or the second one should try to implement C99x [1],
> preserving signed infinities.  I have never seen a fully consistent
> implementation of the Riemannian space and if what we want is
> consistency with C-based packages, we are better off biting the
> bullet and implementing C99x.  That could be done by either someone
> using their employer or other resource to get hold of the spec or
> reverse engineering a C-based OSS implementation like GCC or R.   So
> I am +1 to
> 
> 0) strip out the recoding / checks in trunk, reverting to previous
> "apply formulas and return the results" approach, documenting as the
> trig functions now do.  (If we do this, we should remember to reopen
> any tickets that led to the checks in trunk and either close them as
> WONT_FIX or refer to the proposed second implementation as the
> proposed fix)
> 1) implement C99x in a subclass
> 
> If we choose to implement something other than C99x in the subclass,
> we need to agree on the spec for it.  Given the vagueness in at
> least the draft version of the spec, even in 1), it may turn out to
> be best to choose a reference implementation to emulate.  In either
> case, full documentation of behavior in the javadoc will be necessary.
> 
> As I have said before, I am also fine - and would prefer- doing
> nothing, i.e. staying with the documented contracts that are in the
> trunk now, realizing that they are not consistent with either the
> full Riemannian view or C99x.  I see both of these as having
> pitfalls and the value of these changes as not worth users of the
> main class having to make changes to their exception management code
> to accommodate the change.  I can see I am in the minority here, so
> I am OK with the split implementation idea above.

To avoid (or delay) any burden on satisfied users of the "Complex" class, we
could leave it as-is for now and create a new "BasicComplex" that will
contain the "apply formulas and return the results" approach.

Then, if time and motivation allows, gradually implement an
"ExtendedComplex" class and/or a "C99Complex" class.

Only when that work is done (after the hair-splitting and all), can it be
decided to deprecate "Complex" (telling users that they will be better off
using one of the new classes).


Gilles

> 
> [1] Quite likely, whatever is approved by now is called something
> like "Annex X of C00.y" - what I am referring to is whatever
> "informative" or normative guidance the current C spec provides for
> complex arithmetic and standard functions.

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