On Mon, 25 Jan 2016 07:01:38 -0700, Phil Steitz wrote:
On 1/25/16 2:28 AM, luc wrote:
Le 2016-01-25 08:52, Benedikt Ritter a écrit :
Hi,
I very much like the idea of taking the name of a famous
mathematician.
If it has to be some thing more descriptive: Apache Commons
HttpClient went
to Apache HttpComponents. How about Apache Math Components as TLP
name?
Benedikt
2016-01-25 8:40 GMT+01:00 Ole Ersoy <ole.er...@gmail.com>:
Umbrella-ish is good. Linear algebra, genetic algorithms, neural
networks, clustering, monte carlo, simplex...These need an
umbrella. Some
of the other Apache projects that do math may be interested in
moving that
piece under the Apache Math umbrella.
Personally I like to see each in a separate repository dedicated
to the
subject, along with the corresponding documentation, etc So:
apache-math (Central repository describing the project as a
whole with the
documentation that cuts across modules)
apache-math-linear-real
apache-math-linear-field
apache-math-optimization-genetic
apache-math-optimization-simplex
etc.
And hopefully:
apache-math-optimization-integer
apache-math-optimization-mixed
And more..
Cheers,
Ole
On 01/24/2016 04:41 PM, Phil Steitz wrote:
On Jan 24, 2016, at 3:17 PM, Gilles
<gil...@harfang.homelinux.org> wrote:
Just plain and simple "Apache Math" maybe?
Or is it taken already?
It's not taken; but I thought it was too broad-sounding and in
fact
umbrella-ish. There are other ASF projects that do
math-relates things. I
think adding "components" makes it look more like a library of
base
components that other math-related projects can use.
Phil
Gilles
On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:
On 1/24/16 2:16 PM, James Carman wrote:
I guess it depends on the scope of what the new TLP is going
to do.
This is slightly jumping the gun, as we do have the
opportunity in
forming the new TLP to revisit the initial goals of [math];
but I
suspect that initially at least we will mostly continue to be a
general-purpose Java math library, trying to provide IP-clean,
easily integrated, standard algorithm-based solutions to
common math
programming problems. We have grown to the point where we will
almost certainly break the distribution up into separate
"components." No umbrella, but likely multiple release
artifacts.
Similar in some ways to what happened with [http], which is
why I
suggested the same approach to naming.
Regarding picking a mathematician for the name, I don't much
like
that idea as whoever you choose, you end up loading some math
area
and / or cultural bias into the name.
Phil
Umbrella projects aren't that popular these days, from what I
understand.
Maybe an homage to a famous mathematician? Apache Newton?
Apache Euler?
Apache Euclid?
On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz
<phil.ste...@gmail.com>
wrote:
We need to agree on a name. My own preference is for a
boring,
descriptive name, but I am manifestly not a marketing guy,
so won't
be offended if others want to be more creative.
My suggestion is
MathComponents
I would be happy with either Math Components or Math.
Also I do favor fancy acronyms that read exactly as well known
names
One that I thought of kind of like that was another current ASF name
ripoff:
JAML (Java Apache Math Library) imitating JAMES.
Oh no, too close to YAML! ;-)
And, as an ending, "ML" is usually acronym for "markup language".
:-P
(23 years ago, the name of my first mathematics library was
an acronym that read "Cantor"), it is probably not a good idea for
this new TLP.
In any case, the project will most probably be de facto an umbrella
project as modularizing it seems in the current mood.
Modularization does not mean becoming an umbrella project. It just
means we distribute multiple jars. In any case, the scope
limitation that I thought good to somehow imply in the name was that
what we aim to produce is a base library in Java.
"Base library" is much too blurred.
Currently, what CM actually is a toolbox collection of what the PMC
agreed to put in, not more not less. Some things are pretty basic in
some sense (MathArrays), some are pretty not basic at all (BSP).
It would make it much clearer if we could agree to think deeply about
the requirements and purpose of modularization.
That could help a lot in defining the scope(s).
Gilles
Phil
best regards,
Luc
Hearkens back to HttpComponents, which has worked pretty
well.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
