Le 30/12/2015 20:18, Ole Ersoy a écrit : > Hi Luc, > > On 12/30/2015 03:55 AM, Luc Maisonobe wrote: >> Le 30/12/2015 06:18, Ole Ersoy a écrit : >>> Hi, >> Hi Ole, >> >>> RealMatrixPreservingVisitor and RealMatrixChangingVisitor files look >>> identical with the exception of a single @see Default... annotation >>> (Which I think is redundant...same as > All known implementing >>> classes...?). Would it make sense to remove the annotation and have ons >>> RealMatrixChangingVisitor extend RealMatrixPreservingVisitor? >> No. They are different and used for different things. >> The visit method returns void in one case and double in another >> case. When it returns double, this double is used to update >> the matrix that is visited, hence the "Changing" nature of the >> visitor. > Aha - Figured I was missing something - thanks for explaining. What do > you think about removing the @see annotation (IIUC javadoc generates a > link to implementing classes) and having the changing visitor extend the > preserving one while overriding `visit()`?
This would defeat the purpose of the overloaded signatures for the various walk methods in RealMatrix. There would also be an ambiguity when calling visit and ignoring the returned value: would it be a call to the void method in the super interface or a call to the new method in the lower interface? I don't even think it is possible to override something based only on the return type. > > Also could you help me understand what the start() and() end methods are > for? Is there some test code I can look at (I did scan > BlockRealMatrixTest)? These methods are used before and after the walk. They are typically used for initialization for the first one and to gather some results for the second one. You can see an exemple in the Adams-Moulton ODE integrator (package org.apache.commons.math[34].ode.nonstiff. There is an internal class named Corrector that implements RealMatrixPreservingVisitor. best regards, Luc > > Cheers, > Ole > > --------------------------------------------------------------------- > 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