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