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, s/Map/Operator > > 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
