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