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: domain of phil.steitz@gmail.com
 designates 209.85.210.47 as permitted sender)
Message-ID: <4E6CC3E0.3000804@gmail.com>
Date: Sun, 11 Sep 2011 07:21:20 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
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>
In-Reply-To: <20110910215127.GO19625@dusk.harfang.homelinux.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

Phil

[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.


>
>
> Regards,
> 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