Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.217.208 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=RdMks8hUGLBFrMJ9VevNuYHcwoylYBK4RrV+6Ai/2gDEGcXaP0RPmgiKedcTv5Ka/l
         vzGGUupS0deH6CrK0R15qkmCSkF6MOkx1WwjBIU4X+XgPjRZUm6d4xHkq0tYc8azzkrx
         C+9QLQsG3XsvamSa4DW1AT7vr4SOErv74810w=
MIME-Version: 1.0
In-Reply-To: <49989262.7000006@free.fr>
References: <49986E63.1090808@free.fr> <49987A62.2070106@gmail.com>
	 <49989262.7000006@free.fr>
Date: Sun, 15 Feb 2009 14:43:26 -0800
Message-ID: <c7d45fc70902151443gb4d6a06u139ad07b7534841f@mail.gmail.com>
Subject: Re: [math] restructuring linear package
From: Ted Dunning <ted.dunning@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=001485f91ee45772aa0462fccc16

--001485f91ee45772aa0462fccc16
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

-1 on splitting out the others.  They really do hang together and are prett=
y
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 th=
e
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 =C3=A9crit :
> > 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 wit=
h
> >> 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
>
>


--=20
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)

--001485f91ee45772aa0462fccc16--