[jira] [Resolved] (MATH-668) Polygon difference function produces erroneous results with certain polygons
[ https://issues.apache.org/jira/browse/MATH-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-668. Resolution: Not A Problem Fix Version/s: (was: 3.1) 3.0 I agree with Thomas analyses. Concerning the difference2 case, the two points are explained by the vertical line at x = 5.0 which comes from the outer shape. The internal representation is a BSP tree and one of this part of the outer boundary creates an hyperplane that splits the inner triangle. When the boundary representation is rebuilt, the two segments are glued together and the points appear there. There is no post-processing that simplifies the representation afterwards. Concerning the circle test, I guess you mixed the arrays. What is really in the code is that the vertices2 array is build first from outer circle and the vertices1 array is built afterwards from inner circle. So you are really subtracting a big disk from a smaller one. As Thomas explained, computing set2 minus set1 give the expected two boundaries. Another possible change is to build the circles clockwise instead of counter-clockwise, and in this case the two regions are infinite wich a whole at the center, then subtracting set2 from set1 returns a disk with a hole. Polygon difference function produces erroneous results with certain polygons Key: MATH-668 URL: https://issues.apache.org/jira/browse/MATH-668 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Curtis Jensen Assignee: Luc Maisonobe Labels: difference, math,, polygon, Fix For: 3.0 Attachments: PolygonsSetCircleTest.java, PolygonsSetTest.java Original Estimate: 168h Remaining Estimate: 168h For some polygons, the difference function produces erroneous results. This appears to happen when one polygon is completely encompassed in another, and the outer has multiple concave sections. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-742) Please make PolynomialSplineFunction Serializable
[
https://issues.apache.org/jira/browse/MATH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-742.
Resolution: Won't Fix
After a discussion on the developers list, the consensus reached was to not set
up Serializable for this kind of objects. See the mailing lists archives for
the complete thread.
There are several workarounds you can use to solve your problem.
You could use a custom derived class that would implement Serialible. The only
code you would have to write is the constructors that would call the
constructors of the base class.
An alternative solution would be to keep the existing non serializable class as
is but implement Serialization by custom code on the application level. This
would work of course only if you have access to the serialization framework
code.
Please make PolynomialSplineFunction Serializable
-
Key: MATH-742
URL: https://issues.apache.org/jira/browse/MATH-742
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Neil Roeth
Priority: Minor
Attachments: PolynomialSplineFunction.java
PolynomialSplineFunction is not Serializable, while the very similar
PolynomialFunction class in the same package is. All that needs to be done is
to add the import:
{{import java.io.Serializable;}}
and change this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction}}
to this:
{{public class PolynomialSplineFunction implements
DifferentiableUnivariateRealFunction, Serializable}}
I made exactly that modification to a local copy and it serialized
successfully. Before the change, I got serialization errors.
Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-650) FastMath has static code which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-650. Resolution: Fixed Soved in subversion repository as of r1244725. Selected Sebb's patch using literal arrays with a cloning protection. FastMath has static code which slows the first access to FastMath - Key: MATH-650 URL: https://issues.apache.org/jira/browse/MATH-650 Project: Commons Math Issue Type: Improvement Affects Versions: Nightly Builds Environment: Android 2.3 (Dalvik VM with JIT) Reporter: Alexis Robert Priority: Minor Fix For: 3.0 Attachments: FastMathLoadCheck.java, LucTestPerformance.java Working on an Android application using Orekit, I've discovered that a simple FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the first time it's called). I've launched the Android profiling tool (traceview) and the problem seems to be linked with the static portion of FastMath code named // Initialize tables The timing resulted in : - FastMath.slowexp (40.8%) - FastMath.expint (39.2%) \- FastMath.quadmult() (95.6% of expint) - FastMath.slowlog (18.2%) Hoping that would help Thanks! Alexis Robert -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-727) too large first step with embedded Runge-Kutta integrators (Dormand-Prince 8(5,3) ...)
[ https://issues.apache.org/jira/browse/MATH-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-727. Resolution: Fixed Fixed in subversion repository as of r1215524. too large first step with embedded Runge-Kutta integrators (Dormand-Prince 8(5,3) ...) -- Key: MATH-727 URL: https://issues.apache.org/jira/browse/MATH-727 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Luc Maisonobe Assignee: Luc Maisonobe Fix For: 3.0 Adaptive step size integrators compute the first step size by themselves if it is not provided. For embedded Runge-Kutta type, this step size is not checked against the integration range, so if the integration range is extremely short, this step size may evaluate the function out of the range (and in fact it tries afterward to go back, and fails to stop). Gragg-Bulirsch-Stoer integrators do not have this problem, the step size is checked and truncated if needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-716) BracketingNthOrderBrentSolver exceeds maxIterationCount while updating always the same boundary
[ https://issues.apache.org/jira/browse/MATH-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-716. Resolution: Fixed Fix Version/s: 3.0 Fixed in subversion repository as of r1209307. Thanks for the report. BracketingNthOrderBrentSolver exceeds maxIterationCount while updating always the same boundary --- Key: MATH-716 URL: https://issues.apache.org/jira/browse/MATH-716 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Pascal Parraud Assignee: Luc Maisonobe Priority: Minor Fix For: 3.0 In some cases, the aging feature in BracketingNthOrderBrentSolver fails. It attempts to balance the bracketing points by targeting a non-zero value instead of the real root. However, the chosen target is too close too zero, and the inverse polynomial approximation is always on the same side, thus always updates the same bracket. In the real used case for a large program, I had a bracket point xA = 12500.0, yA = 3.7e-16, agingA = 0, which is the (really good) estimate of the zero on one side of the root and xB = 12500.03, yB = -7.0e-5, agingB = 97. This shows that the bracketing interval is completely unbalanced, and we never succeed to rebalance it as we always updates (xA, yA) and never updates (xB, yB). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-485) Feature Request: Kalman Filter
[ https://issues.apache.org/jira/browse/MATH-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-485. Resolution: Fixed Latest patch applied, with new tests and user guide. Thanks for the patch! Feature Request: Kalman Filter -- Key: MATH-485 URL: https://issues.apache.org/jira/browse/MATH-485 Project: Commons Math Issue Type: Wish Reporter: Benjamin McCann Fix For: 3.0 Attachments: KalmanFilterTest.java, MATH-485-cleanup2.patch, MATH-485-update1.patch, MATH-485.patch, filter.xml I'd love it if Commons Math could add support for the Kalman filter. Here are a few implementations that might be able to be used for reference or included if they're using compatible licenses: http://code.google.com/p/efficient-java-matrix-library/wiki/KalmanFilterExamples http://mathstat.asu.edu/~eubank/ http://www.fit.vutbr.cz/research/prod/index.php.en?id=53notitle=1 http://sourceforge.net/projects/jkalman/ http://www.vni.com/products/imsl/jmsl/v30/api/com/imsl/stat/KalmanFilterEx1.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-196) add support to constrained parameter estimation
[ https://issues.apache.org/jira/browse/MATH-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-196. Resolution: Fixed Fixed in subversion repository as of r1206821. Some optimizers (CMA-ES and Bobyqa, still under development) support natively simple bounds constrained optimization. For direct optimizers not supporting natively simple bounds constrained optimization, two function adapters have been set up, using either a penalty function or a mapping to unbounded variables. add support to constrained parameter estimation --- Key: MATH-196 URL: https://issues.apache.org/jira/browse/MATH-196 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Reporter: Luc Maisonobe Assignee: Luc Maisonobe Fix For: 3.0 The current estimation package supports only unconstrained problems. It should at least support simple bounds constrains on parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-714) init methods for event handler and stap handler in ODE
[ https://issues.apache.org/jira/browse/MATH-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-714. Resolution: Fixed Fixed in subversion repository as of r1207054. init methods for event handler and stap handler in ODE -- Key: MATH-714 URL: https://issues.apache.org/jira/browse/MATH-714 Project: Commons Math Issue Type: Improvement Affects Versions: 2.1 Reporter: Luc Maisonobe Assignee: Luc Maisonobe Priority: Minor Fix For: 3.0 The EventHandler interface does not provide any way to initialize the step handler at integration start. The StepHandler interface does have this feature, but it uses a confusing name (reset) which can easily be confused with the resetState method of the EventHandler interface despite it has nothing to do with events based resets. Both interfaces being often used together, it would be nice to have an init method in both interfaces, with arguments t0, y0 and t representing the integration boundaries. The init method would simply replace the reset method in the StepHandler interface and it would be a new method in the EventHandler interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-710) Add support for fast cryptographically secure pseudorandom number generator ISAAC
[ https://issues.apache.org/jira/browse/MATH-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-710. Resolution: Fixed Fixed in subversion repository as of r1207554. Patch applied with minor changes in javadoc (added javadoc for all methods, moved author name to pom file as per Apache Commons policy). Thanks for the report and for the patch. Add support for fast cryptographically secure pseudorandom number generator ISAAC - Key: MATH-710 URL: https://issues.apache.org/jira/browse/MATH-710 Project: Commons Math Issue Type: New Feature Affects Versions: 2.2 Reporter: Eldar Agalarov Assignee: Luc Maisonobe Priority: Minor Fix For: 3.0 Attachments: ISAACRandom.java, ISAACTest.java Original Estimate: 1h Remaining Estimate: 1h Dear developers, please add to Commons Math library support for ISAAC random number generator. This is a free and open-source CSPRNG (see at http://burtleburtle.net/bob/rand/isaacafa.html). Rewrited (with some improvements) Java code from original C version is attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-713) Negative value with restrictNonNegative
[ https://issues.apache.org/jira/browse/MATH-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-713. Resolution: Fixed Fix Version/s: 3.0 Fixed in subversion repository as of r1207566. Patch applied directly. Thanks to Michal for the report and thanks to Thomas for the patch. Negative value with restrictNonNegative --- Key: MATH-713 URL: https://issues.apache.org/jira/browse/MATH-713 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Environment: commons-math-2.2 Reporter: Michał Skrzypczak Labels: nonnegative, simplex, solver Fix For: 3.0 Attachments: MATH-713.patch Original Estimate: 3h Remaining Estimate: 3h Problem: commons-math-2.2 SimplexSolver. A variable with 0 coefficient may be assigned a negative value nevertheless restrictToNonnegative flag in call: SimplexSolver.optimize(function, constraints, GoalType.MINIMIZE, true); Function 1 * x + 1 * y + 0 Constraints: 1 * x + 0 * y = 1 Result: x = 1; y = -1; Probably variables with 0 coefficients are omitted at some point of computation and because of that the restrictions do not affect their values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-705) DormandPrince853 integrator leads to revisiting of state events
[
https://issues.apache.org/jira/browse/MATH-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-705.
Resolution: Fixed
Fixed in subversion repository as of r1206723.
Applied same method to all Runge-Kutta based integrators.
Thanks for the report.
DormandPrince853 integrator leads to revisiting of state events
---
Key: MATH-705
URL: https://issues.apache.org/jira/browse/MATH-705
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Environment: Commons Math trunk, Java 6, Linux
Reporter: Dennis Hendriks
Assignee: Luc Maisonobe
Fix For: 3.0
Attachments: ReappearingEventTest.java, ReappearingEventTest.out
See the attached ReappearingEventTest.java. It has two unit tests, which use
either the DormandPrince853 or the GraggBulirschStoer integrator, on the same
ODE problem. It is a problem starting at time 6.0, with 7 variables, and 1
state event. The state event was previously detected at time 6.0, which is
why I start there now. I provide and end time of 10.0. Since I start at the
state event, I expect to integrate all the way to the end (10.0). For the
GraggBulirschStoer this is what happens (see attached
ReappearingEventTest.out). For the DormandPrince853Integerator, it detects a
state event and stops integration at 6.002.
I think the problem becomes clear by looking at the output in
ReappearingEventTest.out, in particular these lines:
{noformat}
computeDerivatives: t=6.0 y=[2.0 , 2.0
, 2.0 , 4.0 , 2.0 ,
7.0 , 15.0]
(...)
g : t=6.0 y=[1.9996 ,
1.9996 , 1.9996 , 4.0 ,
1.9996 , 7.0 , 14.998 ]
(...)
final result : t=6.002y=[2.0013 ,
2.0013 , 2.0013 , 4.002 ,
2.0013 , 7.002 , 15.0]
{noformat}
The initial value of the last variable in y, the one that the state event
refers to, is 15.0. However, the first time it is given to the g function,
the value is 14.998. This value is less than 15, and more
importantly, it is a value from the past (as all functions are increasing),
*before* the state event. This makes that the state event re-appears
immediately, and integration stops at 6.002 because of the
detected state event.
I find it puzzling that for the DormandPrince853Integerator the y array that
is given to the first evaluation of the g function, has different values than
the y array that is the input to the problem. For GraggBulirschStoer is can
be seen that the y arrays have identical values.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-709) BigFraction percentageValue does BigInteger divide.
[ https://issues.apache.org/jira/browse/MATH-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-709. Resolution: Fixed Fix Version/s: 3.0 Fixed in subversion repository as of r1203516. I have also added the percentage method to Fraction. Thanks for the report. BigFraction percentageValue does BigInteger divide. --- Key: MATH-709 URL: https://issues.apache.org/jira/browse/MATH-709 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Brent D. Milton Fix For: 3.0 integer divide of 1/2 returns 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-706) Bad interaction between step handlers and events detectors that reset state in ODE integrators
[ https://issues.apache.org/jira/browse/MATH-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-706. Resolution: Fixed Fixed in subversion repository as of r1201105. Bad interaction between step handlers and events detectors that reset state in ODE integrators -- Key: MATH-706 URL: https://issues.apache.org/jira/browse/MATH-706 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Luc Maisonobe Assignee: Luc Maisonobe Fix For: 3.0 During ODE integration, when en event detector attempts to reset a state, if there are also step handlers associated with the integrator, the reset state is not called with the state at event time, but may be called with some other state. The time provided always correspond to the real event time (and hence is inconsistent with the state). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-702) CMA-ES optimizer input sigma should not be normalized by user
[ https://issues.apache.org/jira/browse/MATH-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-702. Resolution: Fixed Fixed in subversion repository as of r1198741. CMA-ES optimizer input sigma should not be normalized by user - Key: MATH-702 URL: https://issues.apache.org/jira/browse/MATH-702 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Luc Maisonobe Priority: Minor Fix For: 3.0 I am trying to use CMA-ES optimizer with simple boundaries. It seems the inputSigma parameter should be normalized as it is checked against the [0 - 1] range in the checkParameters private method and as its value defaults to 0.3 if not not set in the initializeCMA private method. I would have expected this value to be in the same units as the user parameters and to be normalized as part of an internal processing step instead of relying to the user doing this. I think the method need normalized values internally, as per the encode/decode methods in the inner class FitnessFunction suggest. The optimizer should accept values in the same units as the other parameters and use encode (or a similar function) to do the normalization. This way, normalization is considered an internal implementation detail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-695) Incomplete reinitialization with some events handling
[ https://issues.apache.org/jira/browse/MATH-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-695. Resolution: Fixed Fix Version/s: 3.0 Fixed in subversion repository as of r1189086. The fix is different from the proposed patch, it directly updates the events when the step truncation occurs, thus preventing even transient inconsistency. Thanks for the report and for the patch. Incomplete reinitialization with some events handling - Key: MATH-695 URL: https://issues.apache.org/jira/browse/MATH-695 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Pascal Parraud Assignee: Luc Maisonobe Fix For: 3.0 Attachments: events.patch, test-case-MATH-695.patch I get a bug with event handling: I track 2 events that occur in the same step, when the first one is accepted, it resets the state but the reinitialization is not complete and the second one becomes unable to find its way. I can't give my context, which is rather large, but I tried a patch that works for me, unfortunately it breaks the unit tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-682) Pascal triangle
[ https://issues.apache.org/jira/browse/MATH-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-682. Resolution: Not A Problem The existing binomial coefficients methods in MathUtils already provide this feature. Pascal triangle Key: MATH-682 URL: https://issues.apache.org/jira/browse/MATH-682 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Environment: All Reporter: DI COSTANZO Priority: Trivial Attachments: PascalTriangle.java, PascalTriangle.java, PascalTriangle.java, PascalTriangleTest.java, PascalTriangleTest.java Create a method to get Pascal's triangle coefficient. This method could be implemented in MathUtils, in a static way, with the following signature : double[] getTriangleCoefficient(final int order) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-679) Integer overflow in OpenMapRealMatrix
[ https://issues.apache.org/jira/browse/MATH-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-679. Resolution: Fixed Fix Version/s: 3.0 Fixed in subversion repository as of r1181181. Thanks for the report and the workaround. Integer overflow in OpenMapRealMatrix - Key: MATH-679 URL: https://issues.apache.org/jira/browse/MATH-679 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Christopher Berner Priority: Minor Fix For: 3.0 Attachments: Flaw.java computeKey() has an integer overflow. Since it is a sparse matrix, this is quite easily encountered long before heap space is exhausted. The attached code demonstrates the problem, which could potentially be a security vulnerability (for example, if one was to use this matrix to store access control information). Workaround: never create an OpenMapRealMatrix with more cells than are addressable with an int. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-687) Add the Jacobi polynomials in the class PolynomialsUtils
[ https://issues.apache.org/jira/browse/MATH-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-687. Resolution: Fixed Fix Version/s: 3.0 Fixed in subversion repository as of r1180092. Thanks for the report and the patch. Add the Jacobi polynomials in the class PolynomialsUtils Key: MATH-687 URL: https://issues.apache.org/jira/browse/MATH-687 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Environment: all Reporter: DI COSTANZO Priority: Trivial Fix For: 3.0 Attachments: jacobi.patch Jacobi polynomials Pk(vw) are a generalization of the legendre polynomial. Legendre Polynomials are Jacobi polynomials for v = w = 0. They are orthogonal polynomials and are defined from a recursion formula, giving the n+1 element of the polynomial from the nth element and the (n-1)'s one Therefore, they could be implemented in the PolynomialsUtils and use the generic frame already used in this class to create and store them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-445) Replace package.html by package-info.java
[ https://issues.apache.org/jira/browse/MATH-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-445. Resolution: Fixed Fixed in subversion repository as of r1178168. The script has been fixed with respect to the missing space and committed in commons/script for general use. The missing spaces have been added directly to the already converted package-info.java files. The checkstyle plugin used by maven has been upgraded so the underlying checkstyle is 5.x, so we can use package-info.java. Replace package.html by package-info.java - Key: MATH-445 URL: https://issues.apache.org/jira/browse/MATH-445 Project: Commons Math Issue Type: Task Reporter: Gilles Priority: Trivial Fix For: 3.0 The newest (and recommended, I think) way of documenting packages is through package-info.java files. CM still uses package.html files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-380) Need to (re)initialize dYdY0 for multiple integrate with FirstOrderIntegratorWithJacobians
[ https://issues.apache.org/jira/browse/MATH-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-380. Resolution: Fixed fixed in subversion repository as of r1176745. Need to (re)initialize dYdY0 for multiple integrate with FirstOrderIntegratorWithJacobians -- Key: MATH-380 URL: https://issues.apache.org/jira/browse/MATH-380 Project: Commons Math Issue Type: Bug Affects Versions: 2.1 Reporter: Pascal Parraud Assignee: Luc Maisonobe Priority: Minor Fix For: 3.0 There is a lack in the method integrate of FirstOrderIntegratorWithJacobians. The jacobian DYDY0 can't be initialized by the user, unlike DFDP with DF0DP. So, for several successive integrations, the matrix is reinitialized to identity and that is not what we might want. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-381) inconsistency for methods names within StepInterpolator and StepInterpolatorWithJacobians
[ https://issues.apache.org/jira/browse/MATH-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-381. Resolution: Fixed Fixed in subversion repository as of r1176745 inconsistency for methods names within StepInterpolator and StepInterpolatorWithJacobians - Key: MATH-381 URL: https://issues.apache.org/jira/browse/MATH-381 Project: Commons Math Issue Type: Bug Affects Versions: 2.1 Reporter: Pascal Parraud Priority: Trivial Fix For: 3.0 There is some inconstency in methods naming : getInterpolatedY and getInterpolatedYDot in StepInterpolatorWithJacobians do the same as getInterpolatedState and getInterpolatedDerivatives in StepInterpolator, so it will be better if they would have the same name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-487) Deprecate ConvergenceException in MATH_2_X and remove it in trunk
[
https://issues.apache.org/jira/browse/MATH-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-487.
Resolution: Fixed
Fix Version/s: (was: 2.2)
Fixed in subversion repository as of r1177986.
The checked exception has been replaced by the unchecked one that lies in the
exception package.
Deprecate ConvergenceException in MATH_2_X and remove it in trunk
---
Key: MATH-487
URL: https://issues.apache.org/jira/browse/MATH-487
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Priority: Minor
Fix For: 3.0
The checked ConvergenceException should be deprecated.
An example usage is in class {{ContinuedFraction}} (package {{util}}), at
line 153:
{noformat}
if (scale = 0) { // Can't scale
throw new
ConvergenceException(LocalizedFormats.CONTINUED_FRACTION_INFINITY_DIVERGENCE,
x);
}
{noformat}
I think that it should be replaced by a more specific (and unchecked)
exception that reflects the exact low-level problem:
{noformat}
if (scale = 0) { // Can't scale
throw new NotStrictlypositiveException(scale);
}
{noformat}
A few lines below that, there is:
{noformat}
if (infinite) {
// Scaling failed
throw new
ConvergenceException(LocalizedFormats.CONTINUED_FRACTION_INFINITY_DIVERGENCE,
x);
}
{noformat}
So it seems that it is not necessary to throw an exception at the place where
the test on scale fails; instead we could have:
{noformat}
infinite = true;
if (scale = 0) { // Can't scale
break;
}
{noformat}
and let the check on infinite throw the exception:
{noformat}
if (infinite) {
// Scaling failed
throw new
NotFiniteNumberException(LocalizedFormats.CONTINUED_FRACTION_DIVERGENCE,
Double.POSITIVE_INFINITY, x);
}
{noformat}
As shown in the above excerpt, we could also replace two {{enum}}:
* CONTINUED_FRACTION_INFINITY_DIVERGENCE
* CONTINUED_FRACTION_NAN_DIVERGENCE
with a single one:
* CONTINUED_FRACTION_DIVERGENCE
because the other bit of information (infinity vs NaN) is already given by
the first parameter of the message.
What do you think of these changes?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-569) Add more operators to FieldElementT
[ https://issues.apache.org/jira/browse/MATH-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-569. Resolution: Won't Fix Setting to Won't Fix as per comments above. Add more operators to FieldElementT - Key: MATH-569 URL: https://issues.apache.org/jira/browse/MATH-569 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Arne Plöse Priority: Minor it would be nice to have some additional operators in FieldElement i.e. T negate(); T pow(T x); T sqrt(); maybe the double variant i.e. T pow(double x); as well. This would be affect FieldVector | Matrix, BigReal, ... as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-571) make FieldVector generic
[
https://issues.apache.org/jira/browse/MATH-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-571.
Resolution: Won't Fix
Setting to Won't Fix as per comments above.
make FieldVector generic
Key: MATH-571
URL: https://issues.apache.org/jira/browse/MATH-571
Project: Commons Math
Issue Type: Improvement
Reporter: Arne Plöse
Priority: Minor
Fix For: 3.0
make FieldVector generic, so one can extend i.e. ArrayVieldVectorComplex to
ArrayComplexVector an introduce new methoids (getReal())...
if one has an equation complexvector.copy the original type
ArrayComplexVector is lost thus access to getReal() is not possible.
solution:
public class InheritationTest {
public static interface FieldVectorT extends FieldElementT, R extends
FieldVector {
R copy();
}
public abstract static class ArrayFieldVectorExtendableT extends
FieldElementT, R extends FieldVector implements FieldVectorT, R,
Serializable {
protected T[] data;
@Override
public R copy() {
return createVector(data);
}
abstract protected R createVector(T[] data);
}
public static class ArrayFieldVectorT extends FieldElementT extends
ArrayFieldVectorExtendableT, ArrayFieldVector {
@Override
protected ArrayFieldVectorT createVector(T[] data) {
ArrayFieldVectorT result = new ArrayFieldVectorT();
result.data = data;
return result;
}
}
public static class ArrayComplexVector extends
ArrayFieldVectorExtendableComplex, ArrayComplexVector {
@Override
protected ArrayComplexVector createVector(Complex[] data) {
ArrayComplexVector result = new ArrayComplexVector();
result.data = data;
return result;
}
public double[] getReal() {
return null;
}
public double[] getImaginary() {
return null;
}
}
public void test() {
ArrayComplexVector v = new ArrayComplexVector();
ArrayComplexVector v1 = v.copy(); // FiledVector type survives ...
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-457) Remove usage of OptimizationException
[
https://issues.apache.org/jira/browse/MATH-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-457.
Resolution: Fixed
Fixed in subversion repository as of r1178006.
Remove usage of OptimizationException
---
Key: MATH-457
URL: https://issues.apache.org/jira/browse/MATH-457
Project: Commons Math
Issue Type: Improvement
Reporter: Gilles
Priority: Minor
Fix For: 3.0
{{OptimizationException}} (defined in package {{optimization}}) is still used
in classes of packages {{optimization.linear}} and {{optimization.fitting}}.
Its occurrences must be removed, or replaced by the corresponding exception
from the {{exception}} package.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-284) Avoid ArrayStoreException
[
https://issues.apache.org/jira/browse/MATH-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luc Maisonobe resolved MATH-284.
Resolution: Fixed
Fixed in subversion repository as of r1178009.
Thanks for the report and the fix suggestion.
Avoid ArrayStoreException
-
Key: MATH-284
URL: https://issues.apache.org/jira/browse/MATH-284
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Klaus
Priority: Minor
Fix For: 3.0
Attachments: math-284.patch
Add a new method
org.apache.commons.math,Field#getRuntimeClass():
...
/**
* Returns the runtime class of the FieldElement.
*
* @return The {@code Class} object that represents the runtime
* class of this object.
*/
Class? extends FieldElement getRuntimeClass();
...
and replace all occurrences of
Array.newInstance(field.getZero().getClass(),)
with
Array.newInstance(field.getRuntimeClass(),)
to avoid the throwing of ArrayStoreException in the case you have a type
hierachy of Fields with a common interface
and the array should have the interface type at runtime.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-445) Replace package.html by package-info.java
[ https://issues.apache.org/jira/browse/MATH-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-445. Resolution: Fixed Fixed in subversion repository as of r1178067. A shell+sed script has been created for this conversion, it can be found here: [http://people.apache.org/~luc/convert-to-package-info.sh] Replace package.html by package-info.java - Key: MATH-445 URL: https://issues.apache.org/jira/browse/MATH-445 Project: Commons Math Issue Type: Task Reporter: Gilles Priority: Trivial Fix For: 3.0 The newest (and recommended, I think) way of documenting packages is through package-info.java files. CM still uses package.html files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
