Hi Eric.
Thanks for a refreshing viewpoint!
Gilles
On Sat, 18 Jun 2016 20:22:24 +0200, Eric Barnhill wrote:
I am new to protocols here and not sure which thread to jump on. But
I am
quite interested in the viability of the math project and hope the
following observation is helpful.
I think one reason people are talking past each other in this debate
is
because those outside the commons-math community may be thinking more
about
commons-math classes like Median and those within it may be more
concerned
with commons-math classes like AkimaSplineInterpolator.
In the case of Median, the fit to the commons mission is quite clear.
It's
a simple function that is widely needed and used but not in the Java
API.
Commons as a whole is strengthened by classes like Median, and
commons-math
is strengthened by being in the commons framework. And Median,
probably any
of us could maintain.
But a class like AkimaSplineInterpolator is a different matter. In
that
case the fit with the commons mission is less clear. And in the case
of
classes like AkimaSplineInterpolator, Gilles is right. It doesn't
make
sense to carry a method like that forward to the next version of a
package,
if there is no one around who even knows what an Akima spline is, let
alone
can defend the methodology in the library or its accuracy. One can't
have
a credible library for scientific computing if it contains methods,
for
which no present maintainer can guarantee the accuracy or
effectiveness. In
such case, such a class should probably be mothballed in the next
release,
or spun off to be maintained by someone who knows what they are
doing. (I
have offered to maintain the interpolators BTW.)
So I actually see Gilles' proposal for spin-off packages as solving a
fundamental dischord in the way commons-math is set up. At the risk
of
adding yet another proposal to the mix, what about deciding which of
the
Math classes suit the commons mission, and are of fairly wide
currency such
that developers from other packages in commons who have offered their
help
could probably maintain them just as easily. This makes for a core
CM. Then
for the rich array of more sophisticated classes that prompted calls
for a
TLP math in the first place -- I can certainly understand the impulse
--
only one of two possibilities exists. Either a new community needs to
be
built through incubator, or the classes with current support need to
be
spun off, and new releases of those classes overseen by people who
understand them and want to manage them.
Gilles feels a trip through the incubator is unlikely to bring new
mathematicians into the fold who want to maintain an omnibus math
package.
His instinct here aligns with what I've seen empirically over the
last few
months -- myself, Artem, syenkoc all have our particular agendas and
niches
of interest that we want to maintain. Gilles says it was ever thus,
and I
see no reason to doubt his knowledge of the history.
So if the days of a core of several omnibus maintainers are over, we
should
go with the other logical plan which is to spin off the fancier
interpolators, solvers, etc. -- classes that exceed the commons
mission --
into classes that have someone who understands them and wants to
support
then, and classes which get mothballed for 4.0 . I think this makes a
lot
of sense.
I would only add that I think that all the math-related classes, as
well
as all of commons, benefits from some sort of commons-math core
classes
that we are sure belong in commons. And then there is no more debate
about
whether someone is trying to destroy commons-math, which quickly
becomes
acrimonious. I think this is a partitioning we could all achieve. We
can
vote on every math package if you like!
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
