commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] Exceptions for matrix operations
Date Wed, 11 May 2011 05:00:50 GMT
On 5/10/11 9:47 PM, Sébastien Brisard wrote:
> 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...

Depends on the magnitudes of the arrays. length of iteration,
available memory, etc.
>
> 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.

That does look ugly.  As a compromise, I guess you could add the
in/out parameter version.  This situation actually applies to lots
of other methods in [math] that create and return arrays, vectors,
matrices.  What do others think about this?


Phil

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


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


Mime
View raw message