On Wed, 22 Jun 2016 10:45:33 +0000, Benedikt Ritter wrote:
+/- 0 I'm unsure.
We already have some Math code in Commons Lang. Maybe this code would
fit
into o.a.c.lang3.math ?
In principle, yes, but I'd be wary of a big codebase that becomes less
and less focused.
I think that whatever is a enhancement/extension/generalization of some
JDK functionality is worth a component.
By your line of reasoning, shouldn't "crypto" have been included in as
"o.a.c.lang3.crypto"?
In the "math" case, we enhance tools from "java.lang.Math" (drop-in
remplacement with higher accuracy was the purpose of "FastMath"), then
generalize to unlimited precision ("dfp") and extend with common
(really!)
functions not available[1] in the JDK (combinations, factorial log,
error
functions).
As said, this is all *stable* API (after the necessary adaptation to a
new component) which the Commons PMC would be totally justified to
enforce.
And the main architect and maintainer of a lot of this code is Sebb;
which IMO is a pretty strong argument to have it here.
OTOH it's a big codebase, it may make sense to make a separate
component
out of it.
Exactly.
The scope is pretty math centric. So a Math TLP may be a better home
for
this.
Many, many things are "math-centric"; it certainly does not mean they
should belong to the same TLP. Trying to set up an "all math" TLP is
doomed to fail like CM did (because the same little turfs will appear,
leading to a growing disparity in the development).[2]
Regards,
Gilles
[1] Or not yet, for older Java versions.
[2] This is all provable from the archives and commit log (but nobody
will take the time to do the research...).
Benedikt
Gilles <gil...@harfang.homelinux.org> schrieb am Di., 21. Juni 2016
um
21:30 Uhr:
Hello.
This is one of several votes for establishing new Commons components
out of functionality developed inside the "Commons Math" component.
This vote is dedicated to the following functionality:
Standard mathematical functions (either missing from
"java.lang.Math",
or faster or more accurate than their counterpart in the JDK) and
floating point utilities.
The concerned code is the contents of the following classes and
packages:
org.apache.commons.math4.Field
org.apache.commons.math4.FieldElement
org.apache.commons.math4.RealFieldElement
org.apache.commons.math4.util.FastMath (and helper classes)
org.apache.commons.math4.util.Precision
org.apache.commons.math4.util.MathUtils
org.apache.commons.math4.util.ArithmeticUtils
org.apache.commons.math4.util.Combinations
org.apache.commons.math4.util.CombinatoricsUtils
org.apache.commons.math4.util.ContinuedFraction
org.apache.commons.math4.dfp
org.apache.commons.math4.special
located in the "develop" branch of Commons Math:
https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/util;h=c54f99f943f758e43ebeb54d8771a6ef6516d283;hb=refs/heads/develop
https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/special;h=b8fb8b1f6e29a549d0716c866939e074525246a1;hb=refs/heads/develop
Notes:
* This component will have no dependency.
* Code size: ~13000 lines of code (unit tests not included).
[Out of which ~6000 lines are literal numbers defined in
class "FastMathLiteralArrays".]
* API: stable. [But some of it should probably be moved into
an "internal" package.]
* Estimated minimum Java version: 5
All are welcome to vote, especially potential users of the candidate
component and people who'd like to contribute to it, through user
support,
bug-fixes and enhancements, documentation, release management.
[ ] +1, this would be a valid Commons component.
[ ] -1, this won't be a good Commons component because ...
Thanks,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
