commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@mwm.lt>
Subject Re: [math] Re: [PROPOSAL] Commons-math -- organization of initial code base
Date Tue, 13 May 2003 14:16:48 GMT

----- Original Message -----
From: "Phil Steitz" <phil@steitz.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Tuesday, May 13, 2003 2:46 PM
Subject: Re: [math] Re: [PROPOSAL] Commons-math -- organization of initial
code base


> Juozas Baliuka wrote:
> >
> > I prefer to put stuff into single package at this time,
> > It because suff can become like this:
> >   analysis - imports  complex
> >   complex - imports analysis
> >   both of them import linear
> >
> I am OK with this for now, but I want to keep revisiting this topic as
> we add more thinngs.
>    ...
> > It is  a lot of dependand stuff in math  ... .
> >  I do not think matrix of double values needs to implement some kind of
> > interface at this time, we can add it later, if we will decide stuff
like
> > Complex can implement Matrix, It is not very meaningfull to add
interface
> > for single implementation.
>
> The reason that I implemented a RealMatrix interface is that there are
> mutliple good implementation strategies for real matrices and I did not
> want to lock us into one.  For example, in applications requiring high
> precision, the doubles could be replaced by BigDecimals.  Also, while I
> held my numerically weak inversion implementation back, there are
> multiple strategies for this. I will post a reasonable one "soon"
> (unless someone else presents a good one first :-) My idea was to make
> RealMatrixImpl a "generic," reasonably numerically sound implementation,
> but to leave room for things like extended precision or alternative
> algorithms. I probably should have named it something more meaningful
> like "SimpleRealMatrix".  I would see Complex matrices, btw,
> implementing a different interface.

Ok, if it wil be more implementations.

I am not sure, but possible it is better to use Number as component type in
all interfaces, but implementation can use arrays
of primityves,  stuff like this will work:  Matrix  c  =
matrixOfDoubles.add(matrixOfInts) ,
but
matrixOfDoubles.add(matrixOfInts).equals(matrixOfInts.add(matrixOfDoubles))
will return false.

>
> >
> >
> >>On Tuesday, May 13, 2003, at 02:41 AM, Phil Steitz wrote:
> >>
> >>
> >>>robert burrell donkin wrote:
> >>
> >><snip>
> >>
> >>>>i think i like the idea of breaking down into relatively
self-contained
> >>>>sub-packages. it seems that there might be later a need to be able to
> >>>>break down into smaller, self contained libraries and if we're
> >>>>disciplined from the start that's got to help.
> >>>
> >>>Yes.  That was the idea of the "straw man" below.  I really think that
> >>
> > it
> >
> >>>will help us, both in terms of organization and focus.  Honestly,
> >>
> > however,
> >
> >>> I am not 100% sure that the structure below is best.  I tried to
strike
> >>>a balance between how mathematicians divide up the world and how users
> >>
> > of
> >
> >>>math libraries would like to see things. I am curious as to what others
> >>>think of this.
> >>
> >>in terms of what i've learnt about what users (or at least those users
who
> >>care enough to post comments) want:
> >>
> >>1. the ability to roll small independent sub-libraries is important.
> >>2. documentation is the key. provided that the division into packages
has
> >>a clear plan and the top level package documentation provides an index,
> >>the organization is less important to users than it is to developers.
> >>ideally, the organization should reflect a developer's view making it
> >>easier for developers to understand the code and submit patches.
> >>
> >>it's also often easier to refactor later once momentum (both in terms of
> >>participation and quantity of code) has built up.
> >>
> >>i'd also be interested to know what other people think.
> >>
> >>- robert
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message