commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: Fwd: [math] Contribution to math.linear - CholeskySolver
Date Mon, 24 Nov 2003 19:27:17 GMT


Paul Libbrecht wrote:

> Mark R. Diggory wrote:
> 
>> I suspect this is an area where discussions concerning encapsulation 
>> and exposure of internal datastructures can get heated. Yes, 
>> unnecessary copying should be avoided when performing Matrix operations.
>>
>> Traditionally, we should possibly consider the usage of methods like 
>> Object[] toArray() of the collections API as a model. Does this 
>> publically exposed method always create a copy of the Collections 
>> internal datastructure? Yes, infact it does:
>>
>> http://java.sun.com/j2se/1.4.2/docs/api/java/util/Collection.html#toArray() 
>>
> 
> 
> True for collections.
> But javax.swing.text.GapContent (which is beloved by many) uses Segments 
> which is a simple way to hack into its array, and known to be such).
> 

hmm, I'll take a look at it, I havn't used it before.

> I agree with the point that using this method to perform each 
> computation (i.e. from the same subclass hierarchy) is a bit heavy...
> 

true.

>> But, well documented behaviors should be made because an Object[] simply 
> 
> [...]> I think we should maintain methods that return a copy and methods 
> that
> 
>> return a reference, I would recommend that methods that return a 
>> reference be protected and used internally for processing methods like 
>> RealMatrixImpl.subtract. your correct about the copying, simply 
>> replacing all the getData() methods with getDataRef() methods solves 
>> this however.
>>
>>     public RealMatrix subtract(RealMatrix m) throws 
>> IllegalArgumentException {
>>        ...
>>         *double[][] mData = m.getDataRef();*
>>         for (int row = 0; row < rowCount; row++) {
>>             for (int col = 0; col < columnCount; col++) {
>>                 outData[row][col] = data[row][col] - mData[row][col];
>>             }
>>         }
>>         return new RealMatrixImpl(outData);
>>     }
> 
> 
> But there could be ten thousand time more "interface" based approaches!
> 
> One thing for sure: a RowIterator and a ColumnIterator are needed, 
> returning vectors... inner class implementations of course.
> Substraction, if it is to return a RealMatrixImpl, should then use these 
> instead of accessing the whole array directly!
> 

Hmm, novel, something that would just return public double next()? I 
suppose it could have additional ListIterator functionality, cursoring, etc.

interface VectorIterator {

    public double next();

    public boolean hasNext();

    public double previous();

    public boolean hasPrevious();

    public double current();

    public int cursor();

    public int size();

}


> And... I wonder wether it wouldn't make sense to provide the difference 
> of two matrices as being a simple object (implementing matrix) but which 
> stores nothing: simply responds the difference of its two terms 
> every-time it's requested for its value.

*static RealMatrix subtract(RealMatrix arg0, RealMatrix arg1)*

RealMatrix a = ...
RealMatrix b = ...
RealMatrix c = RealMatrix.subtract(a, b);

or

class Subtract implmenets RealMatrix{
    public Subtract(RealMatrix arg0, RealMatrix arg1)*
}

RealMatrix a = ...
RealMatrix b = ...
RealMatrix c = new Subtract(a, b);

or

*RealMatrix subtract(RealMatrix arg0)*

RealMatrix a = ...
RealMatrix b = ...
RealMatrix c = a.subtract(b)

seems there'd be many alternatives...

-Mark
-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu

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