[jira] [Commented] (MATH-1269) FastMath.exp may return NaN for non-NaN arguments
[ https://issues.apache.org/jira/browse/MATH-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14738393#comment-14738393 ] Sebb commented on MATH-1269: Thanks. However I'm not sure it is necessary to check intVal at all - why not just check x? > FastMath.exp may return NaN for non-NaN arguments > - > > Key: MATH-1269 > URL: https://issues.apache.org/jira/browse/MATH-1269 > Project: Commons Math > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Otmar Ertl > Attachments: MATH-1269.patch > > > I have observed that FastMath.exp(709.8125) returns NaN. However, the > exponential function must never return NaN (if the argument is not NaN). The > result must always be non-negative or positive infinity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1272) FastMath.pow(double, long) enters an infinite loop with Long.MIN_VALUE
[ https://issues.apache.org/jira/browse/MATH-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1272. - Resolution: Fixed Fix Version/s: 3.6 Fixed in git repository (commit d93c95d for master branch, commit 252a013 for MATH_3_X branch). Thanks for the report and for the patch! > FastMath.pow(double, long) enters an infinite loop with Long.MIN_VALUE > -- > > Key: MATH-1272 > URL: https://issues.apache.org/jira/browse/MATH-1272 > Project: Commons Math > Issue Type: Bug >Affects Versions: 4.0, 3.5 >Reporter: Qualtagh >Priority: Minor > Labels: patch > Fix For: 4.0, 3.6 > > Attachments: MATH-1272.patch > > > FastMath.pow(double, long) enters an infinite loop with Long.MIN_VALUE. It > cannot be negated, so unsigned shift (>>>) is required instead of a signed > one (>>). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1271) Unsigned operations
[ https://issues.apache.org/jira/browse/MATH-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14738338#comment-14738338 ] Luc Maisonobe commented on MATH-1271: - Including code from "Hacker's Delight" is OK as per this page: http://www.hackersdelight.org/permissions.htm. However, what is more troublesome in the pull request is the various test methods labelled as "A method from java.lang.Integer." or "A method from java.lang.Long.". If these methods have been copied from a JVM, they are subject to the JVM license. So typically it would be GPL for openJDK. This cannot be included in Apache Commons Math. I would suggest that rather than copying the methods and calling them from the tests we simply put in the test the fixed values provided by these methods (*data* output from a GPL code is not subject to the code license). > Unsigned operations > --- > > Key: MATH-1271 > URL: https://issues.apache.org/jira/browse/MATH-1271 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 4.0 >Reporter: Qualtagh >Priority: Trivial > Labels: features > > Add unsigned operations to ArithmeticUtils: divideUnsigned and > remainderUnsigned. They exist in java.lang.Integer and java.lang.Long since > Java 8. The inner implementation is based on leveraging to long (for ints) > and to BigInteger (for longs). Comments in code suggest using tricks > described in "Hacker's Delight" to stay with smaller type (int and long > respectively). Those tricks were implemented in this pull request: > https://github.com/apache/commons-math/pull/13 > I don't know if using an algorithm from "Hacker's Delight" is compatible with > Apache license. The code is faster than standard Java 8 implementation: 2 > times for int and 8 times for long (verified with simple small tests). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1269) FastMath.exp may return NaN for non-NaN arguments
[
https://issues.apache.org/jira/browse/MATH-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14738475#comment-14738475
]
Sebb commented on MATH-1269:
One should be able to use {{if (x > Math.log(Double.MAX_VALUE))}}
(Of course the value should be a static constant)
> FastMath.exp may return NaN for non-NaN arguments
> -
>
> Key: MATH-1269
> URL: https://issues.apache.org/jira/browse/MATH-1269
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Otmar Ertl
> Attachments: MATH-1269.patch
>
>
> I have observed that FastMath.exp(709.8125) returns NaN. However, the
> exponential function must never return NaN (if the argument is not NaN). The
> result must always be non-negative or positive infinity.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MATH-1269) FastMath.exp may return NaN for non-NaN arguments
[ https://issues.apache.org/jira/browse/MATH-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-1269: --- Attachment: MATH-1269.patch Suggested fix - there was already a private constant with the correct value in the FastMath class > FastMath.exp may return NaN for non-NaN arguments > - > > Key: MATH-1269 > URL: https://issues.apache.org/jira/browse/MATH-1269 > Project: Commons Math > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Otmar Ertl > Attachments: MATH-1269.patch, MATH-1269.patch > > > I have observed that FastMath.exp(709.8125) returns NaN. However, the > exponential function must never return NaN (if the argument is not NaN). The > result must always be non-negative or positive infinity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IO-402) [IO] copyFileToDirectory - Over-Write File
[ https://issues.apache.org/jira/browse/IO-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated IO-402: -- Fix Version/s: (was: 2.5) > [IO] copyFileToDirectory - Over-Write File > -- > > Key: IO-402 > URL: https://issues.apache.org/jira/browse/IO-402 > Project: Commons IO > Issue Type: Wish > Components: Utilities >Affects Versions: 2.4 >Reporter: BELUGA BEHR >Priority: Minor > Attachments: FILEUTILS_OVERWRITE.patch, > FILEUTILS_UNITTC_OVERWRITE.patch > > > I came across a small annoyance at work today. I have code that takes a file > and copies it to a mounted directory on a remote server. I am using > FileUtils.copyFileToDirectory() to do the move, but it does not have an > overwrite flag. If something goes wrong with the file transfer over the > network, and only part of the file is transferred, all subsequent attempts > are blocked by the fact that the file "already exists." I would like to see > another overloaded copyFileToDirectory() method with a flag to overwrite the > file if it already exists. The current behavior is to throw an IoException. > Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MATH-1238) NoBracketingException send with valid brackets
[
https://issues.apache.org/jira/browse/MATH-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14739284#comment-14739284
]
Axion004 edited comment on MATH-1238 at 9/10/15 6:22 PM:
-
I have the same issue through the following test program
import java.util.TreeSet;
import org.apache.commons.math3.analysis.UnivariateFunction;
import org.apache.commons.math3.analysis.solvers.*;
public class TestBrent {
public static void main(String[] args) {
BrentSolver test2 = new BrentSolver(1E-10);
UnivariateFunction function = (double x) -> Math.sin(x);
double EPSILON = 1e-6;
TreeSet set = new TreeSet<>();
for (int i = 1; i <= 500; i++) {
set.add(test2.solve(1000, function, i, i+1));
}
for (Double s : set) {
if (s > 0) {
System.out.println(s);
}
}
}
}
run:
Exception in thread "main"
org.apache.commons.math3.exception.NoBracketingException: function values at
endpoints do not have different signs, endpoints: [1, 2], values: [0.841, 0.909]
at
org.apache.commons.math3.analysis.solvers.BrentSolver.doSolve(BrentSolver.java:133)
at
org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:199)
at
org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:204)
at TestBrent.main(TestBrent.java:15)
Java Result: 1
BUILD SUCCESSFUL (total time: 0 seconds)
was (Author: axion004):
I have the same issue through the following test program
import java.util.TreeSet;
import org.apache.commons.math3.analysis.UnivariateFunction;
import org.apache.commons.math3.analysis.solvers.*;
public class TestBrent {
public static void main(String[] args) {
BrentSolver test2 = new BrentSolver(1E-10);
UnivariateFunction function = (double x) -> Math.sin(x);
double EPSILON = 1e-6;
TreeSet set = new TreeSet<>();
for (int i = 1; i <= 500; i++) {
set.add(test2.solve(1000, function, i, i+1));
}
for (Double s : set) {
if (s > 0) {
System.out.println(s);
}
}
}
}
Exception in thread "main"
org.apache.commons.math3.exception.NoBracketingException: function values at
endpoints do not have different signs, endpoints: [1, 2], values: [0.841, 0.909]
at
org.apache.commons.math3.analysis.solvers.BrentSolver.doSolve(BrentSolver.java:133)
at
org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:199)
at
org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:204)
at TestBrent.main(TestBrent.java:15)
Java Result: 1
BUILD SUCCESSFUL (total time:
> NoBracketingException send with valid brackets
> --
>
> Key: MATH-1238
> URL: https://issues.apache.org/jira/browse/MATH-1238
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: charles sitbon
>Priority: Minor
>
> The brent solver sometimes send a NoBracketingException with valid brackets :
> example for a beta distribution with large Beta (285) and alpha around 15
> Exception in thread "main"
> org.apache.commons.math3.exception.NoBracketingException: function values at
> endpoints do not have different signs, endpoints: [0, 1], values: [-0.15,
> 0.85]
> the exception is actually caused by the yinitial which is Nan
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CONFIGURATION-610) Improve Configuration Variable Documentation
[
https://issues.apache.org/jira/browse/CONFIGURATION-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14739240#comment-14739240
]
Oliver Heger commented on CONFIGURATION-610:
The documentation can certainly be improved. You already have thought about it,
would you be willing to provide a patch with your proposed changes?
Note that some further documentation about variable substitution is available
in the user's guide at
http://commons.apache.org/proper/commons-configuration/userguide/howto_basicfeatures.html#Variable_Interpolation.
So maybe it makes sense to improve this chapter and just add a link in the
Javadocs? Also, as all these basic features are implemented by the base class
{{AbstractConfiguration}}, maybe it is better to add comprehensive
documentation there and in the derived classes add a statement like "All basic
features as described for AbstractConfiguration are available as well".
WDYT?
> Improve Configuration Variable Documentation
>
>
> Key: CONFIGURATION-610
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-610
> Project: Commons Configuration
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 2.0-alpha1
>Reporter: Dan Lamet
>
> The JavaDoc for [Class PropertiesConfiguration
> |http://commons.apache.org/proper/commons-configuration/apidocs/index.html]
> lists a very handy feature of Configuration, which is variable substitution.
> The behavior can be seen in the example file on the JavaDoc (good).
> But it's not in the preceding list of features. It would be nice to have a
> little writeup describing the intended behavior: What is supposed to happen
> if you have an undefined ref? What about nested refs? What about circular
> refs?
> And it was interesting to find that the substitution occurred during get time
> rather than load (unexpected), and that if one calls the wrong get() method
> then the substitution will not happen. (Is that intended behavior?) This
> should be called out in the description as well as the individual method
> JavaDocs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MATH-1238) NoBracketingException send with valid brackets
[
https://issues.apache.org/jira/browse/MATH-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14739284#comment-14739284
]
Axion004 edited comment on MATH-1238 at 9/10/15 6:22 PM:
-
I have the same issue through the following test program
import java.util.TreeSet;
import org.apache.commons.math3.analysis.UnivariateFunction;
import org.apache.commons.math3.analysis.solvers.*;
public class TestBrent {
public static void main(String[] args) {
BrentSolver test2 = new BrentSolver(1E-10);
UnivariateFunction function = (double x) -> Math.sin(x);
double EPSILON = 1e-6;
TreeSet set = new TreeSet<>();
for (int i = 1; i <= 500; i++) {
set.add(test2.solve(1000, function, i, i+1));
}
for (Double s : set) {
if (s > 0) {
System.out.println(s);
}
}
}
}
Exception in thread "main"
org.apache.commons.math3.exception.NoBracketingException: function values at
endpoints do not have different signs, endpoints: [1, 2], values: [0.841, 0.909]
at
org.apache.commons.math3.analysis.solvers.BrentSolver.doSolve(BrentSolver.java:133)
at
org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:199)
at
org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:204)
at TestBrent.main(TestBrent.java:15)
Java Result: 1
BUILD SUCCESSFUL (total time:
was (Author: axion004):
I have the same issue through the following test program
import java.util.TreeSet;
import org.apache.commons.math3.analysis.UnivariateFunction;
import org.apache.commons.math3.analysis.solvers.*;
public class TestBrent {
public static void main(String[] args) {
BrentSolver test2 = new BrentSolver(1E-10);
UnivariateFunction function = (double x) -> Math.sin(x);
double EPSILON = 1e-6;
TreeSet set = new TreeSet<>();
for (int i = 1; i <= 500; i++) {
set.add(test2.solve(1000, function, i, i+1));
}
for (Double s : set) {
if (s > 0) {
System.out.println(s);
}
}
}
}
Exception in thread "main"
org.apache.commons.math3.exception.NoBracketingException: function values at
endpoints do not have different signs, endpoints: [1, 2], values: [0.841, 0.909]
at
org.apache.commons.math3.analysis.solvers.BrentSolver.doSolve(BrentSolver.java:133)
at
org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:199)
at
org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:204)
at TestBrent.main(TestBrent.java:15)
Java Result: 1
BUILD SUCCESSFUL (total time:
> NoBracketingException send with valid brackets
> --
>
> Key: MATH-1238
> URL: https://issues.apache.org/jira/browse/MATH-1238
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: charles sitbon
>Priority: Minor
>
> The brent solver sometimes send a NoBracketingException with valid brackets :
> example for a beta distribution with large Beta (285) and alpha around 15
> Exception in thread "main"
> org.apache.commons.math3.exception.NoBracketingException: function values at
> endpoints do not have different signs, endpoints: [0, 1], values: [-0.15,
> 0.85]
> the exception is actually caused by the yinitial which is Nan
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1238) NoBracketingException send with valid brackets
[
https://issues.apache.org/jira/browse/MATH-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14739284#comment-14739284
]
Axion004 commented on MATH-1238:
I have the same issue through the following test program
import java.util.TreeSet;
import org.apache.commons.math3.analysis.UnivariateFunction;
import org.apache.commons.math3.analysis.solvers.*;
public class TestBrent {
public static void main(String[] args) {
BrentSolver test2 = new BrentSolver(1E-10);
UnivariateFunction function = (double x) -> Math.sin(x);
double EPSILON = 1e-6;
TreeSet set = new TreeSet<>();
for (int i = 1; i <= 500; i++) {
set.add(test2.solve(1000, function, i, i+1));
}
for (Double s : set) {
if (s > 0) {
System.out.println(s);
}
}
}
}
Exception in thread "main"
org.apache.commons.math3.exception.NoBracketingException: function values at
endpoints do not have different signs, endpoints: [1, 2], values: [0.841, 0.909]
at
org.apache.commons.math3.analysis.solvers.BrentSolver.doSolve(BrentSolver.java:133)
at
org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:199)
at
org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:204)
at TestBrent.main(TestBrent.java:15)
Java Result: 1
BUILD SUCCESSFUL (total time:
> NoBracketingException send with valid brackets
> --
>
> Key: MATH-1238
> URL: https://issues.apache.org/jira/browse/MATH-1238
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: charles sitbon
>Priority: Minor
>
> The brent solver sometimes send a NoBracketingException with valid brackets :
> example for a beta distribution with large Beta (285) and alpha around 15
> Exception in thread "main"
> org.apache.commons.math3.exception.NoBracketingException: function values at
> endpoints do not have different signs, endpoints: [0, 1], values: [-0.15,
> 0.85]
> the exception is actually caused by the yinitial which is Nan
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1238) NoBracketingException send with valid brackets
[ https://issues.apache.org/jira/browse/MATH-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14740008#comment-14740008 ] Axion004 commented on MATH-1238: Correct, I did not see my mistake. I will need to review the documentation more carefully. Thank You for pointing this out. > NoBracketingException send with valid brackets > -- > > Key: MATH-1238 > URL: https://issues.apache.org/jira/browse/MATH-1238 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: charles sitbon >Priority: Minor > > The brent solver sometimes send a NoBracketingException with valid brackets : > example for a beta distribution with large Beta (285) and alpha around 15 > Exception in thread "main" > org.apache.commons.math3.exception.NoBracketingException: function values at > endpoints do not have different signs, endpoints: [0, 1], values: [-0.15, > 0.85] > the exception is actually caused by the yinitial which is Nan -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (BCEL-263) LATER: change clone() methods to return the appropriate type
Sebb created BCEL-263: - Summary: LATER: change clone() methods to return the appropriate type Key: BCEL-263 URL: https://issues.apache.org/jira/browse/BCEL-263 Project: Commons BCEL Issue Type: Improvement Reporter: Sebb This is a marker issue to note that it would be sensible to use specific return types for the clone() methods in future. Note that it remains to be decided whether to use clone() or copy methods/constructors - at present both are used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1238) NoBracketingException send with valid brackets
[ https://issues.apache.org/jira/browse/MATH-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14739943#comment-14739943 ] Gilles commented on MATH-1238: -- bq. I have the same issue I don't think so. Your "NoBracketingException" occurs because the bracket is _not_ valid. Moreover, there is no root of the sine function between 1 and 2. > NoBracketingException send with valid brackets > -- > > Key: MATH-1238 > URL: https://issues.apache.org/jira/browse/MATH-1238 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: charles sitbon >Priority: Minor > > The brent solver sometimes send a NoBracketingException with valid brackets : > example for a beta distribution with large Beta (285) and alpha around 15 > Exception in thread "main" > org.apache.commons.math3.exception.NoBracketingException: function values at > endpoints do not have different signs, endpoints: [0, 1], values: [-0.15, > 0.85] > the exception is actually caused by the yinitial which is Nan -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1269) FastMath.exp may return NaN for non-NaN arguments
[ https://issues.apache.org/jira/browse/MATH-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14739394#comment-14739394 ] Sebb commented on MATH-1269: Note: I had a quick look at expm1() and that seems to naturally return infinity when required without needing to check that the input is too large. Unfortunately defining exp() in terms of expm1() does not retain sufficient precision. > FastMath.exp may return NaN for non-NaN arguments > - > > Key: MATH-1269 > URL: https://issues.apache.org/jira/browse/MATH-1269 > Project: Commons Math > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Otmar Ertl > Attachments: MATH-1269.patch, MATH-1269.patch > > > I have observed that FastMath.exp(709.8125) returns NaN. However, the > exponential function must never return NaN (if the argument is not NaN). The > result must always be non-negative or positive infinity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1269) FastMath.exp may return NaN for non-NaN arguments
[ https://issues.apache.org/jira/browse/MATH-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14739384#comment-14739384 ] Otmar Ertl commented on MATH-1269: -- +1 for 2nd patch, I have run the test over the range (MAX_LONG - 1, MAX_LONG + 1), I think that should be enough to assume that there is a clean transition from finite to infinite. > FastMath.exp may return NaN for non-NaN arguments > - > > Key: MATH-1269 > URL: https://issues.apache.org/jira/browse/MATH-1269 > Project: Commons Math > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Otmar Ertl > Attachments: MATH-1269.patch, MATH-1269.patch > > > I have observed that FastMath.exp(709.8125) returns NaN. However, the > exponential function must never return NaN (if the argument is not NaN). The > result must always be non-negative or positive infinity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1246) Kolmogorov-Smirnov 2-sample test does not correctly handle ties
[ https://issues.apache.org/jira/browse/MATH-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14739536#comment-14739536 ] Otmar Ertl commented on MATH-1246: -- The Monte Carlo approach can be modified by simultaneously sampling D. Here is an outline how this sampling could be achieved: # First determine set of points P = (p_i) for which equal values exist in both samples. # Determine maximum difference of CDFs over all values not included in P # Determine for each point p_i if it is possible at all to get a CDF difference that is larger than the calculated maximum. If not, those points can be excluded from P. Otherwise, remember the difference of the CDF d_i just before that point and the number of equal values in both samples n_i and m_i, respectively. # Within each Monte Carlo iteration, generate for each point p_i a random ordering of the n_i and m_i equal values (using a function similar to fillBooleanArrayRandomlyWithFixedNumberTrueValues). Determine the maximum differences of the CDFs at all points p_i using the random ordering and d_i, and take the maximum of them and the maximum calculated in 2) which gives us the sampled (observed) D-statistic that is finally compared to curD. Anyway, we should find the right definition first before implementing anything. > Kolmogorov-Smirnov 2-sample test does not correctly handle ties > --- > > Key: MATH-1246 > URL: https://issues.apache.org/jira/browse/MATH-1246 > Project: Commons Math > Issue Type: Bug >Reporter: Phil Steitz > > For small samples, KolmogorovSmirnovTest(double[], double[]) computes the > distribution of a D-statistic for m-n sets with no ties. No warning or > special handling is delivered in the presence of ties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1272) FastMath.pow(double, long) enters an infinite loop with Long.MIN_VALUE
Qualtagh created MATH-1272: -- Summary: FastMath.pow(double, long) enters an infinite loop with Long.MIN_VALUE Key: MATH-1272 URL: https://issues.apache.org/jira/browse/MATH-1272 Project: Commons Math Issue Type: Bug Affects Versions: 3.5, 4.0 Reporter: Qualtagh Priority: Minor Fix For: 4.0 FastMath.pow(double, long) enters an infinite loop with Long.MIN_VALUE. It cannot be negated, so unsigned shift (>>>) is required instead of a signed one (>>). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1272) FastMath.pow(double, long) enters an infinite loop with Long.MIN_VALUE
[ https://issues.apache.org/jira/browse/MATH-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qualtagh updated MATH-1272: --- Attachment: MATH-1272.patch > FastMath.pow(double, long) enters an infinite loop with Long.MIN_VALUE > -- > > Key: MATH-1272 > URL: https://issues.apache.org/jira/browse/MATH-1272 > Project: Commons Math > Issue Type: Bug >Affects Versions: 4.0, 3.5 >Reporter: Qualtagh >Priority: Minor > Labels: patch > Fix For: 4.0 > > Attachments: MATH-1272.patch > > > FastMath.pow(double, long) enters an infinite loop with Long.MIN_VALUE. It > cannot be negated, so unsigned shift (>>>) is required instead of a signed > one (>>). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
