commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <>
Subject Re: [math] Iterative linear solvers (MATH-581) again
Date Fri, 08 Jul 2011 10:28:23 GMT
> I would go to the natural type we get when building the exception. If we may
> build the exception from both types, then I would select RealVector. We do
> not intend to perform large processing on elements, but we want to display
> them and I think we do have formatting for vectors.
> best regards,
> Luc

I actually was not thinking of speed for --as you mentioned--
exceptional cases, but rather to ease of debugging. If several vectors
could have caused the exception, it's easier to identify the right one
if we have a reference rather than a deep copy (overwise all the
components must be tested).

Speaking of speed, I do have a performance issue, which I stated this
morning in MATH-581, but maybe it would be better to ask the question
here. Suppose I want to implement a method operate, which computes the
matrix-vector product. I read a long time ago that it was better to
have a method signature like
void operate(double[] x, double[] y)
where x is the vector to be multiplied, and y the result. Such a
choice avoids costly (so they said) memory allocations caused by a
signature like
double[] operate(double[] x)

The thing is the first option is not frequently met in Commons-Math.
I've started to work with this option for iterative linear solvers,
but I do not like the inconsistent feel it has with the rest of CM.
Also, very crude monitoring on rather large linear systems (800,000 x
800,000)  shows that memory allocations are not even measurable... As
I said, I read that a long time ago, and someone already mentioned on
this forum that GC is getting pretty good those days... So is it
really worth worrying about memory allocation?

I do not intend to do a thorough benchmarking, but I'd rather like to
get rid of operate(double[], double[]) and keep only the most natural

Any thoughts on this ?

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

View raw message