Re: [Math] Two "Complex" classes?

[Gilles Sadowski <gi...@harfang.homelinux.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

Re: [Math] Two "Complex" classes?

[Gilles Sadowski <gi...@harfang.homelinux.org>]

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).
> 
> Sounds good to me.  When all is said and done, we might think about
> extracting the (by then stable) interface and just allowing the
> multiple impls to all exist.  Or have the Complex class expose
> factory methods to create instances with the "basic" or "extended"
> behavior.  In any case, we don't have to decide that yet.

JIRA issue opened:
  https://issues.apache.org/jira/browse/MATH-667


Gilles

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

Re: [Math] Two "Complex" classes?

[Phil Steitz <ph...@gmail.com>]

On 9/11/11 2:50 PM, Gilles Sadowski wrote:
> 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).

Sounds good to me.  When all is said and done, we might think about
extracting the (by then stable) interface and just allowing the
multiple impls to all exist.  Or have the Complex class expose
factory methods to create instances with the "basic" or "extended"
behavior.  In any case, we don't have to decide that yet.

Phil
>
>
> 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
>
>


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