commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] Exceptions for matrix operations
Date Wed, 11 May 2011 04:34:03 GMT
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[]).
> 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, 
> Thanks for this very constructive discussion. I now need to work
> on my code before I can submit it.


> Best regards,
> Sebastien
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message