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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to