commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [Math] Two "Complex" classes?
Date Sun, 11 Sep 2011 21:50:45 GMT
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


Mime
View raw message