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 ted.dunning@gmail.com
 designates 209.85.216.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20110910215127.GO19625@dusk.harfang.homelinux.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>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Sat, 10 Sep 2011 15:19:58 -0700
Message-ID: 
 <CAJwFCa0bALJoYS8Va_psgNS-BP36SPc5O1_qxX0Qx=Dzt20eZA@mail.gmail.com>
Subject: Re: [Math] Two "Complex" classes? (Was: Re: [math] Complex division)
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=bcaec51a8276e71f0004ac9db273

--bcaec51a8276e71f0004ac9db273
Content-Type: text/plain; charset=UTF-8

Sounds great.

Especially if the implementation of the sub-class is deferred until the
first is completed.

On Sat, Sep 10, 2011 at 2:51 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> 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).
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

--bcaec51a8276e71f0004ac9db273--