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
|