-1 on splitting out the others. They really do hang together and are pretty easy to understand.
In general I would recommend a -1 on everything that smacks of fancy structure before it is needed. Commons math has a history of gratuitously harder to use interfaces than necessary. For instance, all of the statistics stuff seems to have an interface, a factory, and a something all to support exactly one implementation of each kind of thing. This makes it about 5 times more complicated for the user than it needs to be. Lucene is a good example of exactly the opposite tendency. There, almost nothing was abstracted until it was painfully obvious that it would make the users life harder to keep it concrete or it would make the implementation fiendishly difficult. The result is a very simple package to use. Now, Lucene has some problems as a result. Most notably, the key classes that one uses are not interfaces so it is bit tricky to do a good mock implementation which is helpful when writing code that depends on something as complex as Lucene. On the whole, though, I think that the trade-off isn't all that bad. On Sun, Feb 15, 2009 at 2:08 PM, Luc Maisonobe <luc.maison...@free.fr>wrote: > Phil Steitz a écrit : > > Luc Maisonobe wrote: > >> The linear package has been changed a lot lately and numerous new > >> interfaces and classes have been added. This is now a huge package with > >> more than 30 files in it. > >> > >> What about splitting it into subpackages ? I would propose to add > >> "matrix", "vector", "decomposition" and "error"/"exception". > >> > > +1 for splitting out decomposition > > +0 for error > > -0 for matrix, vector, as I think it is OK to leave these base > > interfaces and their impls in the base package. > > OK. I have created the decomposition package and moved along both the > interfaces/classes and the corresponding errors. > > > Thanks, btw for the Cholesky decomp! > > You're welcome. > > Luc > > > > > Phil > >> Luc > >> > >> --------------------------------------------------------------------- > >> 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Ted Dunning, CTO DeepDyve 4600 Bohannon Drive, Suite 220 Menlo Park, CA 94025 www.deepdyve.com 650-324-0110, ext. 738 858-414-0013 (m)
