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
