Hello, > > I think the opposite: IMHO, as I said above, "Base" is less redundant than > "Abstract"; and then, the name indicates that the class is the "root" of > the hierarchy for this functionality. > I also tend to think that Base or Basic is more meaningful, but any choice is fine by me. > > Now, if we strive for shorter names, and it doesn't matter that developers > would need to go to the Javadoc-generated documentation to see the parent > relationships, I don't mind dropping both "Base" and "Abstract". Except that > it won't be possible because there usually is an interface by that name. :-} > Thus, as with all the other cases where we merged the interface with the > single meaningful implementation, maybe that here too, we could dispense with > the interface and have "UnivariateIntegrator" be an abstract base class... > I would tend to agree, except that one of the changes I would like to suggest for future releases (4.0 ???) is revisiting the integration package. Indeed, the way the interface is designed assumes that all integration algorithms are iterative. For performance purpioses, I find myself using Gauss-type integration schemes with *fixed* number of integration points (10 to 15, which by the way is not possible I think in CM-- another future improvement!), and no check for convergence (of course, I've made sure beforehand that the accuracy I get is satisfactory). Anyway, my point is that integrate() should not take a maximum number of evaluations as a parameter (I think this should be provided at the construction time). Of course, this is just my point of view on this topic, but if agree to defer this discussion to a later point, maybe it's not worth spending too much time on the interface naming just now. Best regards, Sébastien
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
