commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [Math] Package "integration" (related to MATH-707)
Date Tue, 31 Jan 2012 19:59:24 GMT
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message