[jira] [Commented] (MATH-1341) "RandomDataGenerator" is brittle
[ https://issues.apache.org/jira/browse/MATH-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15282935#comment-15282935 ] Luc Maisonobe commented on MATH-1341: - Seems good to me. > "RandomDataGenerator" is brittle > > > Key: MATH-1341 > URL: https://issues.apache.org/jira/browse/MATH-1341 > Project: Commons Math > Issue Type: Bug >Reporter: Gilles >Priority: Minor > Labels: API, cleanup, deprecation, thread-safety > Fix For: 4.0 > > Attachments: RandomUtils.java > > > Class {{RandomDataGenerator}} can easily be misused as it advertizes a method > to access its internal RNG (which is _not_ thread-safe). > The class is also a mixed bag of "data generators" that are either "secure" > or not. > Moreover it uses the "lazy initialization" pattern (for the RNG instance) > solely because of this duality; otherwise users that need one or the other > form of data generation will obviously always use the RNG since all data > generation methods need it. > This entails also a performance hit (albeit tiny) as each call checks whether > the RNG has been initialized already. > The clean solution would be to separate the two types of data generation > (secure vs not) into different classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1158) Factory method to provide sampling from distributions
[ https://issues.apache.org/jira/browse/MATH-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166884#comment-15166884 ] Luc Maisonobe commented on MATH-1158: - No objections. > Factory method to provide sampling from distributions > - > > Key: MATH-1158 > URL: https://issues.apache.org/jira/browse/MATH-1158 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.3 >Reporter: Gilles >Priority: Blocker > Labels: API, deprecation > Fix For: 4.0 > > Attachments: MATH-1158.patch > > > A proposal to separate the sampling functionality from the core of the > distribution classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1313) Wrong tolerance in some unit tests of "RandomGeneratorAbstractTest"
[ https://issues.apache.org/jira/browse/MATH-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15091108#comment-15091108 ] Luc Maisonobe commented on MATH-1313: - Testing uniformity seems better than what we currently have, so +1 for changing the test. > Wrong tolerance in some unit tests of "RandomGeneratorAbstractTest" > --- > > Key: MATH-1313 > URL: https://issues.apache.org/jira/browse/MATH-1313 > Project: Commons Math > Issue Type: Bug >Reporter: Gilles >Assignee: Gilles >Priority: Minor > Labels: unit-test > Fix For: 4.0 > > > I doubt that the mean check in the unit test below is ever going to trigger > an assertion failure... > {noformat} > @Test > public void testDoubleDirect() { > SummaryStatistics sample = new SummaryStatistics(); > final int N = 1; > for (int i = 0; i < N; ++i) { > sample.addValue(generator.nextDouble()); > } > Assert.assertEquals("Note: This test will fail randomly about 1 in > 100 times.", > 0.5, sample.getMean(), FastMath.sqrt(N/12.0) * 2.576); > Assert.assertEquals(1.0 / (2.0 * FastMath.sqrt(3.0)), > sample.getStandardDeviation(), 0.01); > } > {noformat} > And similar in "testFloatDirect()". > I propose the following replacement: > {noformat} > @Test > public void testDoubleDirect() { > SummaryStatistics sample = new SummaryStatistics(); > final int N = 10; > for (int i = 0; i < N; ++i) { > sample.addValue(generator.nextDouble()); > } > assertUniformInUnitInterval(sample, 0.99); > } > {noformat} > where "assertUniformInUnitInterval" is defined as: >{noformat} > /** > > > * Check that the sample follows a uniform distribution on the {@code [0, > 1)} interval. > > * > > > * @param sample Data summary. > > > * @param confidenceIntervalLevel Confidence level. Must be in {@code (0, > 1)} interval. > > */ > private void assertUniformInUnitInterval(SummaryStatistics sample, > double confidenceIntervalLevel) { > final int numSamples = (int) sample.getN(); > final double mean = sample.getMean(); > final double stddev = sample.getStandardDeviation() / > FastMath.sqrt(numSamples); > final TDistribution t = new TDistribution(numSamples - 1); > final double criticalValue = t.inverseCumulativeProbability(1 - 0.5 * > (1 - confidenceIntervalLevel)); > final double tol = stddev * criticalValue; > Assert.assertEquals("mean=" + mean + " tol=" + tol + " (note: This > test will fail randomly about " + > (100 * (1 - confidenceIntervalLevel)) + " in 100 > times).", > 0.5, mean, tol); > Assert.assertEquals(FastMath.sqrt(1d / 12), > sample.getStandardDeviation(), 0.01); > } > {noformat} > Please correct if this new test is not what was intended. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1314) RNG: Warn users about "seeding"
[ https://issues.apache.org/jira/browse/MATH-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15091112#comment-15091112 ] Luc Maisonobe commented on MATH-1314: - Nothing can ensure *all* seed are good enough. For any procedure, there will be corner cases that may be poor. The procedures that we have now were provided by the algorithm creators, we cannot do anything more than trusting these experts. I don't think we can provide any tools. The generators are good, and they do create an entropy pool efficiently. Checking the very slight non-uniformity of these pool is beyond our capabilities. We could do that if the generators were poor, but they are good. Concerning the performances, they we obtained on my machine, and its characteristics are shown, because as usual the results depend on the computer. They are not expected to be really accurate, only to give some rough order of magnitudes. Also as the implementations were changed since the benchmarks have been run, I am not surprised these rough order of magnitudes are not true anymore. So you can either remove the table or update it. Is the MersenneTwister much faster or only marginally faster? > RNG: Warn users about "seeding" > --- > > Key: MATH-1314 > URL: https://issues.apache.org/jira/browse/MATH-1314 > Project: Commons Math > Issue Type: Wish >Reporter: Gilles > Labels: doc > Fix For: 4.0 > > > The "package-info.java" file of {{o.a.c.m.random}} does not mention the > problem of seeding. > Many users of CM could not be aware that it is not sufficient to "randomly" > choose a seed in order to ensure a random sequence. > I think that this is what is illustrated by random failures of some unit > tests (when the seed is "randomly" selected). > Do the intricate initialization procedures provided in some implementations > (WELL family and ISAAC) ensure that all seeds are good enough? > Should we provide some tool to test a seed? > By the way, the WELL performances listed on [this > table|http://commons.apache.org/proper/commons-math/javadocs/api-3.6/org/apache/commons/math3/random/package-summary.html] > do not correspond to the results obtained on my machine with our > {{PerfTestUtils}} benchmark: the {{MersenneTwister}} is invariably faster > than all WELL implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1300) BitsStreamGenerator#nextBytes(byte[]) is wrong
[ https://issues.apache.org/jira/browse/MATH-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe updated MATH-1300: Fix Version/s: 3.6 > BitsStreamGenerator#nextBytes(byte[]) is wrong > -- > > Key: MATH-1300 > URL: https://issues.apache.org/jira/browse/MATH-1300 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Rostislav Krasny > Fix For: 3.6 > > Attachments: MersenneTwister2.java, TestMersenneTwister.java > > > Sequential calls to the BitsStreamGenerator#nextBytes(byte[]) must generate > the same sequence of bytes, no matter by chunks of which size it was divided. > This is also how java.util.Random#nextBytes(byte[]) works. > When nextBytes(byte[]) is called with a bytes array of length multiple of 4 > it makes one unneeded call to next(int) method. This is wrong and produces an > inconsistent behavior of classes like MersenneTwister. > I made a new implementation of the BitsStreamGenerator#nextBytes(byte[]) see > attached code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1304) "nextBytes" methods in RNG implementations
[ https://issues.apache.org/jira/browse/MATH-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe updated MATH-1304: Fix Version/s: 3.6 > "nextBytes" methods in RNG implementations > -- > > Key: MATH-1304 > URL: https://issues.apache.org/jira/browse/MATH-1304 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Gilles >Assignee: Gilles > Fix For: 4.0, 3.6 > > > There are two implementations of the "nextBytes" method. > One is in {{AbstractRandomGenerator}} and the other in > {{BitsStreamGenerator}}. > The code should be the same. > And, if possible, it should be shared. > MATH-1300 has several suggestions for improving the current implementations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1305) Improve performance of nextBytes() method of BitsStreamGenerator and AbstractRandomGenerator
[ https://issues.apache.org/jira/browse/MATH-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe updated MATH-1305: Fix Version/s: 3.6 > Improve performance of nextBytes() method of BitsStreamGenerator and > AbstractRandomGenerator > - > > Key: MATH-1305 > URL: https://issues.apache.org/jira/browse/MATH-1305 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 4.0, 3.5, 3.6 >Reporter: Rostislav Krasny > Fix For: 3.6 > > > I propose to use this code in {{BitsStreamGenerator}} > {code:java} > @Override > public void nextBytes(byte[] bytes) { > int index = 0; > // multiple 4 part of length, i.e. length with two least > significant bits unset > int max = bytes.length & 0x7ffc; > // start filling the byte array with tetrads of bytes > while (index < max) { > int random = next(32); > bytes[index++] = (byte) random; > bytes[index++] = (byte) (random >>> 8); > bytes[index++] = (byte) (random >>> 16); > bytes[index++] = (byte) (random >>> 24); > } > // fill the remains bytes > if (index < bytes.length) { > int random = next(32); > while (true) { > bytes[index++] = (byte) random; > if (index < bytes.length) { > random >>>= 8; > } else { > break; > } > } > } > } > {code} > I also propose to use the same code but with {{nextInt()}} calls instead of > {{next(32)}} in the {{AbstractRandomGenerator}}. This implementation improves > performance and fixes inconsistency bugs in those two classes discussed in > the MATH-1300. It is also quite simple and well commented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1281) "Median" should not extend "Percentile"
[ https://issues.apache.org/jira/browse/MATH-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe updated MATH-1281: Fix Version/s: (was: 3.6) > "Median" should not extend "Percentile" > --- > > Key: MATH-1281 > URL: https://issues.apache.org/jira/browse/MATH-1281 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Gilles >Priority: Minor > Fix For: 4.0 > > > Class {{Median}} (package {{o.a.c.m.stat.descriptive.rank}} inherits several > {{evaluate}} methods from {{Percentile}} where one of the arguments is the > percentile value. That doesn't make sense, and easily allows for user bugs. > Either those inherited methods should be overridden by methods that throw a > "forbidden" exception, or perhaps more correctly (but not > backwards-compatible), the methods with a specific percentile argument should > be made "static". The latter would also fix the same problem in the > {{Percentile}} class itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1285) Description API ZipfDistribution
[ https://issues.apache.org/jira/browse/MATH-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1285. - Resolution: Fixed > Description API ZipfDistribution > > > Key: MATH-1285 > URL: https://issues.apache.org/jira/browse/MATH-1285 > Project: Commons Math > Issue Type: Improvement > Environment: All >Reporter: Pim van der Hoorn >Priority: Minor > Labels: easyfix > Fix For: 4.0, 3.6 > > Original Estimate: 1h > Remaining Estimate: 1h > > The description of the constructors for the ZipfDistribution class specifies > an argument of type doule, called exponent. The documentation refers to a > MathWorld page where the distribution is defined. However, here the exponent > p, is the exponent of the cdf, not of the pdf (which is then p + 1). After > running some test I found that the exponent in the constructor is the one for > the pdf. This can create confusion among users. Therefore I recommend > specifying in the documentation which exponent is meant. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1302) Rotation constructor with RotationOrder and angles produces wrong rotation
[ https://issues.apache.org/jira/browse/MATH-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1302. - Resolution: Fixed Two methods, compose and composeInverse have been added. They both allow specifying rotation convention. > Rotation constructor with RotationOrder and angles produces wrong rotation > -- > > Key: MATH-1302 > URL: https://issues.apache.org/jira/browse/MATH-1302 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: James Boyer > Assignee: Luc Maisonobe > Fix For: 3.6 > > Original Estimate: 3h > Remaining Estimate: 3h > > Rotation constructor taking (RotationOrder, double, double, double) has the > local variable "composed" set to an incorrect rotation because the use of r1 > and r3 are swapped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1297) multistep integrator start failure triggers NPE
[ https://issues.apache.org/jira/browse/MATH-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1297. - Resolution: Fixed Fixed in git repository, both in MATH_3_X and master branches. > multistep integrator start failure triggers NPE > --- > > Key: MATH-1297 > URL: https://issues.apache.org/jira/browse/MATH-1297 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Luc Maisonobe > Assignee: Luc Maisonobe > Fix For: 3.6 > > > Multistep ODE integrators like Adams-Bashforth and Adams-Moulton require a > starter procedure. > If the starter integrator is not configured properly, it will not create the > necessary number of initial points and the multistep integrator will not be > initialized correctly. This results in NullPointErException when the scaling > array is referenced later on. > The following test case (with an intentionally wrong starter configuration) > shows the problem. > {code} > @Test > public void testStartFailure() { > TestProblem1 pb = new TestProblem1(); > double minStep = 0.0001 * (pb.getFinalTime() - pb.getInitialTime()); > double maxStep = pb.getFinalTime() - pb.getInitialTime(); > double scalAbsoluteTolerance = 1.0e-6; > double scalRelativeTolerance = 1.0e-7; > MultistepIntegrator integ = > new AdamsBashforthIntegrator(4, minStep, maxStep, > > scalAbsoluteTolerance, > > scalRelativeTolerance); > integ.setStarterIntegrator(new DormandPrince853Integrator(0.2 * > (pb.getFinalTime() - pb.getInitialTime()), > > pb.getFinalTime() - pb.getInitialTime(), > 0.1, 0.1)); > TestProblemHandler handler = new TestProblemHandler(pb, integ); > integ.addStepHandler(handler); > integ.integrate(pb, > pb.getInitialTime(), pb.getInitialState(), > pb.getFinalTime(), new > double[pb.getDimension()]); > } > {code} > Failure to start the integrator should be detected and an appropriate > exception should be triggered. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1302) Rotation constructor with RotationOrder and angles produces wrong rotation
[ https://issues.apache.org/jira/browse/MATH-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1302. - Resolution: Fixed Fix Version/s: 3.6 The issue has been fixed in git repository (both MATH_3_X branch and master branch). I have kept the enumerate approach. It allows user to select the convention at runtime. It can be used for example in some intermediate libraries that cannot know by themselves the conventions the user wants to select. > Rotation constructor with RotationOrder and angles produces wrong rotation > -- > > Key: MATH-1302 > URL: https://issues.apache.org/jira/browse/MATH-1302 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: James Boyer > Fix For: 3.6 > > Original Estimate: 3h > Remaining Estimate: 3h > > Rotation constructor taking (RotationOrder, double, double, double) has the > local variable "composed" set to an incorrect rotation because the use of r1 > and r3 are swapped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1303) Rotation.getAngles produces wrong angles for Cardan RotationOrders
[ https://issues.apache.org/jira/browse/MATH-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1303. - Resolution: Fixed Fix Version/s: 3.6 The issue has been fixed in git repository (both MATH_3_X branch and master branch). The getAngles method know accepts both vector operator or frame transform convention. The first convention was the one used op to 3.5, and explains the order of the angles. The second convention is new in 3.6 and corresponds to the order you requested. > Rotation.getAngles produces wrong angles for Cardan RotationOrders > -- > > Key: MATH-1303 > URL: https://issues.apache.org/jira/browse/MATH-1303 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: James Boyer > Fix For: 3.6 > > > See MATH-1302 first. > Because unit tests for getAngles relies upon the Rotation constructor > described in MATH-1302 to work and the constructor does not actually work, > getAngles is passing tests when it actually shouldn't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (MATH-1302) Rotation constructor with RotationOrder and angles produces wrong rotation
[ https://issues.apache.org/jira/browse/MATH-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe reopened MATH-1302: - Assignee: Luc Maisonobe The applyTo(Rotation) method should also expose the rotation convention. Currently, the method imposes vector operator convention. > Rotation constructor with RotationOrder and angles produces wrong rotation > -- > > Key: MATH-1302 > URL: https://issues.apache.org/jira/browse/MATH-1302 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: James Boyer > Assignee: Luc Maisonobe > Fix For: 3.6 > > Original Estimate: 3h > Remaining Estimate: 3h > > Rotation constructor taking (RotationOrder, double, double, double) has the > local variable "composed" set to an incorrect rotation because the use of r1 > and r3 are swapped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1302) Rotation constructor with RotationOrder and angles produces wrong rotation
[ https://issues.apache.org/jira/browse/MATH-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066239#comment-15066239 ] Luc Maisonobe commented on MATH-1302: - No. The order is the right one. What you present is a very well known consequence of a convention that is already explained at length in the Javadoc. You can look at the javadoc of the Rotation(Vector axis, double angle) constructor. We *know* some people do not like this convention. The problem is that a rotation can be considered either as a vector operator that moves vectors with respect to a fixed reference frame, or it can be seen as a frame conversion operator that moves frames while vectors are kept fixed. Suppose that for example we simply state: rotation r is a 90 degrees rotation around the Z axis. Using the first convention (fixed frame, moving vectors), the image of vector with coordinates (1, 2, 3) would be vector (-2, 1, 3). This means that the vector rotates counterclockwise. Using the second convention (the frames rotates), then the image of vector with coordinates (1, 2, 3) would be vector (2, -1, 3) because the frame rotates counterclockwise, so the fixed vector appears to rotate in the opposite direction. Apache Commons Math uses the first convention, because it is focused on representing a vectorial operator. The other convention, which Apache Commons Math does not use, is more often encountered in the following fields of applications: frames transforms (typically 3D scenes modelization) or attitude in space flight dynamics. When people work in these fields (and in fact I do work in space flight dynamics and attitude), then one as to be aware of the different conventions and as to think that the angle alpha that Apache Commons Math expect is a perfectly well defined angle that is simply the opposite of the one I have at hand. So when I build my rotation, I simply have to pass -alpha, and when I retrieve the angle using getAngle, I have to change its sign after retrieval. As this topic comes back from time to time, we *may* add an enumerate for specifying the convention in the two constructors involved (one axis and one angle or one rotation order and three angles) and the symmetrical getters. However, simply changing from one convention to the other without any hint for the user to which convention is used is not gonna happen. There are no reasons why the other convention is right and the current convention is wrong. They are simply that: conventions. They are relevant in different fields of applications. What would you think about we add an enumerate, which could be for example VECTOR_OPERATOR_CONVENTION and FRAMES_CONVERSION_CONVENTION? > Rotation constructor with RotationOrder and angles produces wrong rotation > -- > > Key: MATH-1302 > URL: https://issues.apache.org/jira/browse/MATH-1302 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: James Boyer > Original Estimate: 3h > Remaining Estimate: 3h > > Rotation constructor taking (RotationOrder, double, double, double) has the > local variable "composed" set to an incorrect rotation because the use of r1 > and r3 are swapped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1300) BitsStreamGenerator#nextBytes(byte[]) is wrong
[ https://issues.apache.org/jira/browse/MATH-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065726#comment-15065726 ] Luc Maisonobe commented on MATH-1300: - In fact, the code from Apache Commons Math come from the mantissa project. Mantissa is obsolete, it was a single person project (myself). I joined the Apache Commons project to continue the work there. The complete Mantissa library was donated to Apache at that time and merged. The Apache version of this code is therefore the most up to date one. > BitsStreamGenerator#nextBytes(byte[]) is wrong > -- > > Key: MATH-1300 > URL: https://issues.apache.org/jira/browse/MATH-1300 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Rostislav Krasny > Attachments: MersenneTwister2.java, TestMersenneTwister.java > > > Sequential calls to the BitsStreamGenerator#nextBytes(byte[]) must generate > the same sequence of bytes, no matter by chunks of which size it was divided. > This is also how java.util.Random#nextBytes(byte[]) works. > When nextBytes(byte[]) is called with a bytes array of length multiple of 4 > it makes one unneeded call to next(int) method. This is wrong and produces an > inconsistent behavior of classes like MersenneTwister. > I made a new implementation of the BitsStreamGenerator#nextBytes(byte[]) see > attached code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1300) BitsStreamGenerator#nextBytes(byte[]) is wrong
[ https://issues.apache.org/jira/browse/MATH-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065729#comment-15065729 ] Luc Maisonobe commented on MATH-1300: - My position would be that even if having values independent of chunk size is a nice features, it is not worth degrading either understandability or performances for it. So just advertising the fact this property does *not* hold would be fine to me. I'm also not sure losing much time with Mersenne twister is worth it. This generator was the best one a few years ago but has been superseded with the WELL family of generators almost 10 years ago (see http://www.iro.umontreal.ca/~panneton/WELLRNG.html, where a mink to the reference paper can be found). According to the paper, the Mersenne twister suffers fro a lack of chaos at the start (i.e. the first few millions generations) that the WELL generators fix. > BitsStreamGenerator#nextBytes(byte[]) is wrong > -- > > Key: MATH-1300 > URL: https://issues.apache.org/jira/browse/MATH-1300 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Rostislav Krasny > Attachments: MersenneTwister2.java, TestMersenneTwister.java > > > Sequential calls to the BitsStreamGenerator#nextBytes(byte[]) must generate > the same sequence of bytes, no matter by chunks of which size it was divided. > This is also how java.util.Random#nextBytes(byte[]) works. > When nextBytes(byte[]) is called with a bytes array of length multiple of 4 > it makes one unneeded call to next(int) method. This is wrong and produces an > inconsistent behavior of classes like MersenneTwister. > I made a new implementation of the BitsStreamGenerator#nextBytes(byte[]) see > attached code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1300) BitsStreamGenerator#nextBytes(byte[]) is wrong
[ https://issues.apache.org/jira/browse/MATH-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065748#comment-15065748 ] Luc Maisonobe commented on MATH-1300: - If it is unnecessary, sure it can be removed. Indicating that the WELL generators are considered more up to date than the Mersenne Twister would be nice too. > BitsStreamGenerator#nextBytes(byte[]) is wrong > -- > > Key: MATH-1300 > URL: https://issues.apache.org/jira/browse/MATH-1300 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Rostislav Krasny > Attachments: MersenneTwister2.java, TestMersenneTwister.java > > > Sequential calls to the BitsStreamGenerator#nextBytes(byte[]) must generate > the same sequence of bytes, no matter by chunks of which size it was divided. > This is also how java.util.Random#nextBytes(byte[]) works. > When nextBytes(byte[]) is called with a bytes array of length multiple of 4 > it makes one unneeded call to next(int) method. This is wrong and produces an > inconsistent behavior of classes like MersenneTwister. > I made a new implementation of the BitsStreamGenerator#nextBytes(byte[]) see > attached code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1297) multistep integrator start failure triggers NPE
Luc Maisonobe created MATH-1297: --- Summary: multistep integrator start failure triggers NPE Key: MATH-1297 URL: https://issues.apache.org/jira/browse/MATH-1297 Project: Commons Math Issue Type: Bug Affects Versions: 3.5 Reporter: Luc Maisonobe Assignee: Luc Maisonobe Fix For: 3.6 Multistep ODE integrators like Adams-Bashforth and Adams-Moulton require a starter procedure. If the starter integrator is not configured properly, it will not create the necessary number of initial points and the multistep integrator will not be initialized correctly. This results in NullPointErException when the scaling array is referenced later on. The following test case (with an intentionally wrong starter configuration) shows the problem. {code} @Test public void testStartFailure() { TestProblem1 pb = new TestProblem1(); double minStep = 0.0001 * (pb.getFinalTime() - pb.getInitialTime()); double maxStep = pb.getFinalTime() - pb.getInitialTime(); double scalAbsoluteTolerance = 1.0e-6; double scalRelativeTolerance = 1.0e-7; MultistepIntegrator integ = new AdamsBashforthIntegrator(4, minStep, maxStep, scalAbsoluteTolerance, scalRelativeTolerance); integ.setStarterIntegrator(new DormandPrince853Integrator(0.2 * (pb.getFinalTime() - pb.getInitialTime()), pb.getFinalTime() - pb.getInitialTime(), 0.1, 0.1)); TestProblemHandler handler = new TestProblemHandler(pb, integ); integ.addStepHandler(handler); integ.integrate(pb, pb.getInitialTime(), pb.getInitialState(), pb.getFinalTime(), new double[pb.getDimension()]); } {code} Failure to start the integrator should be detected and an appropriate exception should be triggered. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1288) Allow ordinary differential equations to use Field
[ https://issues.apache.org/jira/browse/MATH-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1288. - Resolution: Fixed The feature has been merged into MATH_3_X branch (commit 10c271f). > Allow ordinary differential equations to use Field > -- > > Key: MATH-1288 > URL: https://issues.apache.org/jira/browse/MATH-1288 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.5 >Reporter: Luc Maisonobe > Assignee: Luc Maisonobe >Priority: Minor > Fix For: 3.6 > > > Several algorithms in Apache Commons Math already provide one implementation > for primitive double and another implementation for RealField elements. Among > these are linear algebra, solvers and geometry. > It would be fine to also have such a feature for ODE. > A side effect of developing this would be to test a simplified API that could > later be backported to the double[] ode implementation in the 4.X series. > Implementing this is quite simple (but involves numerous classes and > interfaces, since the ode package is large) as it mainly consists in changing > types from double to T (with T the parameter for the class) and replacing the > operations with calls to add, subtract, multiply ... > As an initial step, providing this feature for only a small subset of > existing integrators would be sufficient (typically Dormand-Prince 8(5, 3) > would be needed). More complex integrators like Gragg-Bulirsch-Stoer could be > done later on. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MATH-1289) Incorrect calculation in org.apache.commons.math3.complex.Complex#multiply
[ https://issues.apache.org/jira/browse/MATH-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15005989#comment-15005989 ] Luc Maisonobe edited comment on MATH-1289 at 11/15/15 6:43 PM: --- The expressions used in the library are correct. With your expressions, computing I^2 would give +1 instead of -1. and multiplication would not be commutative (for example I * 1 would be the opposite of 1 * I). Remember that in the complex class, the imaginary field is a *real* value holding the multiplicative factor to be applied to I (the square root of -1). In other words z = real + I * imaginary. So {noformat} z1 * z2 = (r1 + I * i1) * (r2 + I * i2) = (r1 * r2 + I * r1 * i2 + I * i1 * r2 + I * I * i1 * i2) = (r1 * r2 + I * I * i1 * i2) + I * (r1 * i2 + i1 * r2) = (r1 * r2 - i1 * i2) + I * (r1 * i2 + i1 * r2) {noformat} which is exactly the expression in the library. was (Author: luc): The expressions used in the library are correct. With your expressions, computing I^2 would give +1 instead of -1. and multiplication would not be commutative (for example I * 1 would be the opposite of 1 * I). Remember that in the complex class, the imaginary field is a *real* value holding the multiplicative factor to be applied to I (the square root of -1). In other words z = real + I * imaginary. So {noformat} z1 * z2 = (r1 + I * i1) * (r2 + I * i2) = (r1 * r2 + I * r1 * i2 + I * i1 * r2 + I * I * i1 * i2) = (r1 * r2 + I * I * i1 * i1) + I * (r1 * i2 + i1 * r2) = (r1 * r2 - i1 * i2) + I * (r1 * i2 + i1 * r2) {noformat} which is exactly the expression in the library. > Incorrect calculation in org.apache.commons.math3.complex.Complex#multiply > -- > > Key: MATH-1289 > URL: https://issues.apache.org/jira/browse/MATH-1289 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 > Environment: Linux 3.16.0-44-generic #59-Ubuntu SMP Tue Jul 7 > 02:07:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > java version "1.8.0_45" > Java(TM) SE Runtime Environment (build 1.8.0_45-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) >Reporter: Detaille Octave > Labels: easyfix > > Hello guys! > If think there is a bug in the > org.apache.commons.math3.complex.Complex#multiply method > Line 536 & 537 below are not correct > {code:title=Complex.java|borderStyle=solid} > return createComplex(real * factor.real - imaginary * factor.imaginary, real > * factor.imaginary + imaginary * factor.real); > {code} > It should be > {code:title=Complex.java|borderStyle=solid} > return createComplex(real * factor.real + imaginary * factor.imaginary, > imaginary * factor.real-real * factor.imaginary); > {code} > Can you confirm that? Or do I miss something? > Thanks a lot (also, for this excellent library). > Best, > Octave -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1289) Incorrect calculation in org.apache.commons.math3.complex.Complex#multiply
[ https://issues.apache.org/jira/browse/MATH-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1289. - Resolution: Invalid The expressions used in the library are correct. With your expressions, computing I^2 would give +1 instead of -1. and multiplication would not be commutative (for example I * 1 would be the opposite of 1 * I). Remember that in the complex class, the imaginary field is a *real* value holding the multiplicative factor to be applied to I (the square root of -1). In other words z = real + I * imaginary. So {noformat} z1 * z2 = (r1 + I * i1) * (r2 + I * i2) = (r1 * r2 + I * r1 * i2 + I * i1 * r2 + I * I * i1 * i2) = (r1 * r2 + I * I * i1 * i1) + I * (r1 * i2 + i1 * r2) = (r1 * r2 - i1 * i2) + I * (r1 * i2 + i1 * r2) {noformat} which is exactly the expression in the library. > Incorrect calculation in org.apache.commons.math3.complex.Complex#multiply > -- > > Key: MATH-1289 > URL: https://issues.apache.org/jira/browse/MATH-1289 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 > Environment: Linux 3.16.0-44-generic #59-Ubuntu SMP Tue Jul 7 > 02:07:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > java version "1.8.0_45" > Java(TM) SE Runtime Environment (build 1.8.0_45-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) >Reporter: Detaille Octave > Labels: easyfix > > Hello guys! > If think there is a bug in the > org.apache.commons.math3.complex.Complex#multiply method > Line 536 & 537 below are not correct > {code:title=Complex.java|borderStyle=solid} > return createComplex(real * factor.real - imaginary * factor.imaginary, real > * factor.imaginary + imaginary * factor.real); > {code} > It should be > {code:title=Complex.java|borderStyle=solid} > return createComplex(real * factor.real + imaginary * factor.imaginary, > imaginary * factor.real-real * factor.imaginary); > {code} > Can you confirm that? Or do I miss something? > Thanks a lot (also, for this excellent library). > Best, > Octave -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1288) Allow ordinary differential equations to use Field
[ https://issues.apache.org/jira/browse/MATH-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15001013#comment-15001013 ] Luc Maisonobe commented on MATH-1288: - Work on this new feature has been started on a dedicated branch named field-ode. The branch will be merged on the MATH_3_X branch when it is ready. > Allow ordinary differential equations to use Field > -- > > Key: MATH-1288 > URL: https://issues.apache.org/jira/browse/MATH-1288 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.5 >Reporter: Luc Maisonobe > Assignee: Luc Maisonobe >Priority: Minor > Fix For: 3.6 > > > Several algorithms in Apache Commons Math already provide one implementation > for primitive double and another implementation for RealField elements. Among > these are linear algebra, solvers and geometry. > It would be fine to also have such a feature for ODE. > A side effect of developing this would be to test a simplified API that could > later be backported to the double[] ode implementation in the 4.X series. > Implementing this is quite simple (but involves numerous classes and > interfaces, since the ode package is large) as it mainly consists in changing > types from double to T (with T the parameter for the class) and replacing the > operations with calls to add, subtract, multiply ... > As an initial step, providing this feature for only a small subset of > existing integrators would be sufficient (typically Dormand-Prince 8(5, 3) > would be needed). More complex integrators like Gragg-Bulirsch-Stoer could be > done later on. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=14973146#comment-14973146 ] Luc Maisonobe commented on MATH-1284: - I agree that vector is not a point. This issue was discussed (shortly) on the developers list on May 22nd 2011. You can look here <http://mail-archives.apache.org/mod_mbox/commons-dev/201105.mbox/browser> for the thread or here <http://commons.markmail.org/search/list:org.apache.common.dev+%22affine+and+vector+spaces%22>. One argument for merging was that the difference was too subtle and merging the two concepts was quite common. The other argument was that our interface is not restricted to Euclidean space but also encompasses spherical geometry (we do use it for BSP trees on the 1-sphere and on the 2-sphere for example). So we decided to stick to a single representation and in the Vector Javadoc we state: This interface represents a generic vector in a vectorial space or a point in an affine space. This implies users are free to decide by themselves what is the semantic of the object they use. The Transform interface defined in the lower partitioning package needs to know about the semantics. Therefore, it specifically states it represents a transform in *affine* space. On the other hand, the Rotation class in the euclidean.threed package is an operator acting in a vector space, and it does *not* implement the aforementioned Transform interface. I would indeed be glad to separate the two concepts, but has to think really a lot about it in spherical geometry. > 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.4#6332)
[jira] [Created] (MATH-1275) EventHandler and StepHandler interfaces do not provide derivatives
Luc Maisonobe created MATH-1275: --- Summary: EventHandler and StepHandler interfaces do not provide derivatives Key: MATH-1275 URL: https://issues.apache.org/jira/browse/MATH-1275 Project: Commons Math Issue Type: Bug Affects Versions: 3.5 Reporter: Luc Maisonobe Fix For: 4.0 The EventHandler and StepHandler interfaces allow passing the current state vector to user code, but not its derivatives. This is a pity because the integrator does know these derivatives as they are the basis from which everything else is computed. The data is lying around, just not passed to user. This is a design issue and as it affects user interfaces, it cannot be fixed before 4.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1271) Unsigned operations
[ https://issues.apache.org/jira/browse/MATH-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1271. - Resolution: Fixed Fix Version/s: 4.0 Patch applied with minor changes (whitespace and @since tags). Thanks for the report and for the patch. > 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 > Fix For: 4.0 > > Attachments: MATH-1271.patch > > > 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] [Resolved] (MATH-1273) Negative zero support in FastMath.pow
[ https://issues.apache.org/jira/browse/MATH-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1273. - Resolution: Fixed Fix Version/s: 3.6 Fixed in git repository, for both 4.0 and 3.X branches. Thanks for the report and for the patch! > Negative zero support in FastMath.pow > - > > Key: MATH-1273 > URL: https://issues.apache.org/jira/browse/MATH-1273 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 4.0 >Reporter: Qualtagh >Priority: Trivial > Fix For: 4.0, 3.6 > > Attachments: MATH-1273.patch > > > FastMath.pow(double, double) and FastMath.pow(double, long) functions never > return negative zero. > Math.pow(-0.0, 5.0) = -0.0 > FastMath.pow(-0.0, 5.0) = 0.0 > Math.pow(-, -3.0) = -0.0 > FastMath.pow(-, -3.0) = 0.0 > Added support for negative zero. > Also, added ultimate tests to cover all special cases described in Math.pow > javadoc. > Slightly edited an existing test: there were some typos and duplicates. -- 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] [Resolved] (MATH-1266) split and side methods may be inconsistent in BSP trees
[ https://issues.apache.org/jira/browse/MATH-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1266. - Resolution: Fixed Fix Version/s: 3.6 4.0 Fixed in git repository (commit 2091cfb for branch master, commit 50c5eae for branch MATH_3_X) > split and side methods may be inconsistent in BSP trees > --- > > Key: MATH-1266 > URL: https://issues.apache.org/jira/browse/MATH-1266 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Luc Maisonobe > Assignee: Luc Maisonobe > Fix For: 4.0, 3.6 > > > In BSP trees, there are two related methods dealing with the relative > position of a sub-hyperplane and an hyperplane: side and split. > sub.side(hyperplane) returns an enumerate (PLUS, MINUS, BOTH, HYPER) telling > the relative position of the syb-hyperplane with respect to the hyperplane. > sub.split(hyperplane) splits the sub-hyperplane in two parts, one on the plus > side of the hyperplane and one on the minus side of the hyperplane. > These methods should be consistent, i.e. when side returns BOTH, then split > should return two non-null parts. This fails in the following case: > {code} > @Test > public void testSideSplitConsistency() { > double tolerance = 1.0e-6; > Circle hyperplane = new Circle(new Vector3D(9.738804529764676E-5, > -0.6772824575010357, -0.7357230887208355), >tolerance); > SubCircle sub = new SubCircle(new Circle(new > Vector3D(2.1793884139073498E-4, 0.9790647032675541, -0.20354915700704285), > tolerance), > new ArcsSet(4.7121441684170700, > 4.7125386635004760, tolerance)); > SplitSubHyperplane split = sub.split(hyperplane); > Assert.assertNotNull(split.getMinus()); > Assert.assertNull(split.getPlus()); > Assert.assertEquals(Side.MINUS, sub.side(hyperplane)); > } > {code} > Here, side returns BOTH but the plus part is null. This is due to the plus > side being smaller than the tolerance (1.0e-6 here) and filtered out in the > split methods whereas it is not filtered out in the side method, which has a > slightly different algorithm. So instead of returning BOTH, side should > return MINUS as it should filter out the too small plus part. > In fact, it is only one particular case, the same could occur in other spaces > (Euclidean or Spherical, and on various dimensions). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1266) split and side methods may be inconsistent in BSP trees
Luc Maisonobe created MATH-1266: --- Summary: split and side methods may be inconsistent in BSP trees Key: MATH-1266 URL: https://issues.apache.org/jira/browse/MATH-1266 Project: Commons Math Issue Type: Bug Affects Versions: 3.5 Reporter: Luc Maisonobe Assignee: Luc Maisonobe In BSP trees, there are two related methods dealing with the relative position of a sub-hyperplane and an hyperplane: side and split. sub.side(hyperplane) returns an enumerate (PLUS, MINUS, BOTH, HYPER) telling the relative position of the syb-hyperplane with respect to the hyperplane. sub.split(hyperplane) splits the sub-hyperplane in two parts, one on the plus side of the hyperplane and one on the minus side of the hyperplane. These methods should be consistent, i.e. when side returns BOTH, then split should return two non-null parts. This fails in the following case: {code} @Test public void testSideSplitConsistency() { double tolerance = 1.0e-6; Circle hyperplane = new Circle(new Vector3D(9.738804529764676E-5, -0.6772824575010357, -0.7357230887208355), tolerance); SubCircle sub = new SubCircle(new Circle(new Vector3D(2.1793884139073498E-4, 0.9790647032675541, -0.20354915700704285), tolerance), new ArcsSet(4.7121441684170700, 4.7125386635004760, tolerance)); SplitSubHyperplane split = sub.split(hyperplane); Assert.assertNotNull(split.getMinus()); Assert.assertNull(split.getPlus()); Assert.assertEquals(Side.MINUS, sub.side(hyperplane)); } {code} In fact, it is only one particular case, the same could occur in other spaces (Euclidean or Spherical, and on various dimensions) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1266) split and side methods may be inconsistent in BSP trees
[ https://issues.apache.org/jira/browse/MATH-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe updated MATH-1266: Description: In BSP trees, there are two related methods dealing with the relative position of a sub-hyperplane and an hyperplane: side and split. sub.side(hyperplane) returns an enumerate (PLUS, MINUS, BOTH, HYPER) telling the relative position of the syb-hyperplane with respect to the hyperplane. sub.split(hyperplane) splits the sub-hyperplane in two parts, one on the plus side of the hyperplane and one on the minus side of the hyperplane. These methods should be consistent, i.e. when side returns BOTH, then split should return two non-null parts. This fails in the following case: {code} @Test public void testSideSplitConsistency() { double tolerance = 1.0e-6; Circle hyperplane = new Circle(new Vector3D(9.738804529764676E-5, -0.6772824575010357, -0.7357230887208355), tolerance); SubCircle sub = new SubCircle(new Circle(new Vector3D(2.1793884139073498E-4, 0.9790647032675541, -0.20354915700704285), tolerance), new ArcsSet(4.7121441684170700, 4.7125386635004760, tolerance)); SplitSubHyperplane split = sub.split(hyperplane); Assert.assertNotNull(split.getMinus()); Assert.assertNull(split.getPlus()); Assert.assertEquals(Side.MINUS, sub.side(hyperplane)); } {code} Here, side returns BOTH but the plus part is null. This is due to the plus side being smaller than the tolerance (1.0e-6 here) and filtered out in the split methods whereas it is not filtered out in the side method, which has a slightly different algorithm. So instead of returning BOTH, side should return MINUS as it should filter out the too small plus part. In fact, it is only one particular case, the same could occur in other spaces (Euclidean or Spherical, and on various dimensions). was: In BSP trees, there are two related methods dealing with the relative position of a sub-hyperplane and an hyperplane: side and split. sub.side(hyperplane) returns an enumerate (PLUS, MINUS, BOTH, HYPER) telling the relative position of the syb-hyperplane with respect to the hyperplane. sub.split(hyperplane) splits the sub-hyperplane in two parts, one on the plus side of the hyperplane and one on the minus side of the hyperplane. These methods should be consistent, i.e. when side returns BOTH, then split should return two non-null parts. This fails in the following case: {code} @Test public void testSideSplitConsistency() { double tolerance = 1.0e-6; Circle hyperplane = new Circle(new Vector3D(9.738804529764676E-5, -0.6772824575010357, -0.7357230887208355), tolerance); SubCircle sub = new SubCircle(new Circle(new Vector3D(2.1793884139073498E-4, 0.9790647032675541, -0.20354915700704285), tolerance), new ArcsSet(4.7121441684170700, 4.7125386635004760, tolerance)); SplitSubHyperplane split = sub.split(hyperplane); Assert.assertNotNull(split.getMinus()); Assert.assertNull(split.getPlus()); Assert.assertEquals(Side.MINUS, sub.side(hyperplane)); } {code} In fact, it is only one particular case, the same could occur in other spaces (Euclidean or Spherical, and on various dimensions) > split and side methods may be inconsistent in BSP trees > --- > > Key: MATH-1266 > URL: https://issues.apache.org/jira/browse/MATH-1266 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Luc Maisonobe > Assignee: Luc Maisonobe > > In BSP trees, there are two related methods dealing with the relative > position of a sub-hyperplane and an hyperplane: side and split. > sub.side(hyperplane) returns an enumerate (PLUS, MINUS, BOTH, HYPER) telling > the relative position of the syb-hyperplane with respect to the hyperplane. > sub.split(hyperplane) splits the sub-hyperplane in two parts, one on the plus > side of the hyperplane and one on the minus side of the hyperplane. > These methods should be consistent, i.e. when side returns BOTH, then split > should return two non-null parts. This fails in the following case: > {code} > @Test > public void testSideSplitConsistency() { > double tolerance = 1.0e-6; > Circle hyperplane = new Circle(new Vector3D(9.738804529764676E-5, > -0.6772824575010357, -0.7357230887208355), >tolerance); > SubCircle sub = new SubCircle(new Circl
[jira] [Created] (MATH-1232) UknownParameterException message prints {0} instead of parameter name
Luc Maisonobe created MATH-1232: --- Summary: UknownParameterException message prints {0} instead of parameter name Key: MATH-1232 URL: https://issues.apache.org/jira/browse/MATH-1232 Project: Commons Math Issue Type: Bug Affects Versions: 3.5 Reporter: Luc Maisonobe Priority: Trivial The constructor for UnknownParameterException stores the parameter name internally but does not forward it to the base class which creates the error message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1232) UknownParameterException message prints {0} instead of parameter name
[ https://issues.apache.org/jira/browse/MATH-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1232. - Resolution: Fixed Fix Version/s: 3.6 4.0 Fixed in git repository, both in master branch and MATH_3_X branch. UknownParameterException message prints {0} instead of parameter name - Key: MATH-1232 URL: https://issues.apache.org/jira/browse/MATH-1232 Project: Commons Math Issue Type: Bug Affects Versions: 3.5 Reporter: Luc Maisonobe Priority: Trivial Fix For: 4.0, 3.6 The constructor for UnknownParameterException stores the parameter name internally but does not forward it to the base class which creates the error message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1226) Exception thrown in ode for a pair of close events
[ https://issues.apache.org/jira/browse/MATH-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1226. - Resolution: Fixed Fix Version/s: 3.6 4.0 Fixed in git repository, as of commit c44bfe0 for master branch and commit 777273e for 3.X branch. Exception thrown in ode for a pair of close events -- Key: MATH-1226 URL: https://issues.apache.org/jira/browse/MATH-1226 Project: Commons Math Issue Type: Bug Affects Versions: 3.5 Reporter: Luc Maisonobe Priority: Minor Fix For: 4.0, 3.6 When two discrete events occur closer to each other than the convergence threshold used for locating them, this sometimes triggers a NumberIsTooLargeException. The exception happens because the EventState class think the second event is simply a numerical artifact (a repetition of the already triggerred first event) and tries to skip past it. If there are no other event in the same step later on, one interval boundary finally reach step end and the interval bounds are reversed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1116) NullPointerException not advertized in Javadoc
[ https://issues.apache.org/jira/browse/MATH-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1116. - Resolution: Fixed Fix Version/s: 3.6 4.0 Fixed in git repository for the remaining part (ODE package). NullPointerException not advertized in Javadoc -- Key: MATH-1116 URL: https://issues.apache.org/jira/browse/MATH-1116 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Environment: Mac OS 10.9, Java 6, 7 Reporter: Cyrille Artho Priority: Minor Labels: javadoc Fix For: 4.0, 3.6 Attachments: IllegalStateB.java, Report2.java, Report6.java, Report7.java The following statement produces a NullPointerException: new org.apache.commons.math3.optim.nonlinear.vector.jacobian.LevenbergMarquardtOptimizer().getWeight(); The documentation does not seem to indicate that other data must be set before getWeight is used (at least I could not find that information). In this case, weightMatrix is still null because it has not been initialized. This call should probably throw an IllegalStateException, which makes it clear that this API usage is incorrect. This test uses LevenbergMarquardtOptimizer but any instantiable subclass of MultivariateVectorOptimizer probably works the same way. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1224) NullPointerExceptions not documented in some classes
[ https://issues.apache.org/jira/browse/MATH-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1224. - Resolution: Fixed Fix Version/s: 3.6 4.0 Fixed in git repository for the remaining part (ODE package). NullPointerExceptions not documented in some classes Key: MATH-1224 URL: https://issues.apache.org/jira/browse/MATH-1224 Project: Commons Math Issue Type: Bug Affects Versions: 3.3, 3.5 Environment: Mac OS X, Java 6-8 Reporter: Cyrille Artho Priority: Minor Labels: documentation, easyfix, easytest, newbie Fix For: 4.0, 3.6 Attachments: Report6.java, Report7.java Original Estimate: 40m Remaining Estimate: 40m In general, the need to initialize newly constructed objects with more data is now documented, but we have found two cases where a NullPointerException is thrown because of missing data. The documentation should be updated to reflect this. This is similar to issues report in MATH-1116 but concerns classes that are not going to be deprecated (as far as we can tell). I have previously posted this as a new comment on issue 1116, but that comment has not elicited any response. As the original issue is one year old, I post this bug as a new issue. Below is the code that produces the two cases: org.apache.commons.math3.ode.nonstiff.HighamHall54Integrator var1 = new org.apache.commons.math3.ode.nonstiff.HighamHall54Integrator(0.0d, 0.0d, 0.0d, 0.0d); double[] var2 = new double[] { 0.0d }; var1.computeDerivatives(0.0d, var2, var2); // NPE new org.apache.commons.math3.stat.correlation.SpearmansCorrelation().getCorrelationMatrix(); // NPE -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1225) ODE tutorial documentation not up to date
[ https://issues.apache.org/jira/browse/MATH-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1225. - Resolution: Fixed Fix Version/s: 3.6 4.0 The userguide has been updated in git repository (both master branch and 3.x branch). The online site has also been updated. Thanks for the report. ODE tutorial documentation not up to date - Key: MATH-1225 URL: https://issues.apache.org/jira/browse/MATH-1225 Project: Commons Math Issue Type: Bug Affects Versions: 3.5 Reporter: Bernard GODARD Priority: Minor Fix For: 4.0, 3.6 The tutorial on ODE is not up to date http://commons.apache.org/proper/commons-math/userguide/ode.html in particular in what concerns the usage of Parametrized ODE and jacobian providers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1222) Use Double.isNaN(double) instead of x != x in FastMath
[ https://issues.apache.org/jira/browse/MATH-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1222. - Resolution: Fixed Fix Version/s: 4.0 Fixed in git repository (commit:903f280). Thanks for the report and for the patch. Use Double.isNaN(double) instead of x != x in FastMath -- Key: MATH-1222 URL: https://issues.apache.org/jira/browse/MATH-1222 Project: Commons Math Issue Type: Task Reporter: Benedikt Ritter Labels: github Fix For: 4.0 As discussed in http://markmail.org/thread/f6juilawhswblnve we should use Double.isNaN(double) for checking whether a double is NaN in FastMath instead of using the odd looking x != x comparison. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1223) Wrong splitting of huge double numbers
[ https://issues.apache.org/jira/browse/MATH-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1223. - Resolution: Fixed Fix Version/s: 3.6 Fixed in git repository, with commit e4b3ac8 in the master branch (4.X) and with commit 9e1b0ac in the MATH_3_X branch. Wrong splitting of huge double numbers -- Key: MATH-1223 URL: https://issues.apache.org/jira/browse/MATH-1223 Project: Commons Math Issue Type: Bug Affects Versions: 3.5 Reporter: Luc Maisonobe Priority: Minor Fix For: 4.0, 3.6 In both MathArrays and FastMath, some computations on double are performed by firt splitting double numbers in two numbers with about 26 bits. This splitting fails when the numbers are huge, even if they are still representable and not infinite (the limit is about 1.0e300, eight orders of magnitude below infinity). This can be seen by computing for example {code} FastMath.pow(FastMath.scalb(1.0, 500), 4); {code} The result is NaN whereas it should be +infinity. or by modifying test MathArraysTest.testLinearCombination1 and scaling down first array elements by FastMath.scalb(a[i], -971) and scaling up the second array elements by FastMath.scalb(b[i], +971), which should not change the results. Here the result is a loss of precision because a safety check in MathArrays.linearCombination falls back to naive implementation if the high accuracy algorithm fails. The reason for the wrong splitting is an overflow when computing {code} final int splitFactor = 0x801; final double cd = splitFactor * d; // --- overflow {code} {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1223) Wrong splitting of huge double numbers
Luc Maisonobe created MATH-1223: --- Summary: Wrong splitting of huge double numbers Key: MATH-1223 URL: https://issues.apache.org/jira/browse/MATH-1223 Project: Commons Math Issue Type: Bug Affects Versions: 3.5 Reporter: Luc Maisonobe Priority: Minor Fix For: 4.0 In both MathArrays and FastMath, some computations on double are performed by firt splitting double numbers in two numbers with about 26 bits. This splitting fails when the numbers are huge, even if they are still representable and not infinite (the limit is about 1.0e300, eight orders of magnitude below infinity). This can be seen by computing for example {code} FastMath.pow(FastMath.scalb(1.0, 500), 4); {code} The result is NaN whereas it should be +infinity. or by modifying test MathArraysTest.testLinearCombination1 and scaling down first array elements by FastMath.scalb(a[i], -971) and scaling up the second array elements by FastMath.scalb(b[i], +971), which should not change the results. Here the result is a loss of precision because a safety check in MathArrays.linearCombination falls back to naive implementation if the high accuracy algorithm fails. The reason for the wrong splitting is an overflow when computing {code} final int splitFactor = 0x801; final double cd = splitFactor * d; // --- overflow {code} {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1118) Complex: semantics of equals != Double equals, mismatch with hashCode
[ https://issues.apache.org/jira/browse/MATH-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1118. - Resolution: Fixed Fix Version/s: (was: 3.3) 3.6 4.0 Fixed in git repository on both the master branch and the 3.X branch. Thanks for the reminding. Complex: semantics of equals != Double equals, mismatch with hashCode - Key: MATH-1118 URL: https://issues.apache.org/jira/browse/MATH-1118 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Environment: Mac OS 10.9, Java 6, 7 Reporter: Cyrille Artho Fix For: 4.0, 3.6 Attachments: MATH-1118.patch, MATH-1118.patch, Report5.java, Report5a.java Two complex numbers with real/imaginary parts 0.0d but different signs compare as equal numbers. This is according to their mathematical value; the comparison is done via return (real == c.real) (imaginary == c.imaginary); Unfortunately, two Double values do NOT compare as equal in that case, so real.equals(c.real) would return false if the signs differ. This becomes a problem because for the hashCode, MathUtils.hash is used on the real and imaginary parts, which in turn uses Double.hash. This violates the contract on equals/hashCode, so Complex numbers cannot be used in a hashtable or similar data structure: Complex c1 = new Complex(0.0, 0.0); Complex c2 = new Complex(0.0, -0.0); // Checks the contract: equals-hashcode on c1 and c2 assertTrue(Contract failed: equals-hashcode on c1 and c2, c1.equals(c2) ? c1.hashCode() == c2.hashCode() : true); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[ https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1143. - Resolution: Fixed Fix Version/s: 4.0 Methods toDifferentiable (two signatures) and derivative (two signatures) have been added to FunctionUtils. Note that the proposal I made in an earlier comment did not work as it does not handle partial derivatives composition correctly. This means it failed when the input parameters were not the canonical free parameters of the derivatives. The committed methods handle composition correctly. Helper methods to FiniteDifferencesDifferentiator - Key: MATH-1143 URL: https://issues.apache.org/jira/browse/MATH-1143 Project: Commons Math Issue Type: Improvement Reporter: Alexander Nozik Priority: Trivial Fix For: 4.0 A DerivativeStructure and UnivariateDifferentiableFunction are great tools if one needs to investigate the whole function but are not convenient if one just needs derivative in a given point. Perhaps you could add some helper methods to FiniteDifferencesDifferentiator or to utility class like FunctionUtils. Also it would be good to have helper methods to get the derivatives of UnivariateDifferentiableFunction or MultivariateDifferentiableFunction as simple Univariate or Multivariate functions (or vector-functions). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[ https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521339#comment-14521339 ] Luc Maisonobe commented on MATH-1143: - If you have function f(x1, x2, x3) and know both the value and the derivatives, you can directly build the DerivativeStructure as follows: {code} int nbParams = 3; // index 0 will be for x1, index 1 for x2, index 2 for x3 int order = 1; // we will use only value and first order derivative return new DerivativeStructure(nbParams, order, f, dfdx1, dfdx2, dfdx3); {code} As this constructor as a variable number of arguments, this example can be generalized to other numbers of parameters. The order in which the derivatives should be provided is difficult to set up in the general case when both nbParams and order are greater than 1, but it is straightforward in the two limit cases (nbParams = 1, order 1) or (nbParams 1, order = 1). In both cases, you just give the derivatives in the natural order, which is in increasing order when you have one parameter and high order derivatives, and in parameters order when you have only first order derivatives for all parameters. Helper methods to FiniteDifferencesDifferentiator - Key: MATH-1143 URL: https://issues.apache.org/jira/browse/MATH-1143 Project: Commons Math Issue Type: Improvement Reporter: Alexander Nozik Priority: Trivial A DerivativeStructure and UnivariateDifferentiableFunction are great tools if one needs to investigate the whole function but are not convenient if one just needs derivative in a given point. Perhaps you could add some helper methods to FiniteDifferencesDifferentiator or to utility class like FunctionUtils. Also it would be good to have helper methods to get the derivatives of UnivariateDifferentiableFunction or MultivariateDifferentiableFunction as simple Univariate or Multivariate functions (or vector-functions). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[ https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521339#comment-14521339 ] Luc Maisonobe edited comment on MATH-1143 at 4/30/15 11:24 AM: --- If you have function f(x1, x2, x3) and know both the value and the derivatives, you can directly build the DerivativeStructure as follows: {code} int nbParams = 3; // index 0 will be for x1, index 1 for x2, index 2 for x3 int order = 1; // we will use only value and first order derivative return new DerivativeStructure(nbParams, order, f, dfdx1, dfdx2, dfdx3); {code} As this constructor has a variable number of arguments, this example can be generalized to other numbers of parameters. The order in which the derivatives should be provided is difficult to set up in the general case when both nbParams and order are greater than 1, but it is straightforward in the two limit cases (nbParams = 1, order 1) or (nbParams 1, order = 1). In both cases, you just give the derivatives in the natural order, which is in increasing order when you have one parameter and high order derivatives, and in parameters order when you have only first order derivatives for all parameters. was (Author: luc): If you have function f(x1, x2, x3) and know both the value and the derivatives, you can directly build the DerivativeStructure as follows: {code} int nbParams = 3; // index 0 will be for x1, index 1 for x2, index 2 for x3 int order = 1; // we will use only value and first order derivative return new DerivativeStructure(nbParams, order, f, dfdx1, dfdx2, dfdx3); {code} As this constructor as a variable number of arguments, this example can be generalized to other numbers of parameters. The order in which the derivatives should be provided is difficult to set up in the general case when both nbParams and order are greater than 1, but it is straightforward in the two limit cases (nbParams = 1, order 1) or (nbParams 1, order = 1). In both cases, you just give the derivatives in the natural order, which is in increasing order when you have one parameter and high order derivatives, and in parameters order when you have only first order derivatives for all parameters. Helper methods to FiniteDifferencesDifferentiator - Key: MATH-1143 URL: https://issues.apache.org/jira/browse/MATH-1143 Project: Commons Math Issue Type: Improvement Reporter: Alexander Nozik Priority: Trivial A DerivativeStructure and UnivariateDifferentiableFunction are great tools if one needs to investigate the whole function but are not convenient if one just needs derivative in a given point. Perhaps you could add some helper methods to FiniteDifferencesDifferentiator or to utility class like FunctionUtils. Also it would be good to have helper methods to get the derivatives of UnivariateDifferentiableFunction or MultivariateDifferentiableFunction as simple Univariate or Multivariate functions (or vector-functions). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[ https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521431#comment-14521431 ] Luc Maisonobe commented on MATH-1143: - {quote} I am not sure I understand, how this constructor works. It seems that it defines derivatives in the fixed point. {quote} Yes. A DerivativeStructure instance is just one set of values, just like a double which would hold a value f(x). If you want to have f(x) for several x values, you create as many double as you want, this is the same for DerivativeStructure, you create one instance for each x value. Your example to create a function is almost good. It just misses one point: you don't use the derivatives of ds itself, only its value. This may be fine if you are sure ds is already your canonical variable, but it would not work if your function is the last step of a composition. The DerivativeStructure class has been created to handle the second case, which explains why it seems overkill in simpler cases. In fact, in your case you seem to already do separately the computation of the derivatives with separate code, using your someDerivativeCalculationHere function. This is the kind of things DerivativesStructure could do for you. In fact, as long as you have a way to implement someOperationHere using only Java (i.e. with primitive operations, Math/FastMath/StrictMath functions and even calls to intermediate functions, then you can reimplement it so it directly computes the derivatives at the same time and most importantly at any order, without requiring you to find the expression for the derivatives. This is the essence of automatic differentiation. There is even the Apache Commons Nable project (unfortunately not fully functional) that could do this for you, i.e. you give it a UnivariateFunction and it creates the corresponding UnivariateDifferentiableFunction automatically. What you seem to ask here is for something different: you already have the function and derivatives available, but probably only at the order at which you did code them. Then if you want to put the result in a DerivativeStructure instance, the class simply acts as a container for the values, and serves no other purpose. Then of course it seems complicated for just doing this. Helper methods to FiniteDifferencesDifferentiator - Key: MATH-1143 URL: https://issues.apache.org/jira/browse/MATH-1143 Project: Commons Math Issue Type: Improvement Reporter: Alexander Nozik Priority: Trivial A DerivativeStructure and UnivariateDifferentiableFunction are great tools if one needs to investigate the whole function but are not convenient if one just needs derivative in a given point. Perhaps you could add some helper methods to FiniteDifferencesDifferentiator or to utility class like FunctionUtils. Also it would be good to have helper methods to get the derivatives of UnivariateDifferentiableFunction or MultivariateDifferentiableFunction as simple Univariate or Multivariate functions (or vector-functions). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1143) Helper methods to FiniteDifferencesDifferentiator
[ https://issues.apache.org/jira/browse/MATH-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521494#comment-14521494 ] Luc Maisonobe commented on MATH-1143: - OK. You may have a look at the JacobianMatrices class in the ode package that allows integrating the variational equations if your derivatives are computed with respect to either the initial state or some model parameters. But even if you use this, you will not directly get a DerivativeStructure and you will have to build it afterwards. So I guess you example is almost the helper function you need. Perhaps we could rework it as follows: {code} UnivariateDifferentiableFunction buildDifferentiable(final UnivariateFunction f, final UnivariateVectorFunction gradient) { return new UnivariateDifferentiableFunction() { public double value(final double x) { return f.value(x); } public DerivativeStructure value(final DerivativeStructure t) { if (t.getOrder() 1) { throw new NumberIsTooLargeException(t.getOrder(), 1, true); } double y = f.value(x); double[] dy = gradient.value(x); double[] packed = new double[dy.length + 1]; packed[0] = y; System.arraycopy(dy, 0, packed, 1, dy.length); return new DerivativeStructure(dy.length, 1, packed); } }; } {code} Helper methods to FiniteDifferencesDifferentiator - Key: MATH-1143 URL: https://issues.apache.org/jira/browse/MATH-1143 Project: Commons Math Issue Type: Improvement Reporter: Alexander Nozik Priority: Trivial A DerivativeStructure and UnivariateDifferentiableFunction are great tools if one needs to investigate the whole function but are not convenient if one just needs derivative in a given point. Perhaps you could add some helper methods to FiniteDifferencesDifferentiator or to utility class like FunctionUtils. Also it would be good to have helper methods to get the derivatives of UnivariateDifferentiableFunction or MultivariateDifferentiableFunction as simple Univariate or Multivariate functions (or vector-functions). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1213) LaguerreSolver complex solve methods do not allow maxEval limit
[ https://issues.apache.org/jira/browse/MATH-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe updated MATH-1213: Fix Version/s: (was: 3.5) 4,0 LaguerreSolver complex solve methods do not allow maxEval limit --- Key: MATH-1213 URL: https://issues.apache.org/jira/browse/MATH-1213 Project: Commons Math Issue Type: Bug Affects Versions: 3.4.1 Reporter: Phil Steitz Fix For: 4.0, 4,0 The methods solveAllComplex and solveComplex in the LaguerreSolver should allow the user to specify a maximum number of function evaluations, similarly to the real solvers. Currently, the calls to setup have Integer.MAX_VALUE hard-coded. Additional versions of these methods that take a maxEval parameter should be added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1195) Move the FastMathTestPerformance source
[ https://issues.apache.org/jira/browse/MATH-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1195. - Resolution: Fixed Fix Version/s: (was: 3.4.2) 4,0 3.5 Fixed in git repository. The dependencies to junit have also been removed from the file, as it isn't really a test. Move the FastMathTestPerformance source - Key: MATH-1195 URL: https://issues.apache.org/jira/browse/MATH-1195 Project: Commons Math Issue Type: Sub-task Reporter: Gilles Assignee: Gilles Priority: Minor Labels: documentation Fix For: 3.5, 4,0 FastMathTestPerformance is stored in the test part of the repository but is not a test, it's a benchmark. Its code should be moved to the src/userguide part of the repository, where it can be updated to generate a report in a format suitable for publishing on the web site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1191) QRDecomposition decompose and performHouseholderReflection methods ignore matrix parameters
[ https://issues.apache.org/jira/browse/MATH-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1191. - Resolution: Fixed Fix Version/s: (was: 3.4.2) 3.5 Fixed in git repository, for both 3.5 and 4.0. Instead of removing the parameters, they are now properly used. It does not really change anything since the parameter passed was already the same matrix. QRDecomposition decompose and performHouseholderReflection methods ignore matrix parameters --- Key: MATH-1191 URL: https://issues.apache.org/jira/browse/MATH-1191 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Reporter: Phil Steitz Fix For: 4.0, 3.5 The protected decompose and performHouseholderReflection methods in QRDecomposition act on the qr matrix set by the constructor, not whatever matrix is supplied as actual parameter. For 3.x, the javadoc should be updated to indicate that the actual parameter is ignored. For 4.0, the parameters should be removed. Alternatively, implementations could be changed to act on the arguments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1211) PolyhedronsSet.firstIntersection(Vector3D point, Line line) sometimes reports intersections on wrong end of line
[ https://issues.apache.org/jira/browse/MATH-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1211. - Resolution: Fixed Fix Version/s: 3.5 Your analysis was perfectly correct and your solution was good. I only made a minor change so it is easier to understand. Fixed in git repository. Beware the fix is currently only in the MATH_3_X branch, which is not the master branch. It will be included in the upcoming 3.5 release. Thanks for the report and the fix. PolyhedronsSet.firstIntersection(Vector3D point, Line line) sometimes reports intersections on wrong end of line Key: MATH-1211 URL: https://issues.apache.org/jira/browse/MATH-1211 Project: Commons Math Issue Type: Bug Reporter: Mike Zimmerman Fix For: 3.5 Attachments: IntersectionTest.java I constructed a PolyhedronsSet from a list of triangular faces representing an icosphere (using the instructions found at https://mail-archives.apache.org/mod_mbox/commons-user/201208.mbox/5039fe35.2090...@free.fr). This seems to produce correct INSIDE/OUTSIDE results for randomly chosen points. I think my mesh triangles are defined appropriately. However, using PolyhedronsSet.firstIntersection(Vector3D point, Line line) to shoot randomly oriented rays from the origin sometimes gives a wrong mesh intersection point behind the origin. The intersection algorithm is sometimes picking up faces of the sphere-shaped mesh on the wrong semi-infinite portion of the line, i.e. meshIntersectionPoint.subtract(point).dotProduct(line.getDirection())0 where point is the Vector3D at center of the sphere and line extends outward through the mesh. I think the dot product above should always be positive. If multiple intersections exist along a whole line then the first one in front of the line's origin should be returned. This makes ray tracing with a PolyhedronsSet possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1211) PolyhedronsSet.firstIntersection(Vector3D point, Line line) sometimes reports intersections on wrong end of line
[ https://issues.apache.org/jira/browse/MATH-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14484866#comment-14484866 ] Luc Maisonobe commented on MATH-1211: - Hi Mike, Could you attach a self-contained test to reproduce the error? PolyhedronsSet.firstIntersection(Vector3D point, Line line) sometimes reports intersections on wrong end of line Key: MATH-1211 URL: https://issues.apache.org/jira/browse/MATH-1211 Project: Commons Math Issue Type: Bug Reporter: Mike Zimmerman I constructed a PolyhedronsSet from a list of triangular faces representing an icosphere (using the instructions found at https://mail-archives.apache.org/mod_mbox/commons-user/201208.mbox/5039fe35.2090...@free.fr). This seems to produce correct INSIDE/OUTSIDE results for randomly chosen points. I think my mesh triangles are defined appropriately. However, using PolyhedronsSet.firstIntersection(Vector3D point, Line line) to shoot randomly oriented rays from the origin sometimes gives a wrong mesh intersection point behind the origin. The intersection algorithm is sometimes picking up faces of the sphere-shaped mesh on the wrong semi-infinite portion of the line, i.e. meshIntersectionPoint.subtract(point).dotProduct(line.getDirection())0 where point is the Vector3D at center of the sphere and line extends outward through the mesh. I think the dot product above should always be positive. If multiple intersections exist along a whole line then the first one in front of the line's origin should be returned. This makes ray tracing with a PolyhedronsSet possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1186) Add README.md and CONTRIBUTING.md
[ https://issues.apache.org/jira/browse/MATH-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1186. - Resolution: Fixed Fix Version/s: 4.0 Pull request has been merged. Add README.md and CONTRIBUTING.md - Key: MATH-1186 URL: https://issues.apache.org/jira/browse/MATH-1186 Project: Commons Math Issue Type: Improvement Reporter: Benedikt Ritter Labels: github Fix For: 4.0 Placeholderticket for https://github.com/apache/commons-math/pull/4 {quote} This will give users and contributors coming from github give some information on where to start. The files were generated by the latest snapshot of the commons-build-plugin using: * {{mvn org.apache.commons:commons-build-plugin:1.5-SNAPSHOT:readme-md}} * {{mvn org.apache.commons:commons-build-plugin:1.5-SNAPSHOT:contributing-md}} {quote} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1188) BesselJ java contains non-Java5 code.
[ https://issues.apache.org/jira/browse/MATH-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1188. - Resolution: Fixed Issue has been identified and fixed by Sebb. The fix is on commit 6a82f92. BesselJ java contains non-Java5 code. - Key: MATH-1188 URL: https://issues.apache.org/jira/browse/MATH-1188 Project: Commons Math Issue Type: Bug Affects Versions: 3.4 Reporter: Luc Maisonobe Fix For: 3.4.1 The class uses Arrays.copyOf, which is only available in Java 1.6+. Apache Commons Math currently targets 1.5, so this method should not be used. MathArrays.copyOf should be used instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Updated] (MATH-1187) Pom to run examples from Maven repo
Hi Sebb, Le 08/01/2015 17:17, Sebb (JIRA) a écrit : [ https://issues.apache.org/jira/browse/MATH-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated MATH-1187: --- Attachment: pom.xml Do you want me to include this in 3.4.1 too? best regards, Luc Pom to run examples from Maven repo --- Key: MATH-1187 URL: https://issues.apache.org/jira/browse/MATH-1187 Project: Commons Math Issue Type: New Feature Reporter: Sebb Priority: Minor Attachments: pom.xml The Pom (to follow) allows one to run the examples assuming an examples jar has been installed / uploaded to Maven. There would be no need to create an Uber jar (with all the potential licensing/jar hell issues) as the pom would download any necessary dependencies to the local repo. As an enhancement, if it proved necessary to optionally depend on a non-permitted jar, it would be possible to add a profile to add that as a proper dependency (the main dependency would have to use provided). I think this would satisfy the ASF requirement that users should not be landed with non-AL code unless they specifically agree to it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1188) BesselJ java contains non-Java5 code.
Luc Maisonobe created MATH-1188: --- Summary: BesselJ java contains non-Java5 code. Key: MATH-1188 URL: https://issues.apache.org/jira/browse/MATH-1188 Project: Commons Math Issue Type: Bug Affects Versions: 3.4 Reporter: Luc Maisonobe Fix For: 3.4.1 The class uses Arrays.copyOf, which is only available in Java 1.6+. Apache Commons Math currently targets 1.5, so this method should not be used. MathArrays.copyOf should be used instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1185) Tail probability drops to zero beyond 10e-17 ?
[ https://issues.apache.org/jira/browse/MATH-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264477#comment-14264477 ] Luc Maisonobe commented on MATH-1185: - Yes, there is a reason: it is due to the subtraction, not the the distribution. When you compute 1.0 - x, you are limited with IEEE754 double precision. If x is close to 1.0, the subtraction leads to loss of significance (also called catastrophic cancellation). What you see here is that the last number just below 1.0 is 1.0 - 2^-53. In other words, there are no representable number between 1.0-2^-53 and 1.0. Then, when subtraction is computed, you jump from 2^-53 to 0. Tail probability drops to zero beyond 10e-17 ? -- Key: MATH-1185 URL: https://issues.apache.org/jira/browse/MATH-1185 Project: Commons Math Issue Type: Wish Affects Versions: 3.3, 3.4 Reporter: Sriram Natarajan Priority: Minor This could be a simple question, In which case I can expect a clarification. If this is the wrong place to post such a question, let me know. OS: Windows 8.1, Java 1.8.0_25 ChiSquaredDistribution chisq = new ChiSquaredDistribution(23) 1.0 - chisq.cumulativeProbability(130) is 1.1102230246251565E-16 1.0 - chisq.cumulativeProbability(131) is 0.0 Am pretty sure it is not a formatting issue. Is there a reason why the tail drops to zero at this point? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1185) Tail probability drops to zero beyond 10e-17 ?
[ https://issues.apache.org/jira/browse/MATH-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264920#comment-14264920 ] Luc Maisonobe commented on MATH-1185: - The problem is not the global magnitude. Values of the order of magnitude of 10^-308 can be represented, and values of the order of 10^+308 can also be represented. The problem is how you compute the value. All normal numbers have about 15 significant digits. This means that when you are speaking of 10^-295, the most significat digit is 10^-295 and the least significant digit if 15 orders of magnitude lowers, hence 10^-308. Here, you start from something of the order of magnitude of 1.0, so the most significant digit is 10^0 and the least significant digit is 10^-15. When you do the subtraction, you cannot recover digits smaller that 10^-15 because they were not in the number you started from. I do not think R uses higher precision. I think they do not use 1 - x here, but compute the value using another direct algorithm/ This is exactly the same problem as computing exp(t) -1 for small t. If you do it the obvious way, by first computing the exponential function and then subtracting 1, you have very bad results. This is the reason why all mathemetical libraries provide a function expm1(t) which does not use the obvious way and therefore avoids the subtraction, allowing extremely high accuracy here. I don't know if for the expression you need such a dedicated algorithm exists, but for sure if you need this level of accuracy, don't use a subtraction with 1. Tail probability drops to zero beyond 10e-17 ? -- Key: MATH-1185 URL: https://issues.apache.org/jira/browse/MATH-1185 Project: Commons Math Issue Type: Wish Affects Versions: 3.3, 3.4 Reporter: Sriram Natarajan Priority: Minor This could be a simple question, In which case I can expect a clarification. If this is the wrong place to post such a question, let me know. OS: Windows 8.1, Java 1.8.0_25 ChiSquaredDistribution chisq = new ChiSquaredDistribution(23) 1.0 - chisq.cumulativeProbability(130) is 1.1102230246251565E-16 1.0 - chisq.cumulativeProbability(131) is 0.0 Am pretty sure it is not a formatting issue. Is there a reason why the tail drops to zero at this point? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1153) Sampling from a 'BetaDistribution' is slow
[ https://issues.apache.org/jira/browse/MATH-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe updated MATH-1153: Fix Version/s: (was: 3.4) 4.0 Sampling from a 'BetaDistribution' is slow -- Key: MATH-1153 URL: https://issues.apache.org/jira/browse/MATH-1153 Project: Commons Math Issue Type: Improvement Reporter: Sergei Lebedev Priority: Minor Fix For: 4.0 Attachments: ChengBetaSampler.java, ChengBetaSamplerTest.java Currently the `BetaDistribution#sample` uses inverse CDF method, which is quite slow for sampling-intensive computations. I've implemented a method from the R. C. H. Cheng paper and it seems to work much better. Here's a simple microbenchmark: {code} o.j.b.s.SamplingBenchmark.algorithmBCorBB 1e-31000 thrpt5 2592200.01514391.520 ops/s o.j.b.s.SamplingBenchmark.algorithmBCorBB 10001000 thrpt5 3210800.2920.791 ops/s o.j.b.s.SamplingBenchmark.commonsVersion1e-31000 thrpt5 31034.225 438.273 ops/s o.j.b.s.SamplingBenchmark.commonsVersion10001000 thrpt5 21834.010 433.324 ops/s {code} Should I submit a patch? R. C. H. Cheng (1978). Generating beta variates with nonintegral shape parameters. Communications of the ACM, 21, 317–322. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1158) Factory method to provide sampling from distributions
[ https://issues.apache.org/jira/browse/MATH-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe updated MATH-1158: Fix Version/s: (was: 3.4) 4.0 Factory method to provide sampling from distributions - Key: MATH-1158 URL: https://issues.apache.org/jira/browse/MATH-1158 Project: Commons Math Issue Type: New Feature Affects Versions: 3.3 Reporter: Gilles Priority: Minor Labels: API, deprecation Fix For: 4.0 Attachments: MATH-1158.patch A proposal to separate the sampling functionality from the core of the distribution classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1153) Sampling from a 'BetaDistribution' is slow
[ https://issues.apache.org/jira/browse/MATH-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14249664#comment-14249664 ] Luc Maisonobe commented on MATH-1153: - In fact, I started incorporating the patch as an internal static class with static methods, and passed the generator, alpha and beta to these methods ;-) I thought it would appear overengineered, but it seems to be a good approach after all. So I'll put it back this way so it is closer to the original patch. Sampling from a 'BetaDistribution' is slow -- Key: MATH-1153 URL: https://issues.apache.org/jira/browse/MATH-1153 Project: Commons Math Issue Type: Improvement Reporter: Sergei Lebedev Priority: Minor Fix For: 3.4 Attachments: ChengBetaSampler.java, ChengBetaSamplerTest.java Currently the `BetaDistribution#sample` uses inverse CDF method, which is quite slow for sampling-intensive computations. I've implemented a method from the R. C. H. Cheng paper and it seems to work much better. Here's a simple microbenchmark: {code} o.j.b.s.SamplingBenchmark.algorithmBCorBB 1e-31000 thrpt5 2592200.01514391.520 ops/s o.j.b.s.SamplingBenchmark.algorithmBCorBB 10001000 thrpt5 3210800.2920.791 ops/s o.j.b.s.SamplingBenchmark.commonsVersion1e-31000 thrpt5 31034.225 438.273 ops/s o.j.b.s.SamplingBenchmark.commonsVersion10001000 thrpt5 21834.010 433.324 ops/s {code} Should I submit a patch? R. C. H. Cheng (1978). Generating beta variates with nonintegral shape parameters. Communications of the ACM, 21, 317–322. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1176) QRDecomposition does not detect the matrix singularity
[ https://issues.apache.org/jira/browse/MATH-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe updated MATH-1176: Fix Version/s: 4.0 QRDecomposition does not detect the matrix singularity -- Key: MATH-1176 URL: https://issues.apache.org/jira/browse/MATH-1176 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Reporter: alberto trivellato Priority: Minor Fix For: 4.0 Attachments: MATH-1176.failing.patch QRDecomposition fails this test. The default contructor sets the threshold=0, so we will never have abs(Rii) = 0 public void testSimpleRankDeficient() throws Exception { double[][] A = new double[][] { { 1, 2, 3 }, { 4, 5, 6 }, { 7, 8, 9 }}; //this matrix is singular RealMatrix M2 = MatrixUtils.createRealMatrix(A); QRDecomposition qr2 = new QRDecomposition(M2); assertFalse(qr2.getSolver().isNonSingular());//this fails } -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1132) NaN transformation based on NaNStrategy
[ https://issues.apache.org/jira/browse/MATH-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1132. - Resolution: Won't Fix The subject has been discussed at length in the past few months, and after several trials, the current status of the code in the repository seems to be good enough. We will settle this for now, and open a new issue if some users complain after 3.4 release. NaN transformation based on NaNStrategy --- Key: MATH-1132 URL: https://issues.apache.org/jira/browse/MATH-1132 Project: Commons Math Issue Type: Improvement Affects Versions: 3.3 Reporter: Venkatesha Murthy TS Fix For: 3.4 Attachments: math-1132.patch The NaNs in a double array may need to be transformed to either +/- Infinity or removed before processing them(say such as in percentile). So basically from documenting angle; we will need to action as follows: Whenever a double quantity is a NaN (say in an array); based on the NanStrategy; it needs to be treated as follows before processing: a) MAXIMAL - replace with +infinity b) MINIMAL - replace with -Inifinity c) REMOVED - just remove it d) FIXED - Leave it as it is e) FAILED - throw a NaN exception Can this documentation be specifically added to NaNStrategy and perhaps a substitution value also can be added to enforce the documentation. In addition i will also submit a patch for a simple NaNTransformer implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1105) Least squares statistical data editing
[ https://issues.apache.org/jira/browse/MATH-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe updated MATH-1105: Fix Version/s: (was: 3.4) 4.0 Least squares statistical data editing -- Key: MATH-1105 URL: https://issues.apache.org/jira/browse/MATH-1105 Project: Commons Math Issue Type: Improvement Reporter: Evan Ward Fix For: 4.0 Attachments: 0001-Add-statistical-editing-capability.patch, 0002-Integrate-data-editing-with-the-LS-framework.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1172) Boiler-plate code for simple parametric curve fitting
[ https://issues.apache.org/jira/browse/MATH-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14248726#comment-14248726 ] Luc Maisonobe commented on MATH-1172: - If this issue should remain open until 4.0, can we remove the 3.4 target so it does not appear in the list for 3.4 anymore? Boiler-plate code for simple parametric curve fitting - Key: MATH-1172 URL: https://issues.apache.org/jira/browse/MATH-1172 Project: Commons Math Issue Type: Wish Reporter: Gilles Priority: Minor Fix For: 4.0, 3.4 Attachments: BasicCurveFitter.java Referring to this [question|http://markmail.org/message/n4smw4yin5mdsi7r] on the user ML, I propose to provide a BasicCurveFitter whose use should be straightforward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1153) Sampling from a 'BetaDistribution' is slow
[ https://issues.apache.org/jira/browse/MATH-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14248928#comment-14248928 ] Luc Maisonobe commented on MATH-1153: - I have reworked the patch in order to integrate it directly into the BetaDistribution class. This involved a few variable renames, and I am clearly not sure I did it properly. It seems the goodness of fit test failed in many cases. I finally selected some seeds for which it succeeded, just to make some progress here. This is clearly not satisfaying. However, the patch has a side effect of making most random generator tests fail, as they share a common test based on beta distribution sampling. They all inherit this test from RandomDataGeneratorTest, the test is testNextInversionDeviate. So my current state of mind is that I broke something while updating the patch, but I do not have the necessary skills to analyze it and even less to fix it. Could someone look at my attempts. They are available on a MATH-1153 branch in the git repository. In the meantime, I propose to postpone this issue after 3.4. Sampling from a 'BetaDistribution' is slow -- Key: MATH-1153 URL: https://issues.apache.org/jira/browse/MATH-1153 Project: Commons Math Issue Type: Improvement Reporter: Sergei Lebedev Priority: Minor Fix For: 3.4 Attachments: ChengBetaSampler.java, ChengBetaSamplerTest.java Currently the `BetaDistribution#sample` uses inverse CDF method, which is quite slow for sampling-intensive computations. I've implemented a method from the R. C. H. Cheng paper and it seems to work much better. Here's a simple microbenchmark: {code} o.j.b.s.SamplingBenchmark.algorithmBCorBB 1e-31000 thrpt5 2592200.01514391.520 ops/s o.j.b.s.SamplingBenchmark.algorithmBCorBB 10001000 thrpt5 3210800.2920.791 ops/s o.j.b.s.SamplingBenchmark.commonsVersion1e-31000 thrpt5 31034.225 438.273 ops/s o.j.b.s.SamplingBenchmark.commonsVersion10001000 thrpt5 21834.010 433.324 ops/s {code} Should I submit a patch? R. C. H. Cheng (1978). Generating beta variates with nonintegral shape parameters. Communications of the ACM, 21, 317–322. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1174) Some thin rectangles are not handled properly as PolygonsSet
Luc Maisonobe created MATH-1174: --- Summary: Some thin rectangles are not handled properly as PolygonsSet Key: MATH-1174 URL: https://issues.apache.org/jira/browse/MATH-1174 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Reporter: Luc Maisonobe Fix For: 3.4 If the width of a rectangle is smaller than the close point tolerances, some weird effects appear when vertices are extracted. Typically the size will be set to infinity and barycenter will be forced at origin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1174) Some thin rectangles are not handled properly as PolygonsSet
[ https://issues.apache.org/jira/browse/MATH-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1174. - Resolution: Fixed Fixed in git repository (see commit e6aae3a). Some thin rectangles are not handled properly as PolygonsSet Key: MATH-1174 URL: https://issues.apache.org/jira/browse/MATH-1174 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Reporter: Luc Maisonobe Fix For: 3.4 If the width of a rectangle is smaller than the close point tolerances, some weird effects appear when vertices are extracted. Typically the size will be set to infinity and barycenter will be forced at origin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1168) PolygonSet instantiation throws NullPointerException
[ https://issues.apache.org/jira/browse/MATH-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1168. - Resolution: Cannot Reproduce PolygonSet instantiation throws NullPointerException Key: MATH-1168 URL: https://issues.apache.org/jira/browse/MATH-1168 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: windows 8 Reporter: gün alppay the following generates an exception {noformat} import org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet; import org.apache.commons.math3.geometry.euclidean.twod.Vector2D; class Test { public static void main(String[] args) { new PolygonsSet(1.0E-10, new Vector2D(-76.8095991248, -15.087601999), new Vector2D(-76.8095991245, -18.288001999), new Vector2D(-10.0583778834, -18.2880019979), new Vector2D(-10.0583778835, -15.0876019979), new Vector2D(-54.8639991264, -15.0876019984)); } } {noformat} the exception is {noformat} Exception in thread main java.lang.NullPointerException at org.apache.commons.math3.geometry.partitioning.BSPTree.fitToCell(BSPTree.java:301) at org.apache.commons.math3.geometry.partitioning.BSPTree.insertCut(BSPTree.java:159) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:333) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:406) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:406) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:406) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:406) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.verticesToTree(PolygonsSet.java:309) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.init(PolygonsSet.java:156) at Test.main(test.java:6) {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1162) contains(RegionS region) method of AbstractRegion throws NullPointerException exception
[ https://issues.apache.org/jira/browse/MATH-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1162. - Resolution: Fixed Fix Version/s: 3.4 The issue has been fixed in the git repository (see commit 046e3a2). Thanks for the report. contains(RegionS region) method of AbstractRegion throws NullPointerException exception -- Key: MATH-1162 URL: https://issues.apache.org/jira/browse/MATH-1162 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: tested on windows 8 and heroku Reporter: gün alppay Fix For: 3.4 the contains call on org.apache.commons.math3.geometry.partitioning.AbstractRegion throws an exception in the sample below: {noformat} import org.apache.commons.math3.geometry.partitioning.Region; import org.apache.commons.math3.geometry.euclidean.twod.Vector2D; import org.apache.commons.math3.geometry.euclidean.twod.Euclidean2D; import org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet; class Test { public static void main(String[] args) { RegionEuclidean2D p = new PolygonsSet( 1.0e-10, new Vector2D(4.26719996532, -11.928637756014894), new Vector2D(4.26720026445, -14.12360595809307), new Vector2D(9.14400273694, -14.12360595809307), new Vector2D(9.14400233383, -11.928637756020067)); RegionEuclidean2D w = new PolygonsSet( 1.0e-10, new Vector2D(2.56735636510452512E-9, -11.933116461089332), new Vector2D(2.56735636510452512E-9, -12.393225665247766), new Vector2D(2.56735636510452512E-9, -27.785625665247778), new Vector2D(4.26720030211, -27.785625665247778), new Vector2D(4.26720030211, -11.933116461089332)); p.contains(w); } } {noformat} the exception thrown is: {noformat} Exception in thread main java.lang.NullPointerException at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:263) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:251) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.contains(AbstractRegion.java:295) at Test.main(test.java:19) {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1168) PolygonSet instantiation throws NullPointerException
[ https://issues.apache.org/jira/browse/MATH-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14222496#comment-14222496 ] Luc Maisonobe commented on MATH-1168: - I was not able to reproduce the issue, neither with the current version after fix for MATH-1162, nor when reverting to a version prior to the fix for MATH-1162. Could you check if it still occurs on your computer? PolygonSet instantiation throws NullPointerException Key: MATH-1168 URL: https://issues.apache.org/jira/browse/MATH-1168 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: windows 8 Reporter: gün alppay the following generates an exception {noformat} import org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet; import org.apache.commons.math3.geometry.euclidean.twod.Vector2D; class Test { public static void main(String[] args) { new PolygonsSet(1.0E-10, new Vector2D(-76.8095991248, -15.087601999), new Vector2D(-76.8095991245, -18.288001999), new Vector2D(-10.0583778834, -18.2880019979), new Vector2D(-10.0583778835, -15.0876019979), new Vector2D(-54.8639991264, -15.0876019984)); } } {noformat} the exception is {noformat} Exception in thread main java.lang.NullPointerException at org.apache.commons.math3.geometry.partitioning.BSPTree.fitToCell(BSPTree.java:301) at org.apache.commons.math3.geometry.partitioning.BSPTree.insertCut(BSPTree.java:159) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:333) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:406) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:406) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:406) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.insertEdges(PolygonsSet.java:406) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.verticesToTree(PolygonsSet.java:309) at org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.init(PolygonsSet.java:156) at Test.main(test.java:6) {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1166) BicubicInterpolation may have a bug
[ https://issues.apache.org/jira/browse/MATH-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14222502#comment-14222502 ] Luc Maisonobe commented on MATH-1166: - If I understand correctly, the former BicubiSplineInterpolatingFunction which was deprecated by Hank would still be deprecated and we would have two different implementation, this new one and the piecewise one? I'm fine with this. BicubicInterpolation may have a bug --- Key: MATH-1166 URL: https://issues.apache.org/jira/browse/MATH-1166 Project: Commons Math Issue Type: Bug Reporter: Ajo Fod Attachments: Draw.java, MATH-1166.patch, myimage.jpg I plotted a random image with bicubic interpolation hoping to see something like this: http://en.wikipedia.org/wiki/Bicubic_interpolation ... but instead I got something weird. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1162) contains(RegionS region) method of AbstractRegion throws NullPointerException exception
[ https://issues.apache.org/jira/browse/MATH-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208655#comment-14208655 ] Luc Maisonobe commented on MATH-1162: - I've made some progress in the analysis. The error is not in the chopOffPlus/chopOffMinus methods but it occurs earlier in the BSP tree merging phase. Debugging this is unfortunately quite hard. I hope I'll understand what happens in the nexxt few days. I don't think the second problem is similar to the first one you reported. Could you open a separate JIRA issue for it? contains(RegionS region) method of AbstractRegion throws NullPointerException exception -- Key: MATH-1162 URL: https://issues.apache.org/jira/browse/MATH-1162 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: tested on windows 8 and heroku Reporter: gün alppay the contains call on org.apache.commons.math3.geometry.partitioning.AbstractRegion throws an exception in the sample below: {noformat} import org.apache.commons.math3.geometry.partitioning.Region; import org.apache.commons.math3.geometry.euclidean.twod.Vector2D; import org.apache.commons.math3.geometry.euclidean.twod.Euclidean2D; import org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet; class Test { public static void main(String[] args) { RegionEuclidean2D p = new PolygonsSet( 1.0e-10, new Vector2D(4.26719996532, -11.928637756014894), new Vector2D(4.26720026445, -14.12360595809307), new Vector2D(9.14400273694, -14.12360595809307), new Vector2D(9.14400233383, -11.928637756020067)); RegionEuclidean2D w = new PolygonsSet( 1.0e-10, new Vector2D(2.56735636510452512E-9, -11.933116461089332), new Vector2D(2.56735636510452512E-9, -12.393225665247766), new Vector2D(2.56735636510452512E-9, -27.785625665247778), new Vector2D(4.26720030211, -27.785625665247778), new Vector2D(4.26720030211, -11.933116461089332)); p.contains(w); } } {noformat} the exception thrown is: {noformat} Exception in thread main java.lang.NullPointerException at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:263) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:251) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.contains(AbstractRegion.java:295) at Test.main(test.java:19) {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1162) contains(RegionS region) method of AbstractRegion throws NullPointerException exception
[ https://issues.apache.org/jira/browse/MATH-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198957#comment-14198957 ] Luc Maisonobe commented on MATH-1162: - I confirm the bug. A first analysis shows that the problems is due to BSPTree.chopOffPlus(hyperplane), which may replace the cut hyperplane with null despite preserving two sub-trees. We end up with a node that should be a leaf node but has children. I guess the same problem could occur in the similar chopOffMinus(hyperplane) method too. I'm looking at it. Reducing hyperplane thickness allow the test to pass, but I would not really recommend it, as too small thickness may create numerical problems elsewhere. contains(RegionS region) method of AbstractRegion throws NullPointerException exception -- Key: MATH-1162 URL: https://issues.apache.org/jira/browse/MATH-1162 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: tested on windows 8 and heroku Reporter: gün alppay the contains call on org.apache.commons.math3.geometry.partitioning.AbstractRegion throws an exception in the sample below: {noformat} import org.apache.commons.math3.geometry.partitioning.Region; import org.apache.commons.math3.geometry.euclidean.twod.Vector2D; import org.apache.commons.math3.geometry.euclidean.twod.Euclidean2D; import org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet; class Test { public static void main(String[] args) { RegionEuclidean2D p = new PolygonsSet( 1.0e-10, new Vector2D(4.26719996532, -11.928637756014894), new Vector2D(4.26720026445, -14.12360595809307), new Vector2D(9.14400273694, -14.12360595809307), new Vector2D(9.14400233383, -11.928637756020067)); RegionEuclidean2D w = new PolygonsSet( 1.0e-10, new Vector2D(2.56735636510452512E-9, -11.933116461089332), new Vector2D(2.56735636510452512E-9, -12.393225665247766), new Vector2D(2.56735636510452512E-9, -27.785625665247778), new Vector2D(4.26720030211, -27.785625665247778), new Vector2D(4.26720030211, -11.933116461089332)); p.contains(w); } } {noformat} the exception thrown is: {noformat} Exception in thread main java.lang.NullPointerException at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:263) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:267) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.isEmpty(AbstractRegion.java:251) at org.apache.commons.math3.geometry.partitioning.AbstractRegion.contains(AbstractRegion.java:295) at Test.main(test.java:19) {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1160) ContinuousOutputModel for ordinary differential equations should provide derivatives
Luc Maisonobe created MATH-1160: --- Summary: ContinuousOutputModel for ordinary differential equations should provide derivatives Key: MATH-1160 URL: https://issues.apache.org/jira/browse/MATH-1160 Project: Commons Math Issue Type: Improvement Affects Versions: 3.3 Reporter: Luc Maisonobe Assignee: Luc Maisonobe Priority: Trivial Fix For: 3.4 The ContinuousOutputModel class allows to store the evolution of the state of an ODE system throughout integration. It aims to provides at a global level all the information that is available at local level in step handlers. It does so by storing the step interpolators as integration is performed, and delegate data retrieval to the interpolator matching the time step. However, there is a missing part: step interpolators do provide access to the derivatives of the state, whereas ContinuousOutputModel does not. A getInterpolatedDerivatives method should be added, matching the method with the same name in StepInterpolator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1160) ContinuousOutputModel for ordinary differential equations should provide derivatives
[ https://issues.apache.org/jira/browse/MATH-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1160. - Resolution: Fixed Solved in git repository as of commit 25aa4bd3. ContinuousOutputModel for ordinary differential equations should provide derivatives Key: MATH-1160 URL: https://issues.apache.org/jira/browse/MATH-1160 Project: Commons Math Issue Type: Improvement Affects Versions: 3.3 Reporter: Luc Maisonobe Assignee: Luc Maisonobe Priority: Trivial Fix For: 3.4 The ContinuousOutputModel class allows to store the evolution of the state of an ODE system throughout integration. It aims to provides at a global level all the information that is available at local level in step handlers. It does so by storing the step interpolators as integration is performed, and delegate data retrieval to the interpolator matching the time step. However, there is a missing part: step interpolators do provide access to the derivatives of the state, whereas ContinuousOutputModel does not. A getInterpolatedDerivatives method should be added, matching the method with the same name in StepInterpolator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1138) BicubicSplineInterpolator is returning incorrect interpolated values
[ https://issues.apache.org/jira/browse/MATH-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1138. - Resolution: Fixed Fix Version/s: 3.4 Patch applied as of b5e155e. Thanks for the patch! BicubicSplineInterpolator is returning incorrect interpolated values Key: MATH-1138 URL: https://issues.apache.org/jira/browse/MATH-1138 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Reporter: Adam Bedrossian Fix For: 3.4 Attachments: Interpolated Values from CM and MatLab.docx I have encountered a use case with the BicubicSplineInterpolator where the interpolated values that are being returned seem incorrect. Furthermore, the values do not match those generated by MatLab using the interp2 'cubic' method. Here is a snippet of code that uses the interpolator: double[] xValues = new double[] {36, 36.001, 36.002}; double[] yValues = new double[] {-108.00, -107.999, -107.998}; double[][] fValues = new double[][] {{1915, 1906, 1931}, {1877, 1889, 1894}, {1878, 1873, 1888}}; BicubicSplineInterpolator interpolator = new BicubicSplineInterpolator(); BicubicSplineInterpolatingFunction interpolatorFunction = interpolator.interpolate(xValues, yValues, fValues); double[][] results = new double[9][9]; double x = 36; int arrayIndexX = 0, arrayIndexY = 0; while(x = 36.002) { double y = -108; arrayIndexY = 0; while (y = -107.998) { results[arrayIndexX][arrayIndexY] = interpolatorFunction.value(x, y); System.out.println(results[arrayIndexX][arrayIndexY]); y = y + 0.00025; arrayIndexY++; } x = x + 0.00025; arrayIndexX++; } Attached is a grid showing x and y values and the corresponding interpolated value from both commons math and MatLab. The values produced by commons math are far off from those created by MatLab. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1120) Need Percentile computations that can be matched with standard spreadsheet formula
[ https://issues.apache.org/jira/browse/MATH-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1120. - Resolution: Fixed This issue seems to be solved now. It will be closed when 3.4 is officially released, hopefully in a few weeks. Need Percentile computations that can be matched with standard spreadsheet formula -- Key: MATH-1120 URL: https://issues.apache.org/jira/browse/MATH-1120 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Venkatesha Murthy TS Labels: Percentile Fix For: 3.4 Attachments: 18-jun-percentile-with-estimation-patch, 27-jun-refactored-kth-pivoting.patch, excel-percentile-patch, math-1120-removeAndSlice.patch, percentile-with-estimation-patch, r-output.txt Original Estimate: 504h Remaining Estimate: 504h The current Percentile implementation assumes and hard-codes the quantile pth position as p * (N+1)/100 and provides a kth selected value. However if we need to verify compare/contrast with standard statistical tools such as say MS Excel; it would be good to provide an extensible way of morphing this selection of position than hard code. For example in order to generate the percentile closely matching with MS Excel the position required may be [p*(N-1)/100]+1. Please let me know if i could submit this as a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MATH-1156) mvn tests fail if JDK 8 is used
Luc Maisonobe created MATH-1156: --- Summary: mvn tests fail if JDK 8 is used Key: MATH-1156 URL: https://issues.apache.org/jira/browse/MATH-1156 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: Linux Debian Jessie, openJDK 8 Reporter: Luc Maisonobe Assignee: Luc Maisonobe Priority: Minor Fix For: 3.4 Despite the fact the pom.xml specifies Java version to be 1.5, some tests for FastMath use reflection to verify that FastMath implements all methods found in StrictMath. As the class available in a Java 8 environment has newer methods, and these methods are not available in FastMath, the test fail and maven refuses to build the artifacts. The missing methods should be added, just as the new methods were added when Java 6 was relesed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1156) mvn tests fail if JDK 8 is used
[ https://issues.apache.org/jira/browse/MATH-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1156. - Resolution: Fixed Solved in Git repository (commit a67f0a3) mvn tests fail if JDK 8 is used --- Key: MATH-1156 URL: https://issues.apache.org/jira/browse/MATH-1156 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: Linux Debian Jessie, openJDK 8 Reporter: Luc Maisonobe Assignee: Luc Maisonobe Priority: Minor Fix For: 3.4 Despite the fact the pom.xml specifies Java version to be 1.5, some tests for FastMath use reflection to verify that FastMath implements all methods found in StrictMath. As the class available in a Java 8 environment has newer methods, and these methods are not available in FastMath, the test fail and maven refuses to build the artifacts. The missing methods should be added, just as the new methods were added when Java 6 was relesed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1157) problem with the rotation
[ https://issues.apache.org/jira/browse/MATH-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14161848#comment-14161848 ] Luc Maisonobe commented on MATH-1157: - I don't think it is a real problem. What happens here is simply floating point accuracy which is not absolute. Under the hood, the Rotation class does not use matrices but a more efficient way based on quaternions. This implies that the rotation you define has the following components: q0 = 0.984807753012208, q1 = 0, q2 = 0, q3 = -0.17364817766693033. The expression computing .applyInverseTo is a combination of q0, q1, q2, q3 and your vector x, y, z. The z component is: (-2 q0 q2) x + (2 q0 q1) y + (2 q0 q0 - 1) z + 2 q3 s where s = q1 x + q2 y + q3 z In your case, q1 and q2 are 0, and floating points multiplications and additions involving 0 are exact, so in your specific case, (and only in this specific case) the z component is (2 (q0^2 + q3^2) - 1) z. As a rotation quaternion is normalized, this should be equal to z since q1 and q2 are 0. however, the floating point numbers q0 and q3 are not perfect, and the multiplicative factor for z is not exactly 1 but is rather 1-epsilon where epsilon is the gap between 1 and the primitive double number just below 1. This means that the values q0 and q3 were already computed to the full accuracy of the computer. I have checked them using our Dfp high accuracy numbers class, and in fact the error in q0 is about 3.905e-7 and the error in q3 is about -1.767e-17, so it is not possible to have better values for q0 and q3, we are already at the limit of the primitive double. Do you agree with this explanation? Can we solve the issue as Not A Problem? problem with the rotation - Key: MATH-1157 URL: https://issues.apache.org/jira/browse/MATH-1157 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: Windows 7, Eclipse, Java SE 1.7 Reporter: Frank A Priority: Critical Labels: newbie Fix For: 3.4 Hello, this is my problem: myAngle = 0.3490658503988659 The angle is created with FastMath.toRadians(20). myRotation = new Rotation(RotationOrder.XYZ, 0, 0, myAngle); if I use this on my Vector3D myVector = new Vector3D(4,4,4) with myRotation.applyInverseTo(myVector) I'm get the result x = 5.1268510564463075 y = 2.390689909840958 z = 3.999 (using the .getX() getY() and getZ() functions) Im working with double values, but after the rotation just around the axis z, the z value of my vector shouldn't have changed, but it does. Maybe it is not a bug but a wrong result after a simple rotation, or did I use the rotation in a wrong way? Best regards Frank -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MATH-1157) problem with the rotation
[ https://issues.apache.org/jira/browse/MATH-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14161848#comment-14161848 ] Luc Maisonobe edited comment on MATH-1157 at 10/7/14 12:50 PM: --- I don't think it is a real problem. What happens here is simply floating point accuracy which is not absolute. Under the hood, the Rotation class does not use matrices but a more efficient way based on quaternions. This implies that the rotation you define has the following components: q0 = 0.984807753012208, q1 = 0, q2 = 0, q3 = -0.17364817766693033. The expression computing .applyInverseTo is a combination of q0, q1, q2, q3 and your vector x, y, z. The z component is: (-2 q0 q2) x + (2 q0 q1) y + (2 q0 q0 - 1) z + 2 q3 s where s = q1 x + q2 y + q3 z In your case, q1 and q2 are 0, and floating points multiplications and additions involving 0 are exact, so in your specific case, (and only in this specific case) the z component is (2 (q0^2 + q3^2) - 1) z. As a rotation quaternion is normalized, this should be equal to z since q1 and q2 are 0. however, the floating point numbers q0 and q3 are not perfect, and the multiplicative factor for z is not exactly 1 but is rather 1-epsilon where epsilon is the gap between 1 and the primitive double number just below 1. This means that the values q0 and q3 were already computed to the full accuracy of the computer. I have checked them using our Dfp high accuracy numbers class, and in fact the error in q0 is about 3.905e-17 and the error in q3 is about -1.767e-17, so it is not possible to have better values for q0 and q3, we are already at the limit of the primitive double. Do you agree with this explanation? Can we solve the issue as Not A Problem? was (Author: luc): I don't think it is a real problem. What happens here is simply floating point accuracy which is not absolute. Under the hood, the Rotation class does not use matrices but a more efficient way based on quaternions. This implies that the rotation you define has the following components: q0 = 0.984807753012208, q1 = 0, q2 = 0, q3 = -0.17364817766693033. The expression computing .applyInverseTo is a combination of q0, q1, q2, q3 and your vector x, y, z. The z component is: (-2 q0 q2) x + (2 q0 q1) y + (2 q0 q0 - 1) z + 2 q3 s where s = q1 x + q2 y + q3 z In your case, q1 and q2 are 0, and floating points multiplications and additions involving 0 are exact, so in your specific case, (and only in this specific case) the z component is (2 (q0^2 + q3^2) - 1) z. As a rotation quaternion is normalized, this should be equal to z since q1 and q2 are 0. however, the floating point numbers q0 and q3 are not perfect, and the multiplicative factor for z is not exactly 1 but is rather 1-epsilon where epsilon is the gap between 1 and the primitive double number just below 1. This means that the values q0 and q3 were already computed to the full accuracy of the computer. I have checked them using our Dfp high accuracy numbers class, and in fact the error in q0 is about 3.905e-7 and the error in q3 is about -1.767e-17, so it is not possible to have better values for q0 and q3, we are already at the limit of the primitive double. Do you agree with this explanation? Can we solve the issue as Not A Problem? problem with the rotation - Key: MATH-1157 URL: https://issues.apache.org/jira/browse/MATH-1157 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: Windows 7, Eclipse, Java SE 1.7 Reporter: Frank A Priority: Critical Labels: newbie Fix For: 3.4 Hello, this is my problem: myAngle = 0.3490658503988659 The angle is created with FastMath.toRadians(20). myRotation = new Rotation(RotationOrder.XYZ, 0, 0, myAngle); if I use this on my Vector3D myVector = new Vector3D(4,4,4) with myRotation.applyInverseTo(myVector) I'm get the result x = 5.1268510564463075 y = 2.390689909840958 z = 3.999 (using the .getX() getY() and getZ() functions) Im working with double values, but after the rotation just around the axis z, the z value of my vector shouldn't have changed, but it does. Maybe it is not a bug but a wrong result after a simple rotation, or did I use the rotation in a wrong way? Best regards Frank -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1153) Sampling from a 'BetaDistribution' is slow
[ https://issues.apache.org/jira/browse/MATH-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14154572#comment-14154572 ] Luc Maisonobe commented on MATH-1153: - There is a problem with the GitHub mirror currently, as it does not follow our new Git repository, which is http://git-wip-us.apache.org/repos/asf/commons-math.git Sampling from a 'BetaDistribution' is slow -- Key: MATH-1153 URL: https://issues.apache.org/jira/browse/MATH-1153 Project: Commons Math Issue Type: Improvement Reporter: Sergei Lebedev Priority: Minor Fix For: 3.3 Currently the `BetaDistribution#sample` uses inverse CDF method, which is quite slow for sampling-intensive computations. I've implemented a method from the R. C. H. Cheng paper and it seems to work much better. Here's a simple microbenchmark: {code} o.j.b.s.SamplingBenchmark.algorithmBCorBB 1e-31000 thrpt5 2592200.01514391.520 ops/s o.j.b.s.SamplingBenchmark.algorithmBCorBB 10001000 thrpt5 3210800.2920.791 ops/s o.j.b.s.SamplingBenchmark.commonsVersion1e-31000 thrpt5 31034.225 438.273 ops/s o.j.b.s.SamplingBenchmark.commonsVersion10001000 thrpt5 21834.010 433.324 ops/s {code} Should I submit a patch? R. C. H. Cheng (1978). Generating beta variates with nonintegral shape parameters. Communications of the ACM, 21, 317–322. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1120) Need Percentile computations that can be matched with standard spreadsheet formula
[ https://issues.apache.org/jira/browse/MATH-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe updated MATH-1120: Fix Version/s: (was: 4.0) 3.4 Need Percentile computations that can be matched with standard spreadsheet formula -- Key: MATH-1120 URL: https://issues.apache.org/jira/browse/MATH-1120 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Venkatesha Murthy TS Labels: Percentile Fix For: 3.4 Attachments: 18-jun-percentile-with-estimation-patch, 27-jun-refactored-kth-pivoting.patch, excel-percentile-patch, math-1120-removeAndSlice.patch, percentile-with-estimation-patch, r-output.txt Original Estimate: 504h Remaining Estimate: 504h The current Percentile implementation assumes and hard-codes the quantile pth position as p * (N+1)/100 and provides a kth selected value. However if we need to verify compare/contrast with standard statistical tools such as say MS Excel; it would be good to provide an extensible way of morphing this selection of position than hard code. For example in order to generate the percentile closely matching with MS Excel the position required may be [p*(N-1)/100]+1. Please let me know if i could submit this as a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1120) Need Percentile computations that can be matched with standard spreadsheet formula
[ https://issues.apache.org/jira/browse/MATH-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14116794#comment-14116794 ] Luc Maisonobe commented on MATH-1120: - Yes, it will be included in next version as the code is already in the main branch. Need Percentile computations that can be matched with standard spreadsheet formula -- Key: MATH-1120 URL: https://issues.apache.org/jira/browse/MATH-1120 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Venkatesha Murthy TS Labels: Percentile Fix For: 3.4 Attachments: 18-jun-percentile-with-estimation-patch, 27-jun-refactored-kth-pivoting.patch, excel-percentile-patch, math-1120-removeAndSlice.patch, percentile-with-estimation-patch, r-output.txt Original Estimate: 504h Remaining Estimate: 504h The current Percentile implementation assumes and hard-codes the quantile pth position as p * (N+1)/100 and provides a kth selected value. However if we need to verify compare/contrast with standard statistical tools such as say MS Excel; it would be good to provide an extensible way of morphing this selection of position than hard code. For example in order to generate the percentile closely matching with MS Excel the position required may be [p*(N-1)/100]+1. Please let me know if i could submit this as a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-1120) Need Percentile computations that can be matched with standard spreadsheet formula
[ https://issues.apache.org/jira/browse/MATH-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14068750#comment-14068750 ] Luc Maisonobe commented on MATH-1120: - Patch from today (2014-07-21) applied, with only whitespace changes (removed tabs). Thanks for the patch. Need Percentile computations that can be matched with standard spreadsheet formula -- Key: MATH-1120 URL: https://issues.apache.org/jira/browse/MATH-1120 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Venkatesha Murthy TS Labels: Percentile Fix For: 4.0 Attachments: 18-jun-percentile-with-estimation-patch, 27-jun-refactored-kth-pivoting.patch, excel-percentile-patch, math-1120-removeAndSlice.patch, percentile-with-estimation-patch, r-output.txt Original Estimate: 504h Remaining Estimate: 504h The current Percentile implementation assumes and hard-codes the quantile pth position as p * (N+1)/100 and provides a kth selected value. However if we need to verify compare/contrast with standard statistical tools such as say MS Excel; it would be good to provide an extensible way of morphing this selection of position than hard code. For example in order to generate the percentile closely matching with MS Excel the position required may be [p*(N-1)/100]+1. Please let me know if i could submit this as a patch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-1120) Need Percentile computations that can be matched with standard spreadsheet formula
[ https://issues.apache.org/jira/browse/MATH-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14060050#comment-14060050 ] Luc Maisonobe commented on MATH-1120: - The patch from June 27th has been applied, with a few changes, as the patch did not include the factored out classes. The classes were therefore extracted from the previous version and API adapted for the select method (which now provides the arrays to work on). Thanks for the patch As explained on the mailing list, the problem for FIXED NaNStrategy is still there, and I still want to look at it. Need Percentile computations that can be matched with standard spreadsheet formula -- Key: MATH-1120 URL: https://issues.apache.org/jira/browse/MATH-1120 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Venkatesha Murthy TS Labels: Percentile Fix For: 4.0 Attachments: 18-jun-percentile-with-estimation-patch, 27-jun-refactored-kth-pivoting.patch, excel-percentile-patch, percentile-with-estimation-patch, r-output.txt Original Estimate: 504h Remaining Estimate: 504h The current Percentile implementation assumes and hard-codes the quantile pth position as p * (N+1)/100 and provides a kth selected value. However if we need to verify compare/contrast with standard statistical tools such as say MS Excel; it would be good to provide an extensible way of morphing this selection of position than hard code. For example in order to generate the percentile closely matching with MS Excel the position required may be [p*(N-1)/100]+1. Please let me know if i could submit this as a patch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-1120) Need Percentile computations that can be matched with standard spreadsheet formula
[ https://issues.apache.org/jira/browse/MATH-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040590#comment-14040590 ] Luc Maisonobe commented on MATH-1120: - Yes, but the intermediate instances only copy references, so its only a few bytes. We use the same pattern elsewhere (currently only in a small part of optimization) and intend to use it further (for example in ODE). Having the instance themselves implement the withXxx allow the following use case: {code} Algo a = new Algo().withX().withY(); double result1 = a.doSomeHugeComputation(); Algo b = a.withZ(); double result2 = b.doSomeHugeComputation(); double delta = result2 - result1; // here, we have the differential effect of the withZ() setting {code} Need Percentile computations that can be matched with standard spreadsheet formula -- Key: MATH-1120 URL: https://issues.apache.org/jira/browse/MATH-1120 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Venkatesha Murthy TS Labels: Percentile Fix For: 4.0 Attachments: 18-jun-percentile-with-estimation-patch, excel-percentile-patch, percentile-with-estimation-patch, r-output.txt Original Estimate: 504h Remaining Estimate: 504h The current Percentile implementation assumes and hard-codes the quantile pth position as p * (N+1)/100 and provides a kth selected value. However if we need to verify compare/contrast with standard statistical tools such as say MS Excel; it would be good to provide an extensible way of morphing this selection of position than hard code. For example in order to generate the percentile closely matching with MS Excel the position required may be [p*(N-1)/100]+1. Please let me know if i could submit this as a patch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-1120) Need Percentile computations that can be matched with standard spreadsheet formula
[ https://issues.apache.org/jira/browse/MATH-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040181#comment-14040181 ] Luc Maisonobe commented on MATH-1120: - Patch applied (with several changes) as of r1604614. Please look at what have been applied and discuss about it on the mailing list so we can converge to a final resolution. Thanks a lot for the patch! Need Percentile computations that can be matched with standard spreadsheet formula -- Key: MATH-1120 URL: https://issues.apache.org/jira/browse/MATH-1120 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Venkatesha Murthy TS Labels: Percentile Fix For: 4.0 Attachments: 18-jun-percentile-with-estimation-patch, excel-percentile-patch, percentile-with-estimation-patch, r-output.txt Original Estimate: 504h Remaining Estimate: 504h The current Percentile implementation assumes and hard-codes the quantile pth position as p * (N+1)/100 and provides a kth selected value. However if we need to verify compare/contrast with standard statistical tools such as say MS Excel; it would be good to provide an extensible way of morphing this selection of position than hard code. For example in order to generate the percentile closely matching with MS Excel the position required may be [p*(N-1)/100]+1. Please let me know if i could submit this as a patch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-1120) Need Percentile computations that can be matched with standard spreadsheet formula
[ https://issues.apache.org/jira/browse/MATH-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040218#comment-14040218 ] Luc Maisonobe commented on MATH-1120: - Sure, these methods doulf be moved and API adjusted to be more general. Another thing that should be modified is the random generator for the RANDOM piviting strategy: user should have a way to set the seed, but with an enum it will be tricky. Need Percentile computations that can be matched with standard spreadsheet formula -- Key: MATH-1120 URL: https://issues.apache.org/jira/browse/MATH-1120 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Venkatesha Murthy TS Labels: Percentile Fix For: 4.0 Attachments: 18-jun-percentile-with-estimation-patch, excel-percentile-patch, percentile-with-estimation-patch, r-output.txt Original Estimate: 504h Remaining Estimate: 504h The current Percentile implementation assumes and hard-codes the quantile pth position as p * (N+1)/100 and provides a kth selected value. However if we need to verify compare/contrast with standard statistical tools such as say MS Excel; it would be good to provide an extensible way of morphing this selection of position than hard code. For example in order to generate the percentile closely matching with MS Excel the position required may be [p*(N-1)/100]+1. Please let me know if i could submit this as a patch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-1128) Lazy evaluation needed in o.a.c.m.fitting.leastsquares
[ https://issues.apache.org/jira/browse/MATH-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14032228#comment-14032228 ] Luc Maisonobe commented on MATH-1128: - Seems OK to me. Lazy evaluation needed in o.a.c.m.fitting.leastsquares Key: MATH-1128 URL: https://issues.apache.org/jira/browse/MATH-1128 Project: Commons Math Issue Type: Improvement Affects Versions: 3.3 Reporter: Gilles Assignee: Gilles Labels: regression Fix For: 3.4 Attachments: MATH-1128.patch In LocalLeastSquaresProblem (private inner class defined in o.a.c.m.fitting.leastsquares.LeastSquaresFactory), the evaluate method computes the values of both the model and the Jacobian at creation of the Evaluation instance. Optimizers (LevenbergMarquardtOptimizer in particular) may not need both for all of the evaluated points. And this can lead to too many evaluations of the model which in some applications is the costliest part. In my use-case, the current code in o.a.c.m.fitting.leastquares leads to a performance degradation of about 20% w.r.t. the implementation in o.a.c.m.optim.nonlinear.vector.jacobian. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MATH-1127) 2.0 equal to -2.0
Luc Maisonobe created MATH-1127: --- Summary: 2.0 equal to -2.0 Key: MATH-1127 URL: https://issues.apache.org/jira/browse/MATH-1127 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: Linux, Java 5 Reporter: Luc Maisonobe The following test fails: {code} @Test public void testMath1127() { Assert.assertFalse(Precision.equals(2.0, -2.0, 1)); } {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-1127) 2.0 equal to -2.0
[ https://issues.apache.org/jira/browse/MATH-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1127. - Resolution: Fixed Fix Version/s: 3.4 Fixed in subversion repository as of r1602438. This was a fun one! 2.0 equal to -2.0 - Key: MATH-1127 URL: https://issues.apache.org/jira/browse/MATH-1127 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: Linux, Java 5 Reporter: Luc Maisonobe Fix For: 3.4 The following test fails: {code} @Test public void testMath1127() { Assert.assertFalse(Precision.equals(2.0, -2.0, 1)); } {code} -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-1123) NPE in BSPTree#fitToCell()
[ https://issues.apache.org/jira/browse/MATH-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001575#comment-14001575 ] Luc Maisonobe commented on MATH-1123: - Could you explain in which situation you encounter the exception? The fitToCell method is a private one and should be called only in controlled case where the error should not occur. So rather if you encounter this, it is an indication something wrong already occurs before the call, and I guess it should be fixed too. The best way would be to have a small reproducible test case that we could add as a non-regression unit test once the problem is fixed. NPE in BSPTree#fitToCell() -- Key: MATH-1123 URL: https://issues.apache.org/jira/browse/MATH-1123 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: Win32_64 Reporter: Labrosse Aurélien Hello, I faced a NPE using BSPTree#fitToCell() from the SVN trunk. I fixed the problem using a small patch I will attach to the ticket. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-1123) NPE in BSPTree#fitToCell()
[ https://issues.apache.org/jira/browse/MATH-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1123. - Resolution: Fixed Fix Version/s: 3.4 Fixed in subversion repository as of r1595924. The problem was triggered as several points from the convex hull were aligned when the convec region was built. As such convex regions can also be built directly by users from regular public API, the place you fixed it was appropriate. So I simply moved the test as a stop condition in the loop, but it was quite good as is. Thanks for the report and for the patch. NPE in BSPTree#fitToCell() -- Key: MATH-1123 URL: https://issues.apache.org/jira/browse/MATH-1123 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: Win32_64 Reporter: Labrosse Aurélien Fix For: 3.4 Attachments: ConvexHullTest.java Hello, I faced a NPE using BSPTree#fitToCell() from the SVN trunk. I fixed the problem using a small patch I will attach to the ticket. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-1123) NPE in BSPTree#fitToCell()
[ https://issues.apache.org/jira/browse/MATH-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14001965#comment-14001965 ] Luc Maisonobe commented on MATH-1123: - Yes, the hull is correct and I agree colinear point can be included. It was the BSPTree built from these points that triggered a problem. As users could have chosen to build a convex region directly from these points, it was really at BSP level that such points should be handled properly. We had already encountered this problem previously, but I failed to fix it. The previous cases were due to numerical noise, as the original point were not exactly aligned. However, exactly aligned point do occur and should be accepted. This new use case is really interesting since it does trigger the problem with exact integer coordinates. I have added it as a junit test in the general abstract test for all convex hull algorithms as it seemed interesting even for hull themselves, even if they were not really involved this time. NPE in BSPTree#fitToCell() -- Key: MATH-1123 URL: https://issues.apache.org/jira/browse/MATH-1123 Project: Commons Math Issue Type: Bug Affects Versions: 3.3 Environment: Win32_64 Reporter: Labrosse Aurélien Fix For: 3.4 Attachments: ConvexHullTest.java, convex.png Hello, I faced a NPE using BSPTree#fitToCell() from the SVN trunk. I fixed the problem using a small patch I will attach to the ticket. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-1117) twod.PolygonsSet.getSize produces NullPointerException if BSPTree has no nodes
[ https://issues.apache.org/jira/browse/MATH-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982785#comment-13982785 ] Luc Maisonobe commented on MATH-1117: - Yes, these constructors are used outside of their package. Typically, the constructor for polygons (in 2D) is called from the split method in SubPlane and also from an internal class in OutlineExtractor, both in the 3D package. As the methods have been public for a while, they may also be used from user code. The call from the split method is a very important one: it is used a very large number of times as part of building 3D BSP trees, and here the tree has been built using a complex algorithm to ensure it is correct, so we don't want to visit all its leafs to check it. Thanks for the hint about the typos, I have fixed them now. twod.PolygonsSet.getSize produces NullPointerException if BSPTree has no nodes -- Key: MATH-1117 URL: https://issues.apache.org/jira/browse/MATH-1117 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Environment: Mac OS 10.9, Java 6, 7 Reporter: Cyrille Artho Fix For: 3.3 Attachments: Report3.java, Report3_1.java org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.getSize() uses a tree internally: final BSPTreeEuclidean2D tree = getTree(false); However, if that tree contains no data, it seems that the reference returned is null, which causes a subsequent NullPointerException. Probably an exception with a message (tree has no data) would clarify that this is an API usage error. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-1117) twod.PolygonsSet.getSize produces NullPointerException if BSPTree has no nodes
[ https://issues.apache.org/jira/browse/MATH-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1117. - Resolution: Fixed Fix Version/s: 3.3 The two problems you report are completely different from each other. The first report is really a wrong API use. The call did not fulfill the constraints that were already given in the javadoc, i.e. that the provided tree MUST have proper Boolean attributes at leaf nodes. There is no verification here for performance reasons (it would imply walking the full trees all the time). I really don't think it would be a good idea to do such verifications. So I only improved the javadoc of the constructor to make it more clear this constructor is for expert use only (building a tree is difficult) and that there is no verifications, adding in the documentation that failing to provide appropriate arguments is the responsibility of users. In fact, general users should never use this specific constructor, but should rely on the other ones which are there precisely to avoid this kind of errors : the other constructors ensure the tree is correct before calling this constructor. The second one is a real problem, I have fixed it (see r1590251). Please reopen the issue if you do not agree with the fix for the first problem, as it is documentation only. twod.PolygonsSet.getSize produces NullPointerException if BSPTree has no nodes -- Key: MATH-1117 URL: https://issues.apache.org/jira/browse/MATH-1117 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Environment: Mac OS 10.9, Java 6, 7 Reporter: Cyrille Artho Fix For: 3.3 Attachments: Report3.java, Report3_1.java org.apache.commons.math3.geometry.euclidean.twod.PolygonsSet.getSize() uses a tree internally: final BSPTreeEuclidean2D tree = getTree(false); However, if that tree contains no data, it seems that the reference returned is null, which causes a subsequent NullPointerException. Probably an exception with a message (tree has no data) would clarify that this is an API usage error. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-1115) Constructor of PolyhedronsSet throws NullPointerException
[ https://issues.apache.org/jira/browse/MATH-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1115. - Resolution: Fixed Fix Version/s: 3.3 Fixed in subversion repository as of r1590254. We have also included the same javadoc improvements as in MATH-1117. Thanks for the report. Constructor of PolyhedronsSet throws NullPointerException - Key: MATH-1115 URL: https://issues.apache.org/jira/browse/MATH-1115 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Environment: Mac OS 10.9 with Java 6, 7 Reporter: Cyrille Artho Fix For: 3.3 Attachments: Report1.java, Report1a.java The following statement throws a NullPointerException: new org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet(0.0d, 0.0d, 0.0d, 0.0d, 0.0d, 0.0d); I found that other numbers also produce that effect. The stack trace: java.lang.NullPointerException at org.apache.commons.math3.geometry.partitioning.BSPTree.fitToCell(BSPTree.java:297) at org.apache.commons.math3.geometry.partitioning.BSPTree.insertCut(BSPTree.java:155) at org.apache.commons.math3.geometry.partitioning.RegionFactory.buildConvex(RegionFactory.java:55) at org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet.buildBoundary(PolyhedronsSet.java:119) at org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet.init(PolyhedronsSet.java:97) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-1119) Add fast single-step method for fixed-step ODE integrators
[ https://issues.apache.org/jira/browse/MATH-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-1119. - Resolution: Fixed Fixed in subversion repository as of r1588769. Add fast single-step method for fixed-step ODE integrators -- Key: MATH-1119 URL: https://issues.apache.org/jira/browse/MATH-1119 Project: Commons Math Issue Type: Improvement Affects Versions: 3.2 Reporter: Luc Maisonobe Assignee: Luc Maisonobe Priority: Minor Fix For: 3.3 Sometimes, very fast computation of only a few steps of an ODE integrators are needed and embedded in much larger loops. Setting up a full-blown integrators with all its bells and whistles is cumbersome in this case where only the final state is desired. A stripped-down version of the ODE integrator using only the Butcher arrays from Runge-Kutta integrators would be nice. -- This message was sent by Atlassian JIRA (v6.2#6252)