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