commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: [math] restructuring linear package
Date Sun, 15 Feb 2009 22:43:26 GMT
-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.Maisonobe@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@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)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message