[jira] [Commented] (MATH-1341) "RandomDataGenerator" is brittle

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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"

[Luc Maisonobe (JIRA)]

[ 
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"

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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"

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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 (JIRA)]

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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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 
 for
the thread or here 
.

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 (JIRA)]

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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

 [ 
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 (JIRA)]

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

[Luc Maisonobe (JIRA)]

 [ 
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 Circle(new 
> Vector3D(2.1793884139073498E-4, 0.9790647032675541, -0.20354915700704285),
>  

[jira] [Created] (MATH-1232) UknownParameterException message prints {0} instead of parameter name

[Luc Maisonobe (JIRA)]

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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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 (JIRA)]

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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

 [ 
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.

[Luc Maisonobe (JIRA)]

 [ 
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)

[jira] [Created] (MATH-1188) BesselJ java contains non-Java5 code.

[Luc Maisonobe (JIRA)]

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 ?

[Luc Maisonobe (JIRA)]

[ 
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 ?

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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 (JIRA)]

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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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 (JIRA)]

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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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 (JIRA)]

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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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 (JIRA)]

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

[Luc Maisonobe (JIRA)]

 [ 
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()

[Luc Maisonobe (JIRA)]

[ 
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()

[Luc Maisonobe (JIRA)]

 [ 
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()

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

[ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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

[Luc Maisonobe (JIRA)]

 [ 
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)

[jira] [Resolved] (MATH-1107) CMAESOptimizer fails sometimes when bounds are violated

[Luc Maisonobe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MATH-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-1107.
-

Resolution: Fixed

Patch applied (with minor changes) as of r1573506.

Thanks for the report and for the patch!

 CMAESOptimizer fails sometimes when bounds are violated
 ---

 Key: MATH-1107
 URL: https://issues.apache.org/jira/browse/MATH-1107
 Project: Commons Math
  Issue Type: Bug
Reporter: Bruce A Johnson
 Fix For: 3.3

 Attachments: cmaes_penalty.patch


 The CMAESOptimizer repairs points that are out of bounds by moving them into 
 bounds, and adding a penalty based on how far they were moved.
 The penalty added is scaled by the range of values in the current population.
 The calculation of the valueRange, however, includes the penalty so at each 
 iteration the amount of penalty can grow multiplicatively.  One solution, is 
 to keep the value and penalties separate before calculating the scale factor 
 for the penalties.  A patch that does this will be attached.



--
This message was sent by Atlassian JIRA
(v6.2#6252)