Hi Rob.
On Sun, 16 Apr 2017 11:49:32 -0400, Rob Tompkins wrote:
I suppose that I’ll chime in here. Do pardon my delinquency in
responding to the list. I tend to be fairly agnostic on these sorts
of
matters because: (1) I have considerably smaller time in the project
than most of you, and (2) I have a serially agnostic temperament
[personal issue :-)].
So after a year of participation in the project (Commons generally),
I’ve seen and come to enjoy that development is an extremely lengthy
process (and I believe for the better because it accommodates all
necessary and sufficient deliberation). Thus, I tend to take a slow
perspective on any of these changes realizing that I’m not going to
be
able to accomplish anything short of the long order of weeks (short
order of months). With that in mind, I ask, what can I do to help
[math]? What is “progress”?
I've given my POV on the matter.
I think we could chip away at a 4.0
Yes, but only after all current work on new components has
been done (or a clear decision made to abandon the idea).
Currently, the following could gather support from developers
who were interested in working on "Commons Math"-related
utilities:
* Numbers (Eric Bernhill, Ray DeCampo)
* SigProc (Bernd Porr)
* Clustering (Artem Barger)
"Numbers" is underway and its contents has been the subject
of a recent thread. You are welcome to open the corresponding
issues in JIRA.
When done, it will deprecate the following packages from
"Commons Math" (wholly or partly):
* o.a.c.m.complex
* o.a.c.m.fraction
* o.a.c.m.util
* o.a.c.m.primes
The potential contents of "SigProc" exists in the library
which Bernd proposed to relocate here, but according to the
"operative definition" of "Commons", he is to be initiating
the porting work.
When done, it will deprecate:
* o.a.c.m.filter
The new "Clustering" component would be a port of
* o.a.c.m.ml
[Artem has proposed to enhance the "clustering" algorithms.]
or a 3.7 release.
This would be a time-consuming (and futile, IMO) exercise.
I think we
could go TLP? Either direction contains the same difficulty in that
finding contributors in this domain is, apparently, quite difficult.
What domain?
"Math" was an ill-chosen name for a programming project, because
* it gave the illusion that the scope was obvious
* it allowed the scope to grow indefinitely
Either direction requires a relatively prioritized backlog, so that’s
been my intention thus far. And, further I plan to try to fix some of
the bugs.
If you are agnostic about how you help, I'd kindly suggest
that the priority be given on advancing the work on the
components cited above.
As for the philosophy of the matter, I really don’t know what’s best.
I do think that much of this is because [math] sits squarely
in-between a TLP and a component that could be used by any
application.
"Commons Math" is indeed not a component; it resulted from
the aggregation its main developers' personal toolboxes.
I've long suspected that this could lead to disaster. And it
happened last year.
Regards,
Gilles
So there. I’ve completely avoided taking an opinion one way or the
other (agnosticism at it’s best). I’m more in the boat of what can I
do right now to help.
Cheers,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
