commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [math] Exceptions for matrix operations
Date Wed, 11 May 2011 04:47:36 GMT
Le 11/05/11 06:34, Phil Steitz a écrit :
> On 5/10/11 9:18 PM, Sébastien Brisard wrote:
>> Great!
>> So we are more or less back to my initial proposition (see
>> corresponding wiki).
>> To sum up, we will define a new interface, called LinearOperator
>> (should we make it RealLinearOperator? That would be consistent
>> with the hierarchy AnyMatrix/RealMatrix), with the following methods
>> LinearOperator
>>    +- void operate(double[] x, double[] y)
>>    +- int getDomainDimension()
>>    +- int getCodomainDimension()
>>
>> NOTA: I thought that operate(x, y) should *not* create the vector
>> y = A.x, in order to avoid memory allocations for very large data
>> sets. Is it a good idea?
> Why, exactly?  The memory has to get allocated at some point anyway
> - either when you create the vector to pass in or when the operator
> creates its output.  I think it is more natural and consistent with
> the rest of [math] to represent it as it is: double[]
> operate(double[x]).  It is probably best to also have a version that
> operates on and returns RealVectors.  In answer to the name question
> above, yes, it should probably be called RealLinearOperator.  If we
> ever have need for a more general linear operator that works on
> Complex or other vectors, we can define a base LinearOperator that
> operates on FieldVectors (resp FieldElement[]).
This allows reusing previously allocated vectors. I'm using these 
solvers with large data sets (eg tomography), and I'm worried about the 
GC being too heavily sollicitated if I keep allocating new vectors. For 
example, each iteration of the iterative solver calls operate(x, y).
If we had it create a new vector, then a new double[1024*1024] (say) 
would be allocated at the begining of the iteration, and garbage 
collected at the end. Although I've never done any monitoring, I feel 
that it's not very efficient. Am I wrong? I might well be, because the 
GC seems to be such a clever piece of work...
I actually would like to have some time to do some proper monitoring on 
this issue...

Some people go for the mixed solution
double[] operate(double[] x, double[] y)
which actually returns y! This allows chaining calls, but I think this 
is HORRIBLE, and leads to error prone code, so I personally gave up on 
chaining calls.

As for operating on RealVectors, you're right, I'll do that.
>> Regarding exceptions, we would have two new exceptions
>> NonAdjointLinearOperator
>>    +- double[] getFirstOffendingVector()
>>    +- double[] getSecondOffendingVector()
>>    +- double getThreshold()
>>
>> NonPositiveDefiniteLinearMapException
>>    +- double[] getOffendingVector()
>>    +- double getThreshold()
>>
>> Since LinearOperator no longer extends AnyMatrix (or any daughter
>> classes), I no longer feel the need to create a base exception
>> from which NonAdjointLinearOperator and NonSymmetricMatrix would
>> be derived. What do you think? Same goes to NonPositiveDefinite
>> LinearMap/Matrix.
> +1, but for consistency, maybe in the second exception name,
> s/Map/Operator
My mistake... Of course, it will be LinearOperator.
>> Thanks for this very constructive discussion. I now need to work
>> on my code before I can submit it.
> Thanks!
>
> Phil
>> Best regards,
>> Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message