commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] Iterative linear solvers (MATH-581) again
Date Fri, 08 Jul 2011 11:21:01 GMT
On Fri, Jul 08, 2011 at 12:28:23PM +0200, S├ębastien Brisard wrote:
> >
> > 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
> one.



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

View raw message