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