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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
