Nah... I just meant get some usable code done before the inevitable discussion winds down. Discussions about designs in commons math tend to follow the pattern of a) proposing an OK design, b) proposing a fine improvement, and then c) iterating forever on hair-splitting details. The final result is rarely as good as even (a), much less (b). The final design also tends to be very strongly focussed on obscure object-orientated design orthodoxy and not at all focussed on the end user of the library.
So much suggestion is that we are now at (b) and somebody needs to code something up quick and not wait for (c) to finish. On Sun, Sep 11, 2011 at 6:51 AM, Phil Steitz <phil.ste...@gmail.com> wrote: > On 9/10/11 3:19 PM, Ted Dunning wrote: > > Sounds great. > > > > Especially if the implementation of the sub-class is deferred until the > > first is completed. > > What exactly do you mean by "the first is completed" - reverting > what is in trunk now to eliminate the checks / recodes that it does? > > Phil > > > > On Sat, Sep 10, 2011 at 2:51 PM, Gilles Sadowski < > > gil...@harfang.homelinux.org> 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). > >> > >> > >> 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 > >
