commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [math] Re: [PROPOSAL] Commons-math -- organization of initial code base
Date Tue, 13 May 2003 12:46:45 GMT
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.

> 
> 
>>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


Mime
View raw message