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 13:40:20 GMT
Juozas Baliuka wrote:
> ----- 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.
> 
> 
This is an interesting question. I thought about taking the "Number" 
approach, but concluded that a) all of the casting stuff would be 
inconvenient for users who just want real matrices (likely the vast 
majority of uses) and  b) "real" is part of the contract for a 
RealMatrix.  I would be open to accepting anything that could convert to 
a double as an argument to setEntry() though, with the understanding 
that it is being converted to -- and acts like -- a "real" number once 
it becomes an entry. The same kind of thing will apply to Complex 
matrices, once we have these.

We could define a truly "generic" matrix whose entries just were any 
kinds of objects that supported field operations (+,-.*,/).  This is 
what JADE does:
http://www.dautelle.com/jade/api/com/dautelle/math/Matrix.html

But I would see this as a bit inconvenient for the majority of users who 
just want to push double[]s in and out of real matrices and get the 
basic computations done. I also do not like the idea of mixing field 
types within a matrix, which you can't really maintain once you get down 
to computation.

Phil



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




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