[jira] [Commented] (TEXT-25) Add a duration parser
[ https://issues.apache.org/jira/browse/TEXT-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15966992#comment-15966992 ] Bruno P. Kinoshita commented on TEXT-25: Hi [~ameyjadiye], we decided to release 1.0 first, including mainly edit distances and classes migrated from Apache Commons Lang, before adding new features such as the duration parser. If you would like to submit another pull request based on https://github.com/apache/commons-text/pull/24, or maybe keep a fork to compare with the current PR, it might make it easier to review your changes too. I like these features too, by the way. We might have to think about a good way to support multiple currencies like NZD 1.000,00, and BRL 1,000.00 (one thousand new zealand dollars, and one thousand brazilian reals), support different locales (i.e. BRL 1,000.00 uses commas for thousand separator, and dots for cents, and it could be translated as "1000 reais" in Brazilian Portuguese), etc. > Add a duration parser > - > > Key: TEXT-25 > URL: https://issues.apache.org/jira/browse/TEXT-25 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.1 > > > Duration parses interpret text such as *2 hours, 1 mn and 22sec*. > Examples exist, such as https://github.com/jchampemont/gunip, written in > Javaby Jean Champémont, inspired by https://github.com/domchristie/juration > (JavaScript). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1409) "UncorrelatedRandomVectorGenerator" is shaky
[ https://issues.apache.org/jira/browse/MATH-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-1409: - Description: This unit test (package "o.a.c.m.random") is too sensitive to the seed. Using a fixed seed to make it pass (rather than relaxing the tolerance) gives a wrong impression about the code's purpose (or potentially hides a bug). was: This unit test (package "o.a.c.m.random") is too sensitive to the seed. Using a fixed seed used to make it pass (rather than relaxing the tolerance) gives a wrong impression about the code's purpose (or potentially hides a bug). > "UncorrelatedRandomVectorGenerator" is shaky > > > Key: MATH-1409 > URL: https://issues.apache.org/jira/browse/MATH-1409 > Project: Commons Math > Issue Type: Test >Reporter: Gilles >Priority: Minor > Labels: unit-test > Fix For: 4.0 > > > This unit test (package "o.a.c.m.random") is too sensitive to the seed. > Using a fixed seed to make it pass (rather than relaxing the tolerance) gives > a wrong impression about the code's purpose (or potentially hides a bug). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-25) Add a duration parser
[ https://issues.apache.org/jira/browse/TEXT-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15966464#comment-15966464 ] Amey Jadiye commented on TEXT-25: - Hi [~kinow] Is this merged to TEXT code ? if not let me know show stopper things and i can complete that, after that I wish to add few more matrix like numbers and amount (money) Ex. 1k stringyfy - one thousand. parse - 1000 $1k - stringyfy - one thousand doller parse - $1,000 > Add a duration parser > - > > Key: TEXT-25 > URL: https://issues.apache.org/jira/browse/TEXT-25 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.1 > > > Duration parses interpret text such as *2 hours, 1 mn and 22sec*. > Examples exist, such as https://github.com/jchampemont/gunip, written in > Javaby Jean Champémont, inspired by https://github.com/domchristie/juration > (JavaScript). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MATH-1284) Vector is-not-a Point
[ https://issues.apache.org/jira/browse/MATH-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965677#comment-15965677 ] Gilles commented on MATH-1284: -- I don't know. It's not quite clear that there isn't anything to fix. This is the kind of issues that IMHO calls for separation of concerns (i.e. separate components for separate domains of expertise). > Vector is-not-a Point > - > > Key: MATH-1284 > URL: https://issues.apache.org/jira/browse/MATH-1284 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Roman Werpachowski >Priority: Minor > > The class hierarchy for geometry claims that Vector is-a Point: > https://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/geometry/Point.html > This is mathematically incorrect, see e.g. > http://math.stackexchange.com/a/645827 > Just because they share the same numerical representation, Point and Vector > shouldn't be crammed into a common class hierarchy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1370) Increase efficiency of EnumeratedDistribution#probability
[ https://issues.apache.org/jira/browse/MATH-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1370: --- Fix Version/s: 4.0 > Increase efficiency of EnumeratedDistribution#probability > - > > Key: MATH-1370 > URL: https://issues.apache.org/jira/browse/MATH-1370 > Project: Commons Math > Issue Type: Improvement >Reporter: Ryan Gaffney >Priority: Minor > Labels: patch, performance > Fix For: 4.0 > > Attachments: enum-distribution-perf-patch, > enum-distribution-perf-patch.2 > > > There are lots of other low hanging fruit in the distribution package but > unfortunately this is the only one I got to that day. > In the EnumeratedDistribution case, the probability() method is currently > O(N) where N denotes number of random variables, even though the random > variables are fixed / known. This change makes probability() O(1). The > unlikely worst case scenario now consumes slightly more than 2x the memory, > but I do not think this would be an issue in the vast majority of cases. > Original PR (incorrectly against master) > [here|https://github.com/apache/commons-math/pull/34]. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1373) In LogNormalDistribution.java, it appears shape & scale are reversed/mis-labelled.
[ https://issues.apache.org/jira/browse/MATH-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1373: --- Fix Version/s: 4.0 > In LogNormalDistribution.java, it appears shape & scale are > reversed/mis-labelled. > -- > > Key: MATH-1373 > URL: https://issues.apache.org/jira/browse/MATH-1373 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Karl D. Gierach >Priority: Minor > Fix For: 4.0 > > Attachments: MATH-1373.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > When I compute the logshape and log scale based on the formulas on > wikipedia's lognormal distribution page that use empirical mean and variance, > I found that the getNumericalMean() method was not returning the empirical > mean. > However, upon just trying to reverse the shape and scale parameters in the > constructor proved to fix the problem, and the object then returns the > correct empirical mean. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MATH-1284) Vector is-not-a Point
[ https://issues.apache.org/jira/browse/MATH-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965669#comment-15965669 ] Rob Tompkins commented on MATH-1284: [~erans] Should this issue remain open? It feels closable. > Vector is-not-a Point > - > > Key: MATH-1284 > URL: https://issues.apache.org/jira/browse/MATH-1284 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Roman Werpachowski >Priority: Minor > > The class hierarchy for geometry claims that Vector is-a Point: > https://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/geometry/Point.html > This is mathematically incorrect, see e.g. > http://math.stackexchange.com/a/645827 > Just because they share the same numerical representation, Point and Vector > shouldn't be crammed into a common class hierarchy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-752) Triangulation algorithm
[ https://issues.apache.org/jira/browse/MATH-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-752: -- Fix Version/s: 4.X > Triangulation algorithm > --- > > Key: MATH-752 > URL: https://issues.apache.org/jira/browse/MATH-752 > Project: Commons Math > Issue Type: Sub-task >Reporter: Thomas Neidhart >Priority: Minor > Labels: 2d, 3d, geometric, spherical > Fix For: 4.X > > > The geometric package is currently lacking an algorithm for [Delaunay > Triangulation|http://en.wikipedia.org/wiki/Delaunay_triangulation]. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1201) Please clarify tolerance semantics of org.apache.commons.math3.analysis.solvers
[
https://issues.apache.org/jira/browse/MATH-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1201:
---
Fix Version/s: 4.X
> Please clarify tolerance semantics of
> org.apache.commons.math3.analysis.solvers
>
>
> Key: MATH-1201
> URL: https://issues.apache.org/jira/browse/MATH-1201
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Jason Sachs
>Priority: Minor
> Fix For: 4.X
>
>
> The documentation for
> [BrentSolver|http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/analysis/solvers/BrentSolver.html]
> is somewhat vague and doesn't seem to agree with the source code:
> {quote}The {{solve}} method returns a zero {{x}} of the function f in the
> given interval {{[a, b]}} to within a tolerance {{6 eps abs \(x\) + t}}
> where {{eps}} is the relative accuracy and {{t}} is the absolute accuracy.
> The given interval must bracket the root.{quote}
> A couple of issues:
> - the default tolerance values are not clearly specified. The documentation
> says "default accuracy (1e-6)" but does not state whether it's absolute,
> relative, or function value accuracy. If I dig into the [source
> code|https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/main/java/org/apache/commons/math3/analysis/solvers/BrentSolver.java],
> it is the default absolute accuracy. It is unclear what the default values
> for relative and function value accuracy are. I have to dig into the class
> tree and find
> [BaseAbstractUnivariateSolver|https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/main/java/org/apache/commons/math3/analysis/solvers/BaseAbstractUnivariateSolver.java]
> to find out that the default relative accuracy is 10^-14 and the default
> function value accuracy is 10^-15. These constants in the code are never
> mentioned in the documentation for
> [BaseAbstractUnivariateSolver|https://commons.apache.org/proper/commons-math/javadocs/api-3.1/org/apache/commons/math3/analysis/solvers/BaseAbstractUnivariateSolver.html]
> but should be there.
> - the code appears not to use function value accuracy at all.
> - the [code for
> BrentSolver|https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/main/java/org/apache/commons/math3/analysis/solvers/BrentSolver.java#l165]
> has the expression {{tol = 2*eps * abs(b) + t}}, not {{tol = 6*eps * abs(b)
> + t}} as would be implied by the documentation. Is this an error, or is there
> a magic feature of Brent's algorithm that effectively turns the 2 into a 6?
>
> Suggest you:
> - include the default relative and function value tolerances in the
> documentation for BaseAbstractUnivariateSolver
> - amend the documentation for
> [BaseUnivariateSolver|https://commons.apache.org/proper/commons-math/javadocs/api-3.1/org/apache/commons/math3/analysis/solvers/BaseUnivariateSolver.html]
> to expand upon the three tolerances: Are they always used by each of the
> solver implementations? (no they aren't) Do they add together, or is the
> minimum error of the three used? (it seems dependent on each of the solver
> algorithms; in BrentSolver the relative and absolute tolerances add)
> - amend the documentation for BrentSolver to state clearly that the default
> absolute accuracy is 10^-6 and the other default tolerances are defined in
> the documentation for BaseAbstractUnivariateSolver (with a link)
> - amend the documentation for BrentSolver to state that it does not use
> function value accuracy
> - address the discrepancy in the total tolerance formula between the
> documentation and the code: is the relevant constant 2 or 6?)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-833) Redundancy in number formatting classes.
[
https://issues.apache.org/jira/browse/MATH-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-833:
--
Fix Version/s: 4.X
> Redundancy in number formatting classes.
>
>
> Key: MATH-833
> URL: https://issues.apache.org/jira/browse/MATH-833
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Minor
> Fix For: 4.X
>
>
> # Many tests are repetitive. They are very tedious to modify in case the
> default format changes (as was the case in MATH-622).
> Whenever one is testing the number part (be it an element of a vector, or of
> a matrix, or the real part of a complex number, or the imaginary part of a
> complex), the procedure for testing that, e.g. the truncation works as
> expected, is the same; there should be a way to not repeat the same strings
> of digits in every test class and every test method in those classes.
> The tests should be rationalized in the perspective that the default format
> is changed again, to scientific notation.
> # The formatting classes ("RealVectorFormat", "RealMatrixFormat",
> "VectorFormat", "Vector3DFormat") contain a fairly large amount of duplicate
> code.
> We should look for a way to abstract the formatting of a number (be it an
> element of a vector, or of a matrix, or the real part of a complex number, or
> the imaginary part of a complex) from the rest of the string representation
> of the structure at hand.
> # Some functionality is totally redundant: Formatting a "Vector3D" should be
> strictly equivalent to formatting a "RealVector" with 3 elements.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1253) Skewness could get more precision from slightly reordered code.
[
https://issues.apache.org/jira/browse/MATH-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1253:
---
Fix Version/s: 4.0
> Skewness could get more precision from slightly reordered code.
> ---
>
> Key: MATH-1253
> URL: https://issues.apache.org/jira/browse/MATH-1253
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Bill Murphy
>Priority: Minor
> Fix For: 4.0
>
>
> In Skewness.java, approx line 180, there is code like:
> {noformat}
> double accum3 = 0.0;
> for (int i = begin; i < begin + length; i++) {
> final double d = values[i] - m;
> accum3 += d * d * d;
> }
> accum3 /= variance * FastMath.sqrt(variance);
> {noformat}
> If the division was moved into the for loop, accum3 would be less likely to
> overflow to Infinity (or -Infinity). This might allow computation to return a
> result in a case such as:
> {noformat}
> double[] numArray = { 1.234E11, 1.234E51, 1.234E101, 1.234E151 };
> Skewnessskew = new Skewness();
> doublesk = skew.evaluate( numArray );
> {noformat}
> Currently, this returns NaN, but I'd prefer it returned approx
> 1.154700538379252.
> The change I'm proposing would have the code instead read like:
> {noformat}
> double accum3 = 0.0;
> double divisor = variance * FastMath.sqrt(variance);
> for (int i = begin; i < begin + length; i++) {
> final double d = values[i] - m;
> accum3 += d * d * d / divisor;
> }
> {noformat}
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1262) Heap overflow in org.apache.commons.math4.special.BesselJ
[
https://issues.apache.org/jira/browse/MATH-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1262:
---
Fix Version/s: 4.0
> Heap overflow in org.apache.commons.math4.special.BesselJ
> -
>
> Key: MATH-1262
> URL: https://issues.apache.org/jira/browse/MATH-1262
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Neil Walkinshaw
>Priority: Minor
> Labels: newbie, performance
> Fix For: 4.0
>
>
> This test case:
> {code:java}
> import org.apache.commons.math4.special.BesselJ;
> public class BesselJHeapBug {
> public static void main(String[] args) {
> BesselJ.value(1182054491, 3.589635306407856E-8D);
> }
> }
> {code}
> throws the following exception:
> {code}
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at org.apache.commons.math4.special.BesselJ.rjBesl(BesselJ.java:247)
> at org.apache.commons.math4.special.BesselJ.value(BesselJ.java:161)
> at BesselJHeapBug.main(BesselJHeapBug.java:5)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1113) "FastMath.atan" is slow
[ https://issues.apache.org/jira/browse/MATH-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965666#comment-15965666 ] Rob Tompkins commented on MATH-1113: +1 > "FastMath.atan" is slow > --- > > Key: MATH-1113 > URL: https://issues.apache.org/jira/browse/MATH-1113 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Gilles >Priority: Minor > Labels: perfomance > Fix For: 4.0 > > > This issue is related to > MATH-740 > MATH-901 > Micro-benchmarks show that "FastMath.atan2" is faster than "Math.atan2" but > that "FastMath.atan" is slower than "Math.atan". However, both > "FastMath.atan2" and "Math.atan" call the internal method > "FastMath.atan(double,double,boolean)". > It seems that some performance improvement could be achieved, through > understanding why the results seem contradictory. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1113) "FastMath.atan" is slow
[
https://issues.apache.org/jira/browse/MATH-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-1113:
-
Fix Version/s: (was: 4.X)
4.0
I set the "fix version" to 4.0 because this issue points to a rationale for
changing the name of the {{FastMath}} class.
> "FastMath.atan" is slow
> ---
>
> Key: MATH-1113
> URL: https://issues.apache.org/jira/browse/MATH-1113
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.2
>Reporter: Gilles
>Priority: Minor
> Labels: perfomance
> Fix For: 4.0
>
>
> This issue is related to
> MATH-740
> MATH-901
> Micro-benchmarks show that "FastMath.atan2" is faster than "Math.atan2" but
> that "FastMath.atan" is slower than "Math.atan". However, both
> "FastMath.atan2" and "Math.atan" call the internal method
> "FastMath.atan(double,double,boolean)".
> It seems that some performance improvement could be achieved, through
> understanding why the results seem contradictory.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1331) Addition of accesor methods for abs() and getArgument() of Complex-valued arrays
[
https://issues.apache.org/jira/browse/MATH-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965640#comment-15965640
]
Gilles commented on MATH-1331:
--
Issue is outdated (functionality of the {{complex}} package has been moved to
Commons Numbers).
> Addition of accesor methods for abs() and getArgument() of Complex-valued
> arrays
>
>
> Key: MATH-1331
> URL: https://issues.apache.org/jira/browse/MATH-1331
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 4.0
>Reporter: Eric Barnhill
>Priority: Minor
> Labels: math
> Fix For: 4.X
>
> Original Estimate: 20m
> Remaining Estimate: 20m
>
> Propose to add array-based accessor methods for the abs() and getArgument()
> functions of Complex objects and add them to ComplexUtils. These would be:
> Complex[] abs(Complex[] c)
> also in 2 and 3D, and
> Complex[] getArgument(Complex[] c)
> Following the documentation and other conventions currently found in
> ComplexUtils.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
