[jira] [Created] (MATH-637) Simple utility for micro-benchmarking
Simple utility for micro-benchmarking - Key: MATH-637 URL: https://issues.apache.org/jira/browse/MATH-637 Project: Commons Math Issue Type: Wish Reporter: Gilles Assignee: Gilles Priority: Minor Fix For: 3.0 As per the discussion on the dev ML (with subject: Simple benchmarking utility), it would be useful to have an easy way to benchmark alternative implementations of some functionality. The proposed utility methods will be collected in a class located in the src/test/java part of the code repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-637) Simple utility for micro-benchmarking
[ https://issues.apache.org/jira/browse/MATH-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073034#comment-13073034 ] Gilles commented on MATH-637: - Initial code committed in revision 1152380. Simple utility for micro-benchmarking - Key: MATH-637 URL: https://issues.apache.org/jira/browse/MATH-637 Project: Commons Math Issue Type: Wish Reporter: Gilles Assignee: Gilles Priority: Minor Labels: test Fix For: 3.0 As per the discussion on the dev ML (with subject: Simple benchmarking utility), it would be useful to have an easy way to benchmark alternative implementations of some functionality. The proposed utility methods will be collected in a class located in the src/test/java part of the code repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-638) instead of in SingularValueDecompositionImpl
instead of in SingularValueDecompositionImpl --- Key: MATH-638 URL: https://issues.apache.org/jira/browse/MATH-638 Project: Commons Math Issue Type: Improvement Reporter: Gilles Assignee: Gilles Priority: Trivial Fix For: 3.0 Findbugs signalled the use of the not short-circuit logical operator . -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-638) instead of in SingularValueDecompositionImpl
[ https://issues.apache.org/jira/browse/MATH-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-638. - Resolution: Fixed Revision 1152462. instead of in SingularValueDecompositionImpl --- Key: MATH-638 URL: https://issues.apache.org/jira/browse/MATH-638 Project: Commons Math Issue Type: Improvement Reporter: Gilles Assignee: Gilles Priority: Trivial Fix For: 3.0 Findbugs signalled the use of the not short-circuit logical operator . -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-637) Simple utility for micro-benchmarking
[ https://issues.apache.org/jira/browse/MATH-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073257#comment-13073257 ] Gilles commented on MATH-637: - Revision 1152524 contains significant changes that aim to thwart some of the criticisms discussed [here|http://blog.juma.me.uk/2011/02/23/performance-of-fastmath-from-commons-math/]. Please review. Simple utility for micro-benchmarking - Key: MATH-637 URL: https://issues.apache.org/jira/browse/MATH-637 Project: Commons Math Issue Type: Wish Reporter: Gilles Assignee: Gilles Priority: Minor Labels: test Fix For: 3.0 As per the discussion on the dev ML (with subject: Simple benchmarking utility), it would be useful to have an easy way to benchmark alternative implementations of some functionality. The proposed utility methods will be collected in a class located in the src/test/java part of the code repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073351#comment-13073351
]
Gilles commented on MATH-621:
-
{quote}
BOBYQAOptimizer - the actual version I use myself - all pointers are replaced
by Java arrays. This version is much easier to read and faster than the old
one.
{quote}
:( It's a pity that you didn't mention this version earlier; I already spent
quite a few hours replacing the ScopedPtr variables. Only a few of them
remains in my working version: namely, those that are created as offsets in w
before calling trsbox, rescue, altmov and update.
Since I also made a few other changes along the way, I don't feel like starting
all (almost) over again...
Hence, I'll continue with my incremental changes; but, at some point, I could
use some help to convert the state machine code into proper function calls.
IMO, we should first arrive at a clearer code before worrying about performance
(the more so that, as you pointed out, this algorithm will probably be put to
use when function evaluation is expensive, overwhelming the optimizer's code
running time).
The refactoring from efficient Fortran to (very probably less efficient) Java
is a big effort but it's indispensable: If it were not to become understandable
and maintainable, I don't see the point in including it in CM; you could just
provide the straight translation in a JAR file and people would use it as a
black box.
BOBYQA is missing in optimization
-
Key: MATH-621
URL: https://issues.apache.org/jira/browse/MATH-621
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dr. Dietmar Wolz
Fix For: 3.0
Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip,
bobyqaoptimizer0.4.zip, bobyqav0.3.zip
Original Estimate: 8h
Remaining Estimate: 8h
During experiments with space flight trajectory optimizations I recently
observed, that the direct optimization algorithm BOBYQA
http://plato.asu.edu/ftp/other_software/bobyqa.zip
from Mike Powell is significantly better than the simple Powell algorithm
already in commons.math. It uses significantly lower function calls and is
more reliable for high dimensional problems. You can replace CMA-ES in many
more application cases by BOBYQA than by the simple Powell optimizer.
I would like to contribute a Java port of the algorithm.
I maintained the structure of the original FORTRAN code, so the
code is fast but not very nice.
License status: Michael Powell has sent the agreement via snail mail
- it hasn't arrived yet.
Progress: The attached patch relative to the trunk contains both the
optimizer and the related unit tests - which are all green now.
Performance:
Performance difference (number of function evaluations)
PowellOptimizer / BOBYQA for different test functions (taken from
the unit test of BOBYQA, dimension=13 for most of the
tests.
Rosen = 9350 / 1283
MinusElli = 118 / 59
Elli = 223 / 58
ElliRotated = 8626 / 1379
Cigar = 353 / 60
TwoAxes = 223 / 66
CigTab = 362 / 60
Sphere = 223 / 58
Tablet = 223 / 58
DiffPow = 421 / 928
SsDiffPow = 614 / 219
Ackley = 757 / 97
Rastrigin = 340 / 64
The number for DiffPow should be dicussed with Michael Powell,
I will send him the details.
Open Problems:
Some checkstyle violations because of the original Fortran source:
- Original method comments were copied - doesn't follow javadoc standard
- Multiple variable declarations in one line as in the original source
- Problems related to goto conversions:
gotos not convertible in loops were transated into a finite automata
(switch statement)
no default in switch
fall through from previos case in switch
which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-637) Simple utility for micro-benchmarking
[ https://issues.apache.org/jira/browse/MATH-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073353#comment-13073353 ] Gilles commented on MATH-637: - Thanks. Applied in revision 1152584. Simple utility for micro-benchmarking - Key: MATH-637 URL: https://issues.apache.org/jira/browse/MATH-637 Project: Commons Math Issue Type: Wish Reporter: Gilles Assignee: Gilles Priority: Minor Labels: test Fix For: 3.0 Attachments: PerfUtils.patch As per the discussion on the dev ML (with subject: Simple benchmarking utility), it would be useful to have an easy way to benchmark alternative implementations of some functionality. The proposed utility methods will be collected in a class located in the src/test/java part of the code repository. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-599) Re-implementation of Secant-based root finding algorithms
[ https://issues.apache.org/jira/browse/MATH-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073393#comment-13073393 ] Gilles commented on MATH-599: - AllowedSolutions changed toAllowedSolution in revision 1152644. Re-implementation of Secant-based root finding algorithms - Key: MATH-599 URL: https://issues.apache.org/jira/browse/MATH-599 Project: Commons Math Issue Type: Improvement Reporter: Dennis Hendriks Labels: documentation, patch Fix For: 3.0 Attachments: secant-based-root-finding-algos.patch, secant-based-root-finding-algos2.patch, secant-based-root-finding-algos2.zip Apache Commons Math currently has a SecantSolver. It is unclear exactly what algorithm this solver implements. It states: The algorithm is modified to maintain bracketing of a root by successive approximations. Because of forced bracketing, convergence may be slower than the unrestricted Secant algorithm. However, this implementation should in general outperform the Regula Falsi method. The Regula Falsi method is exactly the Secant method modified to maintain a bracketed solution. It is therefore unclear what other modifications were done to make it 'better' than the Regula Falsi method. Besides the Secant and Regula Falsi methods, several other Secant-based root-finding algorithms exist, such as the the Illinois method, and the Pegasus method. All 4 are well-known, publisched algorithms. I created a patch, which changes the following: - Removed SecantSolver root-finding algorithm. - Implemented new Secant-based root-finding algorithms: SecantSolver, RegulaFalsiSolver, IllinoisSolver, and PegasusSolver. - Introduced BracketedSolution interface and AllowedSolutions enumeration, to control allowed solutions (under-approximations and over-approximations) for bracketed root-finding algorithms. Implemented for RegulaFalsiSolver, IllinoisSolver, and PegasusSolver. - Fixed documentation of BaseUnivariateRealSolver.solve methods, such that documentation order of arguments matches the order of the actual arguments. Note that the original SecantSolver was removed, and replaced by a root-finding algorithm that actually implements the Secant root-finding algorithm. As such, existing code using the SecantSolver is not backwards compatible. That is, even though the new SecantSolver does implement the same interfaces, the root-finding solutions may differ. In particular, the new SecantSolver does not maintain a bracketed solution, and does not guarantee convergence. I added unit tests, and I did a build, including checkstyle checking. I did not fix all checkstyle warnings though, as I consider some of them false positives. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13076194#comment-13076194
]
Gilles commented on MATH-621:
-
Dietmar,
I think I've come across a bug in function rescue. At line 2443 (of the Java
translation I use for comparison, i.e. the one with ScopedPtr):
{code}
i__2 = ndim;
for (ip = npt; ip = i__2; ip++) {
sum += bmat.get(ip + j * bmat_dim1) * w.get(ip);
}
{code}
Whereas, in the original Fortran code (at line 1544):
{noformat}
DO 220 IP=NPT+1,NDIM
220 SUM=SUM+BMAT(IP,J)*W(IP)
{noformat}
Can you confirm?
If indeed, the loop should start at npt + 1, I've made the change; but tests
still all pass! Does this mean that the one exercising rescue is too lenient?
Trying to remove the w (split work space) from rescue provides many
possibilities for my own mistakes; thus I am a little scared that they would
also go unnoticed...
BOBYQA is missing in optimization
-
Key: MATH-621
URL: https://issues.apache.org/jira/browse/MATH-621
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dr. Dietmar Wolz
Fix For: 3.0
Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip,
bobyqaoptimizer0.4.zip, bobyqav0.3.zip
Original Estimate: 8h
Remaining Estimate: 8h
During experiments with space flight trajectory optimizations I recently
observed, that the direct optimization algorithm BOBYQA
http://plato.asu.edu/ftp/other_software/bobyqa.zip
from Mike Powell is significantly better than the simple Powell algorithm
already in commons.math. It uses significantly lower function calls and is
more reliable for high dimensional problems. You can replace CMA-ES in many
more application cases by BOBYQA than by the simple Powell optimizer.
I would like to contribute a Java port of the algorithm.
I maintained the structure of the original FORTRAN code, so the
code is fast but not very nice.
License status: Michael Powell has sent the agreement via snail mail
- it hasn't arrived yet.
Progress: The attached patch relative to the trunk contains both the
optimizer and the related unit tests - which are all green now.
Performance:
Performance difference (number of function evaluations)
PowellOptimizer / BOBYQA for different test functions (taken from
the unit test of BOBYQA, dimension=13 for most of the
tests.
Rosen = 9350 / 1283
MinusElli = 118 / 59
Elli = 223 / 58
ElliRotated = 8626 / 1379
Cigar = 353 / 60
TwoAxes = 223 / 66
CigTab = 362 / 60
Sphere = 223 / 58
Tablet = 223 / 58
DiffPow = 421 / 928
SsDiffPow = 614 / 219
Ackley = 757 / 97
Rastrigin = 340 / 64
The number for DiffPow should be dicussed with Michael Powell,
I will send him the details.
Open Problems:
Some checkstyle violations because of the original Fortran source:
- Original method comments were copied - doesn't follow javadoc standard
- Multiple variable declarations in one line as in the original source
- Problems related to goto conversions:
gotos not convertible in loops were transated into a finite automata
(switch statement)
no default in switch
fall through from previos case in switch
which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13078485#comment-13078485 ] Gilles commented on MATH-621: - I certainly also would like the code to be *in* CM. If just for the selfish reason that I've been working on the conversion for many days now :p. I don't think that _anyone_ wants it out. However, my view of the CM software library is that it should be a repository of best practices for scientific computing in Java, and not just a toolbox. This implies IMHO that we try our best that the implementations are coded in a proper OO way... That said, I'm a bit dismayed that we don't seem to combine our forces to achieve that goal. I cannot use your new version, and you prefer it to the old one; that is the situation that I wanted to avoid when I proposed to do a first pass on the code before committing it to the repository! Please allow me a few more days to get to a consistent state (e.g. removing the big work space). A that point I propose to # commit your original straight translation as provided in your first patch # commit my current version of that code Then we can use that as a common base to refactor: # Replace the goto/state machine constructs # Use matrix operations (from package linear) whenever possible, in place of the explicit loops I don't quite see what seems to bother you with global variables versus long argument list. One of the problems of the original (Fortran-like) implementation is that many of the function arguments are either * input-output (i.e. they are changed in-place), or * work space The former will be more suitably turned into instance variables, and the latter should become a local variable. I've already started this transformation; it reduces the the length of the argument lists and make the code clearer namely because one will be able to tell which variables are input (function arguments) and which are output (instance variable). The clean, from scratch, implementation is also an option. However, a couple of weeks ago, I had the impression that no one stepped forward to work on it. That's also why I took the pedestrian way, having the feeling that we could slowly but surely (thanks to your reference implementation and unit tests) walk towards the goal of having BOBYQA included in CM before the 3.0 release (while waiting for the best person for the task would seem to make it unlikely). Once the 2 commits I talked about above are done, the code will still be far from my ideal OO but I hope that it will be in a state that will make it more likely that it will evolve towards that ideal. How does that sound? BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13078499#comment-13078499
]
Gilles commented on MATH-621:
-
Another problem: The conditionals, at line 567 and at line 570, are never
entered:
{code}
if (xnew.get(j) == sl.get(j)) {
bdtest = w.get(j);
}
if (xnew.get(j) == su.get(j)) {
bdtest = -w.get(j);
}
{code}
In some sense, it would be fine if they could be removed; because otherwise, in
my converted code, there would the extreme inconvenience that the content of
w is accessed before it is initialized...
BOBYQA is missing in optimization
-
Key: MATH-621
URL: https://issues.apache.org/jira/browse/MATH-621
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dr. Dietmar Wolz
Fix For: 3.0
Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip,
bobyqaoptimizer0.4.zip, bobyqav0.3.zip
Original Estimate: 8h
Remaining Estimate: 8h
During experiments with space flight trajectory optimizations I recently
observed, that the direct optimization algorithm BOBYQA
http://plato.asu.edu/ftp/other_software/bobyqa.zip
from Mike Powell is significantly better than the simple Powell algorithm
already in commons.math. It uses significantly lower function calls and is
more reliable for high dimensional problems. You can replace CMA-ES in many
more application cases by BOBYQA than by the simple Powell optimizer.
I would like to contribute a Java port of the algorithm.
I maintained the structure of the original FORTRAN code, so the
code is fast but not very nice.
License status: Michael Powell has sent the agreement via snail mail
- it hasn't arrived yet.
Progress: The attached patch relative to the trunk contains both the
optimizer and the related unit tests - which are all green now.
Performance:
Performance difference (number of function evaluations)
PowellOptimizer / BOBYQA for different test functions (taken from
the unit test of BOBYQA, dimension=13 for most of the
tests.
Rosen = 9350 / 1283
MinusElli = 118 / 59
Elli = 223 / 58
ElliRotated = 8626 / 1379
Cigar = 353 / 60
TwoAxes = 223 / 66
CigTab = 362 / 60
Sphere = 223 / 58
Tablet = 223 / 58
DiffPow = 421 / 928
SsDiffPow = 614 / 219
Ackley = 757 / 97
Rastrigin = 340 / 64
The number for DiffPow should be dicussed with Michael Powell,
I will send him the details.
Open Problems:
Some checkstyle violations because of the original Fortran source:
- Original method comments were copied - doesn't follow javadoc standard
- Multiple variable declarations in one line as in the original source
- Problems related to goto conversions:
gotos not convertible in loops were transated into a finite automata
(switch statement)
no default in switch
fall through from previos case in switch
which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-581) Support for iterative linear solvers
[ https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080172#comment-13080172 ] Gilles commented on MATH-581: - Exceptions patch applied in revision 1154361. Support for iterative linear solvers Key: MATH-581 URL: https://issues.apache.org/jira/browse/MATH-581 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0, Nightly Builds Reporter: Sébastien Brisard Labels: iterative, linear, solver Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip, MATH-581-04.zip, MATH-581-05.patch, MATH-581-05.patch, conjugate-gradient.zip, exceptions.patch, linearoperator.zip Dear all, this issue has already been discussed on the forum. The idea is to implement the most popular linear iterative solvers (CG, SYMMLQ, etc...) in commons-math. The beauty of these solvers is that they do not need direct access to the coefficients of the matrix, only matrix-vector products are necessary. This is goof, as sometimes it is inetficient to store the coefficients of the matrix. So basically, before implementing the iterative solvers, we need to define an interface slightly more general than a matrix, namely LinearOperator, with only one basic operation: matrix-vector product. Here are a few interfaces and abstract classes that do that. Nothing fancy yet, I just wanted to have you advice on the implementation before I commit some solvers. I thought these classes could go in a package org.apache.commons.math.linearoperator, but really, I haven't got a clue... Best regards, Sebastien -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-581) Support for iterative linear solvers
[
https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080237#comment-13080237
]
Gilles commented on MATH-581:
-
I just had a quick look; here are a few non-exhaustive remarks:
* You should add the license header at the top of all files.
* I'm not fond of keys like theVector, otherOperator. We could name them
according the parameter that triggered the exception e.g. in
{{AbstractPreconditionedIterativeLinearSolver}}: operator_m and operator_a
or just m and a (?).
* Couldn't the instance variables be made final (and assigned in the
constructors)?
* There is a class Incrementor in package util which should be used to
count things (e.g. iterations).
* If possible, I'd avoid cyclic references:
{code}
public void setMonitor(final AbstractIterativeLinearSolverMonitor monitor) {
this.monitor = monitor;
monitor.setSolver(this);
}
{code}
Also, you don't check that {{monitor}} is not null.
* Is a separate monitor class really necessary? Couldn't the monitoring be
part of {{AbstractIterativeLinearSolver}}, e.g. through a shouldStop abstract
method?
* {{StoppingCriterion2}} is an odd name if there isn't yet a
StoppingCriterion class. Are there other monitor types?
Support for iterative linear solvers
Key: MATH-581
URL: https://issues.apache.org/jira/browse/MATH-581
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0, Nightly Builds
Reporter: Sébastien Brisard
Labels: iterative, linear, solver
Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip,
MATH-581-04.zip, MATH-581-05.patch, MATH-581-05.patch,
conjugate-gradient.zip, exceptions.patch, linearoperator.zip
Dear all,
this issue has already been discussed on the forum. The idea is to implement
the most popular linear iterative solvers (CG, SYMMLQ, etc...) in
commons-math. The beauty of these solvers is that they do not need direct
access to the coefficients of the matrix, only matrix-vector products are
necessary. This is goof, as sometimes it is inetficient to store the
coefficients of the matrix.
So basically, before implementing the iterative solvers, we need to define an
interface slightly more general than a matrix, namely LinearOperator, with
only one basic operation: matrix-vector product.
Here are a few interfaces and abstract classes that do that. Nothing fancy
yet, I just wanted to have you advice on the implementation before I commit
some solvers.
I thought these classes could go in a package
org.apache.commons.math.linearoperator, but really, I haven't got a clue...
Best regards,
Sebastien
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-632) NaN: Method equals in Complex not consistent with == for double primitive type
[
https://issues.apache.org/jira/browse/MATH-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-632.
-
Resolution: Not A Problem
Clarifying note added in revision 1154392.
NaN: Method equals in Complex not consistent with == for double
primitive type
Key: MATH-632
URL: https://issues.apache.org/jira/browse/MATH-632
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Priority: Minor
Fix For: 3.0
The following tests show several contradictions:
{code}
final double a = Double.NaN;
final double b = Double.NaN;
Assert.assertFalse(a == b, a == b); // (1)
Assert.assertEquals(a != b, a, b, Double.MIN_VALUE); // (2)
Assert.assertFalse(a == b, MathUtils.equals(a, b, Double.MIN_VALUE)); // (3)
Assert.assertFalse(a == b, MathUtils.equals(a, b, Double.MIN_VALUE)); // (4)
final Double dA = Double.valueOf(a);
final Double dB = Double.valueOf(b);
Assert.assertFalse(dA == dB, dA.doubleValue() == dB.doubleValue()); // (5)
Assert.assertTrue(!dA.equals(dB), dA.equals(dB)); // (6)
final Complex cA = new Complex(a, 0);
final Complex cB = new Complex(b, 0);
Assert.assertTrue(!cA.equals(cB), cA.equals(cB)); // (7)
{code}
They all pass; thus:
# Double does not behave as double: (1) and (5) vs (6)
# Two NaNs are almost equal for Junit: (2)
# Two NaNs are never equal for MathUtils: (3) and (4)
# Complex.NaN is consistent with Object Double.valueOf(NaN) (hence not with
primitive Double.NaN): (7)
This is quite confusing.
In MathUtils, we chose to follow IEEE754 (and Java for primitive double),
i.e. it is correct that assertion (1) is false. Do we want Complex to
conform with this or with the inconsistent behaviour of Double?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-581) Support for iterative linear solvers
[
https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080395#comment-13080395
]
Gilles commented on MATH-581:
-
About the usage of the {{ExceptionContext}}, could you start a thread on the
ML? Maybe someone will have a good idea. One of the issue is that the keys
should preferably make sense from the viewpoint of the caller. Hence, as you
said, name like m and a could be confusing, since they are the parameter
names (in the method definition) and not the argument names (as passed by the
caller).
{quote}
[...] Sorry to waste your time here.
{quote}
Don't apologize; I knew that the comment was lacking... ;)
The idea is that, in general, code is easier to understand (and safer and more
efficient) when as many variables as possible are actually constant
(initialized in the constructor). I think that it's really worth trying to
design classes that are immutable. Of course, this has consequences on the
interactions between classes.
This design issue is also related to the other points: cyclic references and
the role of the monitor. Unfortunately, I didn't look at the details of yours
classes's relationships, so it's difficult to come up with a concrete
application to this case.
However, one question arises from your previous comment: You use the monitor
to
* monitor the computation (for plotting, making backup, ...)
* check the convergence of the algorithm
I'm uncomfortable with these 2 very different things being clumped into one
class, itself being tied to a particular set of classes in a particular package.
Monitoring is a feature that would be useful in many other areas (classes). And
we should not have to re-implement similar thing in each of them. E.g. there
was the same wish from the contributor of the CMA-ES optimizer implementation.
In my opinion, this is also a kind of (advanced) logging, which I'm all for
introducing in CM. However, this would imply an external library dependency,
which is frowned upon by others.
On the other hand, checking for convergence is an integral part of the
algorithm.
There was a similar discussion concerning optimizers (see classes in
optimization package): There, the monitor is called ConvergenceChecker:
It might well be that you could reuse it here. It was also the result of a
compromise between an obvious stopping criterion (usually tightly linked to
the algorithm) and the potential need for user-defined special criteria
(probably like the tensor condition you evoked).
Concerning the {{StoppingCriterion2}}, I had understood that you were copying
the name from somewhere, but it nevertheless does not mean anything. At best,
it could be used for a private inner class, renamed as
DefaultStoppingCriterion. In books, for pedagogical purposes, they could use
a list of things to demonstrate increasingly better alternatives (I don't know
if that's the case here): so you could have had BadStoppingCriterion and then
GoodStoppingCriterion, which, out of context, would not have made more
sense... :)
Support for iterative linear solvers
Key: MATH-581
URL: https://issues.apache.org/jira/browse/MATH-581
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0, Nightly Builds
Reporter: Sébastien Brisard
Labels: iterative, linear, solver
Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip,
MATH-581-04.zip, MATH-581-05.patch, MATH-581-05.patch,
conjugate-gradient.zip, exceptions.patch, linearoperator.zip
Dear all,
this issue has already been discussed on the forum. The idea is to implement
the most popular linear iterative solvers (CG, SYMMLQ, etc...) in
commons-math. The beauty of these solvers is that they do not need direct
access to the coefficients of the matrix, only matrix-vector products are
necessary. This is goof, as sometimes it is inetficient to store the
coefficients of the matrix.
So basically, before implementing the iterative solvers, we need to define an
interface slightly more general than a matrix, namely LinearOperator, with
only one basic operation: matrix-vector product.
Here are a few interfaces and abstract classes that do that. Nothing fancy
yet, I just wanted to have you advice on the implementation before I commit
some solvers.
I thought these classes could go in a package
org.apache.commons.math.linearoperator, but really, I haven't got a clue...
Best regards,
Sebastien
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080424#comment-13080424 ] Gilles commented on MATH-621: - Original version (with ScopedPtr variables) committed in revision 1154543. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080478#comment-13080478
]
Gilles commented on MATH-631:
-
The problem was due to the fact that at some point, the update formula always
gave the same value: Nothing was being updated and the loop went on until the
number of evaluations was exhausted.
I've committed a tentative solution in revision 1154614.
However:
# I'm not sure that it doesn't have any adverse side-effects on the bracketing
property.
# It is quite probably not a pristine regula falsi algorithm anymore.
Please review.
Anyways, for the function that triggered the problem (see testIssue631 in
RegulaFalsiSolverTest.java), the (modified) {{RegulaFalsiSolver}} takes 3624
evaluations (versus 17 for {{PegasusSolver}}). We should probably add a word of
warning in the class Javadoc.
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-643) Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and mapAddToSelf(...) to ebeAddToSelf(...) for instance
[
https://issues.apache.org/jira/browse/MATH-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080602#comment-13080602
]
Gilles commented on MATH-643:
-
If ebe is for element-by-element, what would be the second element in
{code}
RealVector mapAdd(double d);
{code}
?
Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and
mapAddToSelf(...) to ebeAddToSelf(...) for instance
-
Key: MATH-643
URL: https://issues.apache.org/jira/browse/MATH-643
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Arne Plöse
Priority: Minor
I think the map* methods have historical names. Today I would prefer ebe as
prefix like ebeMultiply(...).
This would describe the methods better from a users view.
If this is a valid issue, I could provide a patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080608#comment-13080608
]
Gilles commented on MATH-631:
-
(which is difficult to see as you also change other things in the same commit)
Sorry, but I didn't hit the solution right away, i.e. before changing those two
additional little things to make the code clearer (for me)...
The only actual change is that the {{REGULA_FALSI}} enum was not used (i.e.
with the {{switch}} little change, the corresponding {{case}} would have been
empty) whereas now it contains the update of x0 to avoid an infinite loop.
The other (cosmetic) change was to take these two statements
{code}
x1 = x;
f1 = fx;
{code}
out of the previous {{if}} and {{else}} blocks, as they were duplicated there
(which made me wonder whether it was a bug that they were _not_ different).
You say
[...] convergence is guaranteed [...]
[...] it converges very slowly for certain problems, [...]
[...] The limited convergence of the algorithm is a property of the
algorithm, [...]
All the above imply that one expects that the algorithm _can_ find the solution.
However, in this implementation, it _can't_.
Therefore there is a bug, somewhere.
I agree that it is a limitation of double precision. But, IMHO, leaving the
code as-is is not a good idea because because it leads to the impression that
the Regula Falsi mathematical algorithm can fail to converge, which is not
correct (IIUC).
Therefore, we could add a comment stating that the _implementation_ with
limited precision can fail to converge but that would be akin to saying to
users: Here is a code, but don't use it.
Personally, I would prefer to say: Because of limited precision, the
implementation can fail to converge. In those cases, we slightly modified the
original algorithm in order to avoid failure.
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080641#comment-13080641
]
Gilles commented on MATH-631:
-
fails to converge and large number of iteration to converge are completely
different things.
The documentation says: convergence is guaranteed. Is _that_ false?
Moreover, for the function reported in this issue, the problem is not that it
takes a large number iterations, it is that the loop is _literally_ infinite
because at some point, nothing changes anymore.
Stated otherwise: If implemented with larger/infinite precision, would it
converge?
In the affirmative, then in my opinion it means that the plain Regula Falsi
method cannot be implemented with double precision (or that its convergence
properties are not as stated in the docs) or that there is a bug in the
implementation.
In the former case, why keep something that will never be used (as we'll warn
users that they should use Pegasus or Illinois but certainly not
RegulaFalsi)? IMHO, we could just state in the docs that RegulaFalsi was
not implemented because it is demonstrably less efficient and sometimes fails
to work.
A less radical alternative would be to keep the test I've inserted in the code
(at line 186) and throw a {{MathIllegalStateException}} if it passes. The
previous behaviour (infinite loop) is a bug in CM.
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-643) Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and mapAddToSelf(...) to ebeAddToSelf(...) for instance
[ https://issues.apache.org/jira/browse/MATH-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080660#comment-13080660 ] Gilles commented on MATH-643: - ad d to all elemnets of this This is correct. aka. add d element-by-element Sorry, I think that this does not mean anything. map is misleading This name is used in many languages. It means apply the operation to each element. use ebe As noted already, this is not the same: It means apply the operation to each pair of elements. drop the prefix entirely. This is incorrect in some cases. What would mean adding a number to an array? Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and mapAddToSelf(...) to ebeAddToSelf(...) for instance - Key: MATH-643 URL: https://issues.apache.org/jira/browse/MATH-643 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Arne Plöse Priority: Minor I think the map* methods have historical names. Today I would prefer ebe as prefix like ebeMultiply(...). This would describe the methods better from a users view. If this is a valid issue, I could provide a patch. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080675#comment-13080675
]
Gilles commented on MATH-631:
-
I understand what you say. But however you put it, there is a bug; if not in
the implementation, then in the API. It is not expected behaviour that
something which must be changed (function accuracy threshold) to ensure correct
behaviour (avoid an undetected infinite loop) is not a mandatory parameter.
To debug this, I started by raising the absolute accuracy threshold (the first
default parameter, thus the first obvious thing to do) to 1e-2 and was stunned
that I couldn't get anything after 100 iterations!
Therefore I maintain that, at a minimum, we put a line that will detect the
infinite loop and raise an exception identifying _that_ problem and not let the
user wait for TooManyEvaluationsException to be raised, as that will induce
the unaware (me) to just allow more evaluations and try again.
This solution does not corrupt the algorithm; it just adds protection.
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080689#comment-13080689
]
Gilles commented on MATH-631:
-
How can it be correct to have an infinite loop?
The problem is not slow convergence, which you can overcome by allowing more
iterations.
It is too low function value accuracy which you cannot overcome by allowing
more iterations. Thus my point: We must raise the appropriate exception (the
doc for which will state that it can happen if the function value accuracy is
too low for the implementation to provide a result).
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080690#comment-13080690
]
Gilles commented on MATH-631:
-
[My comment starting with I understand what you say. was an answer to Luc. I
hadn't read Phil's previous one which was posted while I was writing mine.]
I agree that it is better not to change the standard algorithm, as I indicated
in my first comment.
The fix which I'm proposing is not an algorithm change, it is an implementation
detail similar to the many hundreds checks performed in CM. Just it is not a
precondition test. It adequately indicates that something went wrong and can
help the user figure out what it was. It makes the implementation more robust.
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080695#comment-13080695
]
Gilles commented on MATH-631:
-
The original implementation, for the problem instance being examined here,
would find the root with absolute accuracy lower than *10e-12* after 3560
evaluations (note: using the default value of *1e-6*).
In fact, the root was found, at the required accuracy, after around 2200
evaluations.
That does not sound like correct behavior.
The problem is that, x0 never being updated, the convergence test always
fails... until we reach the limitation of double precision, which entails an
infinite loop.
In fact my fix should not be necessary, as things have gone awry before it
would apply, but there is a bug to fix nonetheless.
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080792#comment-13080792
]
Gilles commented on MATH-631:
-
I surely hope that your last post is not an answer to mine from 23:46.
I'll try to answer here in case it was in reply to my previous one (23:06).
Of course, the code will not run forever because of the maxeval bound.
But it will run for a time that depends on the value of maxeval *with no
added benefit*! From a certain point, the loop is like
{code}
while (true) {
// Do nothing useful, just count!
++count;
if (count maxeval) {
throw new TooManyEvalutationsException(maxeval);
}
}
{code}
{quote}
from a style perspective, I prefer to explicitly bound loops
{quote}
From an *OO* style perspective, the reuse of the Incrementor is better, and
you don't have to rewrite the same test and throw exception if failed boiler
plate code each time there is such a loop.
{quote}
Trying to detect when a sequence of iterates has gotten stuck and is destined
to hit max iterations without converging is walking down a path that I think is
unwise for us and users.
{quote}
Why?
{quote}
I see no reason not to stick with the standard impl here
{quote}
A busy idle loop is a compelling reason IMO.
{quote}
Trying to workaround numerical problems in simple algorithms and change
contracts to include these workarounds is asking for trouble
{quote}
The trouble is there with the current implementation. I'm not criticizing the
contribution but this issue shows that it should be made more robust.
Also, the documentation about convergence is guaranteed can lead to a false
sense of security.
Moreover, is the regula falsi a mathematical algorithm (with a guaranteed
converge property if computed with infinite precision) or a numerical one,
which this issue proves that it cannot guarantee convergence? In the former
case, CM's (numerical) implementation is not strictly regula falsi and there
would be no such thing as respect for an original/standard implementation if we
can make it more robust.
I've already indicated that the fix does *not* change the contract; it stops
the busy idle loop as soon as it is detected and reports that it won't do any
good to increase the number of iterations. That's _obviously_ more robust.
Now, if you were answering to my 23:46 post, I'd be glad to read an explanation
of why the first paragraph describes expected behaviour.
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-643) Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and mapAddToSelf(...) to ebeAddToSelf(...) for instance
[
https://issues.apache.org/jira/browse/MATH-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080797#comment-13080797
]
Gilles commented on MATH-643:
-
In Perl, the output of
{code}
@a = (1, 2, 3);
print @a + 6;
{code}
is
{noformat}
9
{noformat}
while
{code}
@a = (1, 2, 3);
@a = map {$_ + 6} @a;
print join(,, @a);
{code}
will print
{noformat}
7,8,9
{noformat}
So? ;)
Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and
mapAddToSelf(...) to ebeAddToSelf(...) for instance
-
Key: MATH-643
URL: https://issues.apache.org/jira/browse/MATH-643
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Arne Plöse
Priority: Minor
I think the map* methods have historical names. Today I would prefer ebe as
prefix like ebeMultiply(...).
This would describe the methods better from a users view.
If this is a valid issue, I could provide a patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080873#comment-13080873
]
Gilles commented on MATH-631:
-
{quote}
I think we should completely get rid of regula falsi and only keep the better
algorithms.
{quote}
That was my first idea. And that would be the simplest one, the safest one, and
the only viable one as I can't seem to state clearly enough that
* Problem 1: When the doc says guaranteed convergence, the algorithm should
provide the answer.
* Problem 2: When the (absolute) accuracy threshold is set to 1e-6, and the
correct root *is* found (after 2200 iterations) within the requirements, it
should be returned, instead running idle and finish with an exception
{quote}
The reason why we get stuck is irrelevant.
{quote}
But why? If we *can* be more precise on the cause of failure, why not do it?
{quote}
This limit is simply a safety limit, not a tuning parameter that user are
expected to raise once they hit it hoping they will converge later on.
{quote}
In principle, some possible use would be to compare the efficiency of different
methods where the main criterion would be a time limitation (assuming that the
function evaluation time overwhelms the of the root solver algorithm time).
Thus with the function that triggered this issue:
* If you set maxeval to 3000, then both Pegasus (17 evals) and (a fixed)
RegulaFalsi (2200 evals) would fill the bill.
* If you set maxeval to 1000, then Pegasus will be the only winner.
Anyways:
+1 for removing it altogether, and include somewhere the reason for it not
being implemented in CM.
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-581) Support for iterative linear solvers
[
https://issues.apache.org/jira/browse/MATH-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080954#comment-13080954
]
Gilles commented on MATH-581:
-
{quote}
The problem is both solver and monitor need to know about the other.
{quote}
In your design, yes. My proposal in to change it so that the solver will pass
the necessary information to the Monitor, akin to what is done in the
optimizers + {{ConvergenceChecker}}.
The monitor should not be able to alter the state of the solver.
At least, that is for the checking part which IMO should be a separate and
quite small class.
For the real monitor part, you should really start a thread on the ML. I
would be against the multiple special-purpose monitors tied to a specific
algorithm. We must think of something generally applicable to all CM. That
won't be trivial, and I'd leave that part out of the code which you are
currently designing.
An alternative to using classes from awt or swing, there is the
{{java.util.Observable}} class which might be the basis for a CM monitoring
feature.
{quote}
Some convergence checks only require the last iteration,
{quote}
Nothing forces you to use both arguments!
It would be beneficial that we find some common ground for checking convergence
in different areas of CM. Maybe that from the point-of-view of iterative
solvers, we can modify {{ConvergenceChecker}} so that it will become more
flexible (i.e. applicable to both areas). Please post a message on the ML
exposing your requirements and how {{ConvergenceChecker}} should be changed to
fulfill them.
{quote}
Immutability. I guess that what you would like to have [...]
{quote}
Actually, no. The main issue is how to best separate the attributes of the
algorithm from attributes of the data. Admittedly, there is a lot of
subjectivity here. For example, see the current implementation of the root
solvers (which itself was refactored to look like what was done for the
optimizers).
So, in your case, a wild guess would be:
{code}
final IterativeLinearSolver solver = new ConjugateGradient(monitor);
xx = solver.solve(a, b, x, true);
{code}
Thus the ConjugateGradient instance is reusable: You don't need a new
instance to solve different problems, represented by different input data. But
I would associate the checker with the algorithm.
There is no clear-cut line; IMO, it must be a compromise between full
procedural style (everything passed to the method) and full OO (but not
necessarily good OO) style (everything passed to the constructors or through
setters).
Support for iterative linear solvers
Key: MATH-581
URL: https://issues.apache.org/jira/browse/MATH-581
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0, Nightly Builds
Reporter: Sébastien Brisard
Labels: iterative, linear, solver
Attachments: MATH-581-01.patch, MATH-581-02.zip, MATH-581-03.zip,
MATH-581-04.zip, MATH-581-05.patch, MATH-581-05.patch,
conjugate-gradient.zip, exceptions.patch, linearoperator.zip
Dear all,
this issue has already been discussed on the forum. The idea is to implement
the most popular linear iterative solvers (CG, SYMMLQ, etc...) in
commons-math. The beauty of these solvers is that they do not need direct
access to the coefficients of the matrix, only matrix-vector products are
necessary. This is goof, as sometimes it is inetficient to store the
coefficients of the matrix.
So basically, before implementing the iterative solvers, we need to define an
interface slightly more general than a matrix, namely LinearOperator, with
only one basic operation: matrix-vector product.
Here are a few interfaces and abstract classes that do that. Nothing fancy
yet, I just wanted to have you advice on the implementation before I commit
some solvers.
I thought these classes could go in a package
org.apache.commons.math.linearoperator, but really, I haven't got a clue...
Best regards,
Sebastien
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13081150#comment-13081150
]
Gilles commented on MATH-631:
-
May I please know *why it is OK that a bit of code does loop counting and
repeatedly computes the same thing*!
You insist that I'd be hacking whereas I've indicated 3 or 4 times that there
is no hack: just a test that will exit the loop as soon as it detects that the
algorithm has failed. Why is it not understandable that the busy loop could
last for a long time? The function is potentially evaluated millions of times
at the same point. What if the evaluation is costly? Imagine the computation
running for days, only to discover that it could have been be stopped after a
few seconds. Is that robust code and good advertising for a library? It is one
thing to expect that there are unknown bugs in CM, but refusing to fix a known
one is so obviously wrong...
And may I please know *why it is OK that an algorithm that finds the right
result does not return it*.
I had been trying to provide alternatives to the removal, but I can't do much
more if nobody answers the above two questions.
You just have to run the code and print x and x1 to see what is going on!
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13081180#comment-13081180
]
Gilles commented on MATH-631:
-
{quote}
So the function is called millions of time only if the users wishes so by
setting the maxEvaluations to
a number in the range of millions.
{quote}
No, the user should not expect that any algorithm will go on a single iteration
more than necessary.
This is a plain bug.
Why do you see that a test such as I proposed (exit the loop early) is wrong
while CM (and any good program) is full of tests to ensure that you don't do
useless computations?
This has nothing to do with regula falsi, it is robustness in the face of
limited precision.
However, if you insist that the bug (failing to detect that it is stuck) is
really an integral part of the algorithm, then removing it is not a pathetic
compromise, it is the only right thing to do!
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13081242#comment-13081242
]
Gilles commented on MATH-631:
-
{quote}
Gilles, you obviously don't share the views that Luc and I have on implementing
standard algorithms
{quote}
That's simply _not true_.
I was the one pointing out that standard algorithms should have precedence:
Please recall that it was considered fine that Levenberg-Marquardt and
Brent would be, unknowingly to the user, twisted to perform _non-standard_
convergences check.
In those cases, there was the risk that the result of the algorithm would not
be the same as the reference implementation.
In this case, there is no such thing as deviating from standard numerics! It
was just a matter of throwing the right exception. So: The algorithm fails?
Let's tell it sooner rather than later.
Very interesting question that you ask: what it means to implement the
algorithm. But please note that I asked it several posts ago[1], and an answer
would have helped sort out this discussion. What is your definition?
[1] 08/Aug/11 07:24
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-643) Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and mapAddToSelf(...) to ebeAddToSelf(...) for instance
[
https://issues.apache.org/jira/browse/MATH-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13081273#comment-13081273
]
Gilles commented on MATH-643:
-
{quote}
[...] mapAdd(double d) is a simple addition of d to each element of the vector
- I would say name this mapping is wrong in this case.
{quote}
It is exactly the Perl definition which you quoted earlier:
{quote}
[...] says that map evaluates a BLOCK or EXPR given to map
{quote}
{noformat}
PerlJava
map {$_ + d } @v v.mapAdd(d)
{noformat}
Sorry, but I don't understand what is your problem with this.
Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and
mapAddToSelf(...) to ebeAddToSelf(...) for instance
-
Key: MATH-643
URL: https://issues.apache.org/jira/browse/MATH-643
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Arne Plöse
Priority: Minor
I think the map* methods have historical names. Today I would prefer ebe as
prefix like ebeMultiply(...).
This would describe the methods better from a users view.
If this is a valid issue, I could provide a patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-643) Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and mapAddToSelf(...) to ebeAddToSelf(...) for instance
[
https://issues.apache.org/jira/browse/MATH-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13081521#comment-13081521
]
Gilles commented on MATH-643:
-
{quote}
Nevertheless I think usability suffers from this non consistent naming.
{quote}
Then, please open a discussion on the dev ML. You should probably include the
various inconsistent namings and make a summary list of all the methods in each
set. This will hopefully make the point clear to everyone, in order to decide
what to change and how. Thanks.
Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and
mapAddToSelf(...) to ebeAddToSelf(...) for instance
-
Key: MATH-643
URL: https://issues.apache.org/jira/browse/MATH-643
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Arne Plöse
Priority: Minor
I think the map* methods have historical names. Today I would prefer ebe as
prefix like ebeMultiply(...).
This would describe the methods better from a users view.
If this is a valid issue, I could provide a patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13081633#comment-13081633
]
Gilles commented on MATH-631:
-
Also:
Phil,
Could you please leave out dismissive qualifiers such as pointless and
pathetic (and, elsewhere, silly) and stick to more or less objective
arguments?
That will certainly help keep the conversation tone to a courteous level.
Luc,
Thanks for stating in full details what you meant by convergence in this
case. However, it is still a post-mortem description.
Do you really expect that the average user of the CM library (a.o. me and the
original reporter of the issue) to be able to figure out that obvious
explanation just by getting a TooManyEvalutationsException, setting the
along-x accuracy threshold to a ridiculously high value and still getting the
same exception?
If just for educational purposes, don't you think that it is more instructive
to get a specific hint that the algorithm is stuck, rather than hit the
ultimate fail-safe barrier much much later, and then download the source code
and sprinkle the code with println statements to do forensic analysis?
Phil,
I tried to handle this issue out of respect for a real user who reported an
issue that would have looked suspicious to many CM users. [How many of them
would be experts in numerical analysis?]
You do not do me a favour by removing this algorithm; I don't want it to be a
_compromise_ (pathetic or not). If you prefer to keep it, I don't care anymore.
But, in that case, _you_ should have answered to Axel Kramer to go and read
some books on numerical analysis.
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-625) rename SparseRealVectorTest to OpenMapRealMatrixTest
[
https://issues.apache.org/jira/browse/MATH-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082302#comment-13082302
]
Gilles commented on MATH-625:
-
IIUC, the possible evolution which you suggest would indeed lead to having
{noformat}
SparseXxxAbstractTest
OpenMapXxxTest extends SparseXxxAbstractTest
SomeOtherSparseImplXxxTest extends SparseXxxAbstractTest
{noformat}
where OpenMapXxxTest in effect contains most of what is in the current
SparseXxxTest.
I think that there is some logic in making the change. I mean the full one,
i.e. move the generic test code into abstract classes and create concrete ones
for the OpenMapXxx implementations.
Anyways, the decision can be postponed to 3.1.
rename SparseRealVectorTest to OpenMapRealMatrixTest
Key: MATH-625
URL: https://issues.apache.org/jira/browse/MATH-625
Project: Commons Math
Issue Type: Wish
Affects Versions: 3.0
Reporter: Arne Plöse
Priority: Trivial
rename all Sparse(Real|Field)(Matrix|Vector)Test classes to
OPenMap(Real|Field)(Matrix|Vector)Test
because OpenMap* is what they really test.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-597) Improvement of sampling random exponential variables
[ https://issues.apache.org/jira/browse/MATH-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082321#comment-13082321 ] Gilles commented on MATH-597: - 2.2 cannot be fixed, since it was released ;) Improvement of sampling random exponential variables Key: MATH-597 URL: https://issues.apache.org/jira/browse/MATH-597 Project: Commons Math Issue Type: Improvement Reporter: Mikkel Meyer Andersen Assignee: Mikkel Meyer Andersen Priority: Minor Labels: Exponential, Random Fix For: 2.2, 3.0 Attachments: MATH597-1.patch, MATH597-2.patch Original Estimate: 4m Remaining Estimate: 4m -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-614) toString method for Complex
[ https://issues.apache.org/jira/browse/MATH-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082323#comment-13082323 ] Gilles commented on MATH-614: - We could wait a few more days. If the contenders do not bring the issue on the ML, I'll resolve it next week... toString method for Complex --- Key: MATH-614 URL: https://issues.apache.org/jira/browse/MATH-614 Project: Commons Math Issue Type: Wish Reporter: Gilles Assignee: Gilles Priority: Trivial Fix For: 3.0 Attachments: math.patch Class Complex (in package complex) lacks a toString() method. [Request from Arne Ploese on the dev ML.] I also propose to slightly modify the format method in ComplexFormat so that the stringified version of Complex(1, 1) is 1 + i instead of 1 + 1i. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082361#comment-13082361
]
Gilles commented on MATH-621:
-
Hello Dietmar.
{quote}
Of course I didn't expect
that you restart from scratch, but that we somehow integrate what we have done
so far.
{quote}
But I did not restart from scratch; I used your Java translation and went from
there!
In fact, it looks like I used the original Fortran because I indeed did
transform the ScopedPtr that were inherently bi-dimensional (i.e. matrices
like bmat and zmat) into (new auxiliary) FortranMatrix objects.
It was only when I checked for the bug in rescue that I looked into the
original Fortran, and discovered that it was using matrices! I still don't
understand why they were translated into 1-d arrays in your code...
{quote}
Question is now: should we really go to CM matrices in one step, or use 0-based
Arrays as an intermediate step? I could for instance use your code as a basis
and try
to come up with an 0-based equivalent as an intermediate step. What do you
think?
{quote}
Going to 0-based loops and replace FortranArray and FortranMatrix with
their CM-equivalent (ArrayRealVector and Array2DRowRealMatrix), which are
0-based, can only be done in one step, if I'm not mistaken.
I've started to write a script that would do the translation of everything that
can be spotted automatically i.e. construct like
{code}
for (int i = 1; i n; i++)
{code}
and
{code}
zmat.getEntry(2, j)
{code}
and
{code}
FortranArray glag = new FortranArray(n);
{code}
etc.
But there are some contructs that must be changed concomitantly (like some test
on array bounds in prelim) and cannot be done automatically. I also suspect
that some simplification could be done there because of the use of a variable
containing the number of evaluations + 1. Unfortunately, my first attempt was
not successful :(
So, what I suggest is that
* I finish my (Perl) script; I'll test that it makes all the intended
replacements (but obviously the resulting code will not pass the tests anymore
until all the non-trivial replacements have been correctly performed).
* I'll post it here so that you can run it on your working copy
* you could then attempt to perform the rest of the 1-based to 0-based
conversion.
Once we are left with ArrayRealVector and Array2DRowRealMatrix, we can see
whether some of the explicit loops can replaced by matrix operation methods
from CM's RealMatrix interface.
After this low-level clean-up we can discuss how to introduce the bounded
optimization concept into the CM API (I've already marked the code with XXX
to that purpose).
Concurrently to the preceding point, it would be nice to gradually tackle the
goto problem.
What do you think?
BOBYQA is missing in optimization
-
Key: MATH-621
URL: https://issues.apache.org/jira/browse/MATH-621
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dr. Dietmar Wolz
Fix For: 3.0
Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip,
bobyqaoptimizer0.4.zip, bobyqav0.3.zip
Original Estimate: 8h
Remaining Estimate: 8h
During experiments with space flight trajectory optimizations I recently
observed, that the direct optimization algorithm BOBYQA
http://plato.asu.edu/ftp/other_software/bobyqa.zip
from Mike Powell is significantly better than the simple Powell algorithm
already in commons.math. It uses significantly lower function calls and is
more reliable for high dimensional problems. You can replace CMA-ES in many
more application cases by BOBYQA than by the simple Powell optimizer.
I would like to contribute a Java port of the algorithm.
I maintained the structure of the original FORTRAN code, so the
code is fast but not very nice.
License status: Michael Powell has sent the agreement via snail mail
- it hasn't arrived yet.
Progress: The attached patch relative to the trunk contains both the
optimizer and the related unit tests - which are all green now.
Performance:
Performance difference (number of function evaluations)
PowellOptimizer / BOBYQA for different test functions (taken from
the unit test of BOBYQA, dimension=13 for most of the
tests.
Rosen = 9350 / 1283
MinusElli = 118 / 59
Elli = 223 / 58
ElliRotated = 8626 / 1379
Cigar = 353 / 60
TwoAxes = 223 / 66
CigTab = 362 / 60
Sphere = 223 / 58
Tablet = 223 / 58
DiffPow = 421 / 928
SsDiffPow = 614 / 219
Ackley = 757 / 97
Rastrigin = 340 / 64
The number for DiffPow should be dicussed with Michael Powell,
I will send him the details.
Open Problems:
Some checkstyle violations because of the original Fortran source:
- Original method comments were copied - doesn't follow javadoc standard
- Multiple variable declarations in one line as in the
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084242#comment-13084242
]
Gilles commented on MATH-631:
-
Thanks for the neat summary!
{quote}
* (1) Revert part of 1154614, so get the original algorithm back. The other
changes of that commit, that don't change the actual algorith, can stay.
{quote}
Done in revision 1157185.
{quote}
* (2) If we keep the algorithm, earlier detection would be nice. Not sure which
exception to throw in these cases.
** This would result in a single 'if' that detects that the new approximation
is the same as the previous one, and we thus no longer make progress, in which
case we throw the exception earlier, instead of later.
{quote}
+1 (my position in the 07/Aug/11 20:28 post)
As suggested there, the exception could be MathIllegalStateException but with
a clear message stating that the algorithm is stuck. Or maybe a new subclass of
it which we could call NumericalPrecisionException or even a general-purpose
ImplementationException.
{quote}
[...] all 3 documentation extensions would be a good idea.
{quote}
+1
About the new issue, the message string:
{quote}
illegal state: maximal count (100) exceeded: evaluations
{quote}
contains everything:
# error type: illegal state
# failure description: maximal count (100) exceeded
# context: evaluations
I proposed to use this approach (combining message items with the addMessage
method of ExceptionContext) in order to reduce the number of messages in the
LocalizedFormats enum. Too many of them are just slight variations on a same
theme.
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-602) Inverse condition number
[ https://issues.apache.org/jira/browse/MATH-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084251#comment-13084251 ] Gilles commented on MATH-602: - Could you possibly write a unit test for the new method? Inverse condition number Key: MATH-602 URL: https://issues.apache.org/jira/browse/MATH-602 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Environment: All Reporter: greg sterijevski Priority: Minor Labels: Condition, Inverse, Number Fix For: 3.0 Attachments: svdinvcond Original Estimate: 1h Remaining Estimate: 1h In SingularValueDecompositionImpl, the condition number is given as the ratio of the largest singular value to the smallest singular value. While this is the correct calculation, because of concerns over rank deficiency, researchers have traditionally used the inverse of the condition number as a more stable indicator of rank deficiency. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084473#comment-13084473
]
Gilles commented on MATH-631:
-
Yes. In the file LocalizedFormats.java, I've started to write
{noformat}
/* keep */
{noformat}
after each enum that is supposedly to be kept. All the others are still to be
examined for redundancy with another one, or the possibility to create
something close using the multi-item approach.
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-601) SingularValueDecompositionImpl psuedoinverse is not consistent with Rank calculation
[
https://issues.apache.org/jira/browse/MATH-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084559#comment-13084559
]
Gilles commented on MATH-601:
-
Also changed max(m, n) to m in accordance with Greg's remark on the dev
ML for other such occurrences (revision 1157342).
SingularValueDecompositionImpl psuedoinverse is not consistent with Rank
calculation
Key: MATH-601
URL: https://issues.apache.org/jira/browse/MATH-601
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.2
Environment: All
Reporter: greg sterijevski
Assignee: Phil Steitz
Labels: Pseudoinverse
Fix For: 3.0
Attachments: SingularValueDecompositionImpl.patch
Original Estimate: 24h
Remaining Estimate: 24h
In the SingularValueDecompositionImpl's internal private class Solver, a
pseudo inverse matrix is calculated:
In lines 2600-264 we have:
if (singularValues[i] 0) {
a = 1 / singularValues[i];
} else {
a = 0;
}
This is not consistent with the manner in which rank is determined (lines 225
to 233). That is to say a matrix could potentially be rank deficient, yet the
psuedoinverse would still include the redundant columns...
Also, there is the problem of very small singular values which could result
in overflow.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-602) Inverse condition number
[
https://issues.apache.org/jira/browse/MATH-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084560#comment-13084560
]
Gilles commented on MATH-602:
-
Committed in revision 1157345.
However it would be nice to have a non-trivial test, showing the usefulness of
the method. IIUC, the rationale for adding it is that
{code}
getInverseConditionNumber()
{code}
is not always equal to
{code}
1 / getConditionNumber()
{code}
(?)
Which is rather not obvious from the code...
Inverse condition number
Key: MATH-602
URL: https://issues.apache.org/jira/browse/MATH-602
Project: Commons Math
Issue Type: Improvement
Affects Versions: 2.2
Environment: All
Reporter: greg sterijevski
Priority: Minor
Labels: Condition, Inverse, Number
Fix For: 3.0
Attachments: svdinvcond, tstsvd
Original Estimate: 1h
Remaining Estimate: 1h
In SingularValueDecompositionImpl, the condition number is given as the ratio
of the largest singular value to the smallest singular value. While this is
the correct calculation, because of concerns over rank deficiency,
researchers have traditionally used the inverse of the condition number as a
more stable indicator of rank deficiency.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-621: Attachment: bobyqa_convert.pl Here is a script that converts for loops from 1-based to 0-based. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip, bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084596#comment-13084596 ] Gilles commented on MATH-621: - Introducing the INDEX_OFFSET constant in my last commit made the script simpler; it only converts for loops (hopefully all of them). It also changes the value of INDEX_OFFSET from 1 to 0, allowing to leave the auxiliary FortranArray and FortranMatrix in place (they just become no-op wrappers). So, do you want to try correcting the remaining indices? The first error occurs in prelim (at line 1779)... A good strategy might be to insert INDEX_OFFSET at the appropriate places so that when reverting INDEX_OFFSET to 1, we can still test that the behaviour was as before. I thought that it could then help refactoring the do while loop into something more understandable. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip, bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-560) Incorrect @Deprecated tags added to no-args Solver constructors in org.apache.commons.math.analysis.solvers
[ https://issues.apache.org/jira/browse/MATH-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-560. - Resolution: Fixed Removed deprecations in revision 1157395. Incorrect @Deprecated tags added to no-args Solver constructors in org.apache.commons.math.analysis.solvers --- Key: MATH-560 URL: https://issues.apache.org/jira/browse/MATH-560 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Reporter: Nick Fortescue Priority: Minor Fix For: 2.2.1 Original Estimate: 1h Remaining Estimate: 1h During refactoring of the solvers, an @Deprecated javadoc comment was added to the no argument constructor for a number of Solvers, saying they would be removed for 3.0. This is incorrect - there is no plan to remove those constructors. See the discussion on the user list on 2011-04-20. The @deprecated tag should be removed. This causes deprecation warnings in previously compliant code, and should not. This affects at least the following Solvers: MullerSolver, SecantSolver, NewtonSolver. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-485) Feature Request: Kalman Filter
[
https://issues.apache.org/jira/browse/MATH-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084672#comment-13084672
]
Gilles commented on MATH-485:
-
[...] That means that those exceptions would have been better placed in
o.a.c.m.exception [...]
[...] That is like saying that matrices themselves should move to whatever
package uses them.
The exceptions have to do with linear algebraic objects. It makes sense and
is generally
accepted best practice to define the exceptions in the packages where
associated objects are
found. [...]
I consider that a lot of exceptions are at the same level as any other class of
the library: They are not subsumed to a particular data structure but to the
various uses of that data structure. A matrix is not right or wrong in
itself[1]; whether to throw a {{NonSquareMatrixException}} depends on the
algorithm in which the matrix is used and absolutely not on the matrix concept
itself.
So I think that in CM, we can make a difference between exceptions that are
tied to a specific data structure[2] and those which are first-class citizens
and of general use, in which case they should go in their own exception
package.
[1] Unlike, say, a string which can be a valid or an invalid representation of
a number.
[2] For cases where there exists a link like between {{Number}} and
{{NumberFormatException}}.
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: MATH-485-cleanup2.patch, MATH-485-update1.patch,
MATH-485.patch
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-645) MathRuntimeException with simple ebeMultiply on OpenMapRealVector
[
https://issues.apache.org/jira/browse/MATH-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084678#comment-13084678
]
Gilles commented on MATH-645:
-
Probably fixed in revision 1157403.
Added a unit test for ebeMultiply and ebeDivide.
MathRuntimeException with simple ebeMultiply on OpenMapRealVector
-
Key: MATH-645
URL: https://issues.apache.org/jira/browse/MATH-645
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Labels: linear, sparse, vector
The following piece of code
{code:java}
import org.apache.commons.math.linear.OpenMapRealVector;
import org.apache.commons.math.linear.RealVector;
public class DemoBugOpenMapRealVector {
public static void main(String[] args) {
final RealVector u = new OpenMapRealVector(3, 1E-6);
u.setEntry(0, 1.);
u.setEntry(1, 0.);
u.setEntry(2, 2.);
final RealVector v = new OpenMapRealVector(3, 1E-6);
v.setEntry(0, 0.);
v.setEntry(1, 3.);
v.setEntry(2, 0.);
System.out.println(u);
System.out.println(v);
System.out.println(u.ebeMultiply(v));
}
}
{code}
raises an exception
{noformat}
org.apache.commons.math.linear.OpenMapRealVector@7170a9b6
Exception in thread main org.apache.commons.math.MathRuntimeException$6:
map has been modified while iterating
at
org.apache.commons.math.MathRuntimeException.createConcurrentModificationException(MathRuntimeException.java:373)
at
org.apache.commons.math.util.OpenIntToDoubleHashMap$Iterator.advance(OpenIntToDoubleHashMap.java:564)
at
org.apache.commons.math.linear.OpenMapRealVector.ebeMultiply(OpenMapRealVector.java:372)
at
org.apache.commons.math.linear.OpenMapRealVector.ebeMultiply(OpenMapRealVector.java:1)
at DemoBugOpenMapRealVector.main(DemoBugOpenMapRealVector.java:17)
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-646) Unmodifiable views of RealVector
[
https://issues.apache.org/jira/browse/MATH-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084913#comment-13084913
]
Gilles commented on MATH-646:
-
{quote}
I chose not to nest it in AbstractRealVector because it would make the
corresponding file huge.
{quote}
Rather than an issue of large source file, the issue is whether this class
should part of the public API.
Personally I think that it shouldn't because, as discussed on the ML, it is
useful from the perspective of the caller (it cannot be modified by the callee)
but is not immutable. A method signature containing an UnmodifiableRealVector
parameter could be confusing (leading to a false sense of security). I'd prefer
it to be a private class defined inside AbstractRealVector.java; the only way
to create instances would be by calling the unmodifiableRealVector static
method.
In UnmodifiableEntry, is it necessary to have a constructor?
I'm suspicious that it is possible to call setIndex on the supposedly
unmodifiable entry. Maybe that it is harmless (?).
In fact, I must admit that the whole Entry hierarchy looks odd to me. Maybe
that we should have closer look at [MATH-626]. I have now the impression that
moving the sparse vectors into their own hierarchy would simplify a lot of
methods...
Thanks for the tests; they look quite thorough!
A few things in UnmodifiableRealVectorAbstractTest:
* The utility method testMethod should probably be named something like
doTest or callMethod to avoid confusion (as by convention test... are
used for methods called by JUnit). Also, it should be private.
* Didn't you forget to write the @Test annotation for testGetSubVector?
* I think that it's better to leave the stack trace printing to JUnit (cf. the
exceptions generated by the reflection calls): You could just declare those
exceptions in the methods signature.
* You've excluded ebeDivide from the generic test but it is not handled
separately.
Unmodifiable views of RealVector
Key: MATH-646
URL: https://issues.apache.org/jira/browse/MATH-646
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Labels: linear, vector
Attachments: MATH-646.patch
The issue has been discussed on the [mailing
list|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/CAGRH7HqxUb2y1HmFt9VJ-kxsXwipk_MdO0D=rnuazmgpnot...@mail.gmail.com].
Please find attached a proposal for a new class {{UnmodifiableRealVector}}.
I chose not to nest it in {{AbstractRealVector}} because it would make the
corresponding file huge. Therefore, {{UnmodifiableRealVector}} is {{final}}.
Maybe you'd like it to be {{private}} as well? A static method is provided in
{{AbstractRealVector}} to build an {{UnmodifiableRealVector}} from any
{{RealVector}}.
Tests are also provided. Since iterating through different implementations of
{{RealVector}} is actually different, a test is provided for
{{UnmodifiableRealVector}} built on {{ArrayRealVector}} and
{{OpenMapRealVector}}. These tests both derive from the same abstract test
class. Hope everything works fine.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085061#comment-13085061
]
Gilles commented on MATH-621:
-
Thanks for the work.
However, if I change the INDEX_OFFSET constant (setting it back to 1), the
tests fail.
I see that you hard-coded the offset in most places instead of using
INDEX_OFFSET. I still think that this place-holder would be useful to keep
track of places where the index variables might have been set to fit with the
Fortran 1-based counting... Don't you?
{quote}
The perl script has damaged the for loop intendation
{quote}
Sorry, I didn't see that. But that's easy to fix. I'll do it after the issue
with INDEX_OFFSET is settled.
{quote}
n, npt and nptm should be global variables and not set separately
in each method
{quote}
Yes, I agree. But there are probably many other variables for which this is
true (zmat, bmat, etc).
{quote}
System generated locals: Declare variables in the scope they are needed [...]
{quote}
Agreed, of course. I had started to do that mainly with d__1; then there are
many cases where the same variable was reused whereas we would prefer to create
yet another one with a more explicit name.
{quote}
testDiagonalRosen() is a copy/paste leftover from CMAES, should be removed
{quote}
OK, I'll do it in the next commit.
{quote}
We should shink about removing rescue as proposed by Mike Powell.
{quote}
I'm all for anything that leads to removing unnecessary lines of code :)
If you are indeed confident that, in most cases, the added complexity is not
worth it, I'll just delete it.
BOBYQA is missing in optimization
-
Key: MATH-621
URL: https://issues.apache.org/jira/browse/MATH-621
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dr. Dietmar Wolz
Fix For: 3.0
Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch,
BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl,
bobyqaoptimizer0.4.zip, bobyqav0.3.zip
Original Estimate: 8h
Remaining Estimate: 8h
During experiments with space flight trajectory optimizations I recently
observed, that the direct optimization algorithm BOBYQA
http://plato.asu.edu/ftp/other_software/bobyqa.zip
from Mike Powell is significantly better than the simple Powell algorithm
already in commons.math. It uses significantly lower function calls and is
more reliable for high dimensional problems. You can replace CMA-ES in many
more application cases by BOBYQA than by the simple Powell optimizer.
I would like to contribute a Java port of the algorithm.
I maintained the structure of the original FORTRAN code, so the
code is fast but not very nice.
License status: Michael Powell has sent the agreement via snail mail
- it hasn't arrived yet.
Progress: The attached patch relative to the trunk contains both the
optimizer and the related unit tests - which are all green now.
Performance:
Performance difference (number of function evaluations)
PowellOptimizer / BOBYQA for different test functions (taken from
the unit test of BOBYQA, dimension=13 for most of the
tests.
Rosen = 9350 / 1283
MinusElli = 118 / 59
Elli = 223 / 58
ElliRotated = 8626 / 1379
Cigar = 353 / 60
TwoAxes = 223 / 66
CigTab = 362 / 60
Sphere = 223 / 58
Tablet = 223 / 58
DiffPow = 421 / 928
SsDiffPow = 614 / 219
Ackley = 757 / 97
Rastrigin = 340 / 64
The number for DiffPow should be dicussed with Michael Powell,
I will send him the details.
Open Problems:
Some checkstyle violations because of the original Fortran source:
- Original method comments were copied - doesn't follow javadoc standard
- Multiple variable declarations in one line as in the original source
- Problems related to goto conversions:
gotos not convertible in loops were transated into a finite automata
(switch statement)
no default in switch
fall through from previos case in switch
which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085243#comment-13085243 ] Gilles commented on MATH-621: - OK. Keeping INDEX_OFFSET might be more work than really useful. I'll remove it also. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-646) Unmodifiable views of RealVector
[
https://issues.apache.org/jira/browse/MATH-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085329#comment-13085329
]
Gilles commented on MATH-646:
-
There must be one public (or with package access) class in each Java source
file.
But you can have additional ones (without access qualifier), not necessarily
nested. Thus, in AbstractRealVector.java:
{code}
public class AbstractRealVector implements RealVector {
// ...
public static RealVector unmodifiableRealVector(RealVector v) {
return new UnmodifiableRealVector(v);
}
}
class UnmodifiableRealVector implements RealVector {
// ...
}
{code}
This makes for slightly less cluttered code.
Unmodifiable views of RealVector
Key: MATH-646
URL: https://issues.apache.org/jira/browse/MATH-646
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Labels: linear, vector
Attachments: MATH-646.patch
The issue has been discussed on the [mailing
list|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/CAGRH7HqxUb2y1HmFt9VJ-kxsXwipk_MdO0D=rnuazmgpnot...@mail.gmail.com].
Please find attached a proposal for a new class {{UnmodifiableRealVector}}.
I chose not to nest it in {{AbstractRealVector}} because it would make the
corresponding file huge. Therefore, {{UnmodifiableRealVector}} is {{final}}.
Maybe you'd like it to be {{private}} as well? A static method is provided in
{{AbstractRealVector}} to build an {{UnmodifiableRealVector}} from any
{{RealVector}}.
Tests are also provided. Since iterating through different implementations of
{{RealVector}} is actually different, a test is provided for
{{UnmodifiableRealVector}} built on {{ArrayRealVector}} and
{{OpenMapRealVector}}. These tests both derive from the same abstract test
class. Hope everything works fine.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085332#comment-13085332 ] Gilles commented on MATH-621: - 1-based indexing issue solved in revision 1158015. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085334#comment-13085334 ] Gilles commented on MATH-621: - Removed testDiagonalRosen unit test in revision 1158017. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085340#comment-13085340 ] Gilles commented on MATH-621: - Commenting out rescue (line 671) makes the testRescue test fail, as expected. So, if I also remove the test, we are fine. However, do you know whether I can also remove the whole case 190 (lines 667-697) as well as any code that references that state (e.g. lines 791-796, 846-851, 2597-2599, etc.)? BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085980#comment-13085980 ] Gilles commented on MATH-621: - rescue removed in revision 1158448. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086368#comment-13086368
]
Gilles commented on MATH-621:
-
{quote}
remove unused variables
{quote}
Would you take that one?
{quote}
reorganize variable use (limit their scope)
{quote}
I've done this for altmov and update.
Let me know which function(s) you'd like to deal with.
{quote}
would be great if we could use/identify some of the ArrayRealVector [...]
{quote}
This can be left for after the other two points I think.
When you make changes, please provide a patch for each step separately: i.e.
one patch for point 1, one patch for each function, for point 2.
BOBYQA is missing in optimization
-
Key: MATH-621
URL: https://issues.apache.org/jira/browse/MATH-621
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dr. Dietmar Wolz
Fix For: 3.0
Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch,
BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl,
bobyqaoptimizer0.4.zip, bobyqav0.3.zip
Original Estimate: 8h
Remaining Estimate: 8h
During experiments with space flight trajectory optimizations I recently
observed, that the direct optimization algorithm BOBYQA
http://plato.asu.edu/ftp/other_software/bobyqa.zip
from Mike Powell is significantly better than the simple Powell algorithm
already in commons.math. It uses significantly lower function calls and is
more reliable for high dimensional problems. You can replace CMA-ES in many
more application cases by BOBYQA than by the simple Powell optimizer.
I would like to contribute a Java port of the algorithm.
I maintained the structure of the original FORTRAN code, so the
code is fast but not very nice.
License status: Michael Powell has sent the agreement via snail mail
- it hasn't arrived yet.
Progress: The attached patch relative to the trunk contains both the
optimizer and the related unit tests - which are all green now.
Performance:
Performance difference (number of function evaluations)
PowellOptimizer / BOBYQA for different test functions (taken from
the unit test of BOBYQA, dimension=13 for most of the
tests.
Rosen = 9350 / 1283
MinusElli = 118 / 59
Elli = 223 / 58
ElliRotated = 8626 / 1379
Cigar = 353 / 60
TwoAxes = 223 / 66
CigTab = 362 / 60
Sphere = 223 / 58
Tablet = 223 / 58
DiffPow = 421 / 928
SsDiffPow = 614 / 219
Ackley = 757 / 97
Rastrigin = 340 / 64
The number for DiffPow should be dicussed with Michael Powell,
I will send him the details.
Open Problems:
Some checkstyle violations because of the original Fortran source:
- Original method comments were copied - doesn't follow javadoc standard
- Multiple variable declarations in one line as in the original source
- Problems related to goto conversions:
gotos not convertible in loops were transated into a finite automata
(switch statement)
no default in switch
fall through from previos case in switch
which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086994#comment-13086994
]
Gilles commented on MATH-621:
-
Oops, sorry; _I_ had not updated the to latest revision! Working on two
computers, I forgot to coordinate with myself. :P
Patch committed in revision 1159203.
{quote}
Is it a good idea to maintain a import order inconsistent with organize
imports in eclipse?
{quote}
Not everybody use Eclipse...
BOBYQA is missing in optimization
-
Key: MATH-621
URL: https://issues.apache.org/jira/browse/MATH-621
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dr. Dietmar Wolz
Fix For: 3.0
Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch,
BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip
Original Estimate: 8h
Remaining Estimate: 8h
During experiments with space flight trajectory optimizations I recently
observed, that the direct optimization algorithm BOBYQA
http://plato.asu.edu/ftp/other_software/bobyqa.zip
from Mike Powell is significantly better than the simple Powell algorithm
already in commons.math. It uses significantly lower function calls and is
more reliable for high dimensional problems. You can replace CMA-ES in many
more application cases by BOBYQA than by the simple Powell optimizer.
I would like to contribute a Java port of the algorithm.
I maintained the structure of the original FORTRAN code, so the
code is fast but not very nice.
License status: Michael Powell has sent the agreement via snail mail
- it hasn't arrived yet.
Progress: The attached patch relative to the trunk contains both the
optimizer and the related unit tests - which are all green now.
Performance:
Performance difference (number of function evaluations)
PowellOptimizer / BOBYQA for different test functions (taken from
the unit test of BOBYQA, dimension=13 for most of the
tests.
Rosen = 9350 / 1283
MinusElli = 118 / 59
Elli = 223 / 58
ElliRotated = 8626 / 1379
Cigar = 353 / 60
TwoAxes = 223 / 66
CigTab = 362 / 60
Sphere = 223 / 58
Tablet = 223 / 58
DiffPow = 421 / 928
SsDiffPow = 614 / 219
Ackley = 757 / 97
Rastrigin = 340 / 64
The number for DiffPow should be dicussed with Michael Powell,
I will send him the details.
Open Problems:
Some checkstyle violations because of the original Fortran source:
- Original method comments were copied - doesn't follow javadoc standard
- Multiple variable declarations in one line as in the original source
- Problems related to goto conversions:
gotos not convertible in loops were transated into a finite automata
(switch statement)
no default in switch
fall through from previos case in switch
which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-614) toString method for Complex
[ https://issues.apache.org/jira/browse/MATH-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-614. - Resolution: Fixed toString method for Complex --- Key: MATH-614 URL: https://issues.apache.org/jira/browse/MATH-614 Project: Commons Math Issue Type: Wish Reporter: Gilles Assignee: Gilles Priority: Trivial Fix For: 3.0 Attachments: math.patch Class Complex (in package complex) lacks a toString() method. [Request from Arne Ploese on the dev ML.] I also propose to slightly modify the format method in ComplexFormat so that the stringified version of Complex(1, 1) is 1 + i instead of 1 + 1i. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-413) Miscellaneous issues concerning the optimization package
[
https://issues.apache.org/jira/browse/MATH-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087026#comment-13087026
]
Gilles commented on MATH-413:
-
{{GaussNewtonOptimizer}} updated in revision 1159233.
Miscellaneous issues concerning the optimization package
--
Key: MATH-413
URL: https://issues.apache.org/jira/browse/MATH-413
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
Revision 990792 contains changes triggered the following issues:
* [MATH-394|https://issues.apache.org/jira/browse/MATH-394]
* [MATH-397|https://issues.apache.org/jira/browse/MATH-397]
* [MATH-404|https://issues.apache.org/jira/browse/MATH-404]
This issue collects the currently still unsatisfactory code (not necessarily
sorted in order of annoyance):
# BrentOptimizer: a specific convergence checker must be used.
LevenbergMarquardtOptimizer also has specific convergence checks.
# Trying to make convergence checking independent of the optimization
algorithm creates problems (conceptual and practical):
** See BrentOptimizer and LevenbergMarquardtOptimizer, the algorithm
passes points to the convergence checker, but the actual meaning of the
points can very well be different in the caller (optimization algorithm) and
the callee (convergence checker).
** In PowellOptimizer the line search (BrentOptimizer) tolerances depend
on the tolerances within the main algorithm. Since tolerances come with
ConvergenceChecker and so can be changed at any time, it is awkward to
adapt the values within the line search optimizer without exposing its
internals (BrentOptimizer field) to the enclosing class (PowellOptimizer).
# Given the numerous changes, some Javadoc comments might be out-of-sync,
although I did try to update them all.
# Class DirectSearchOptimizer (in package optimization.direct) inherits
from class AbstractScalarOptimizer (in package optimization.general).
# Some interfaces are defined in package optimization but their base
implementations (abstract class that contain the boiler-plate code) are in
package optimization.general (e.g.
DifferentiableMultivariateVectorialOptimizer and
BaseAbstractVectorialOptimizer).
# No check is performed to ensure the the convergence checker has been set
(see e.g. BrentOptimizer and PowellOptimizer); if it hasn't there will be
a NPE. The alternative is to initialize a default checker that will never be
used in case the user had intended to explicitly sets the checker.
# NonLinearConjugateGradientOptimizer: Ugly workaround for the checked
ConvergenceException.
# Everywhere, we trail the checked FunctionEvaluationException although it
is never used.
# There remains some duplicate code (such as the multi-start loop in the
various MultiStart... implementations).
# The ConvergenceChecker interface is very general (the converged method
can take any number of ...PointValuePair). However there remains a
semantic problem: One cannot be sure that the list of points means the same
thing for the caller of converged and within the implementation of the
ConvergenceChecker that was independently set.
# It is not clear whether it is wise to aggregate the counter of gradient
evaluations to the function evaluation counter. In
LevenbergMarquartdOptimizer for example, it would be unfair to do so.
Currently I had to remove all tests referring to gradient and Jacobian
evaluations.
# In AbstractLeastSquaresOptimizer and LevenbergMarquardtOptimizer,
occurences of OptimizationException were replaced by the unchecked
ConvergenceException but in some cases it might not be the most appropriate
one.
# MultiStartUnivariateRealOptimizer: in the other classes
(MultiStartMultivariate...) similar to this one, the randomization is on
the firts-guess value while in this class, it is on the search interval. I
think that here also we should randomly choose the start value (within the
user-selected interval).
# The Javadoc utility raises warnings (see output of mvn site) which I
couldn't figure out how to correct.
# Some previously existing classes and interfaces have become no more than a
specialisation of new generics classes; it might be interesting to remove
them in order to reduce the number of classes and thus limit the potential
for confusion.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087033#comment-13087033
]
Gilles commented on MATH-621:
-
{quote}
So you want to force Eclipse users not to use the organize import
functionality?
{quote}
No; just that, if you want to perform such cleanup, you should provide it in a
separate patch. Otherwise I can get complaints: The rule is that a commit
should aim at fixing one distinct issue at a time.
BOBYQA is missing in optimization
-
Key: MATH-621
URL: https://issues.apache.org/jira/browse/MATH-621
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dr. Dietmar Wolz
Fix For: 3.0
Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch,
BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip
Original Estimate: 8h
Remaining Estimate: 8h
During experiments with space flight trajectory optimizations I recently
observed, that the direct optimization algorithm BOBYQA
http://plato.asu.edu/ftp/other_software/bobyqa.zip
from Mike Powell is significantly better than the simple Powell algorithm
already in commons.math. It uses significantly lower function calls and is
more reliable for high dimensional problems. You can replace CMA-ES in many
more application cases by BOBYQA than by the simple Powell optimizer.
I would like to contribute a Java port of the algorithm.
I maintained the structure of the original FORTRAN code, so the
code is fast but not very nice.
License status: Michael Powell has sent the agreement via snail mail
- it hasn't arrived yet.
Progress: The attached patch relative to the trunk contains both the
optimizer and the related unit tests - which are all green now.
Performance:
Performance difference (number of function evaluations)
PowellOptimizer / BOBYQA for different test functions (taken from
the unit test of BOBYQA, dimension=13 for most of the
tests.
Rosen = 9350 / 1283
MinusElli = 118 / 59
Elli = 223 / 58
ElliRotated = 8626 / 1379
Cigar = 353 / 60
TwoAxes = 223 / 66
CigTab = 362 / 60
Sphere = 223 / 58
Tablet = 223 / 58
DiffPow = 421 / 928
SsDiffPow = 614 / 219
Ackley = 757 / 97
Rastrigin = 340 / 64
The number for DiffPow should be dicussed with Michael Powell,
I will send him the details.
Open Problems:
Some checkstyle violations because of the original Fortran source:
- Original method comments were copied - doesn't follow javadoc standard
- Multiple variable declarations in one line as in the original source
- Problems related to goto conversions:
gotos not convertible in loops were transated into a finite automata
(switch statement)
no default in switch
fall through from previos case in switch
which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087370#comment-13087370 ] Gilles commented on MATH-621: - An unexplored code path: See revision 1159438. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087408#comment-13087408
]
Gilles commented on MATH-621:
-
I tried to replace a loop with a matrix operation: The computation of the first
sum in case 90 (line 564). Although the new and old computations differ by
less than 1e-15, they induce failures:
{noformat}
Failed tests:
testAckley(org.apache.commons.math.optimization.direct.BOBYQAOptimizerTest):
expected:0.0 but was:1.0731970423449866E-8
Tests in error:
testDiffPow(org.apache.commons.math.optimization.direct.BOBYQAOptimizerTest):
illegal state: maximal count (12,000) exceeded: evaluations
{noformat}
The first is possibly (?) acceptable due to numerical errors but the second
seems more problematic.
Anyways, it looks like these kinds of code transformation should not be
attempted at this point.
BOBYQA is missing in optimization
-
Key: MATH-621
URL: https://issues.apache.org/jira/browse/MATH-621
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dr. Dietmar Wolz
Fix For: 3.0
Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch,
BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip
Original Estimate: 8h
Remaining Estimate: 8h
During experiments with space flight trajectory optimizations I recently
observed, that the direct optimization algorithm BOBYQA
http://plato.asu.edu/ftp/other_software/bobyqa.zip
from Mike Powell is significantly better than the simple Powell algorithm
already in commons.math. It uses significantly lower function calls and is
more reliable for high dimensional problems. You can replace CMA-ES in many
more application cases by BOBYQA than by the simple Powell optimizer.
I would like to contribute a Java port of the algorithm.
I maintained the structure of the original FORTRAN code, so the
code is fast but not very nice.
License status: Michael Powell has sent the agreement via snail mail
- it hasn't arrived yet.
Progress: The attached patch relative to the trunk contains both the
optimizer and the related unit tests - which are all green now.
Performance:
Performance difference (number of function evaluations)
PowellOptimizer / BOBYQA for different test functions (taken from
the unit test of BOBYQA, dimension=13 for most of the
tests.
Rosen = 9350 / 1283
MinusElli = 118 / 59
Elli = 223 / 58
ElliRotated = 8626 / 1379
Cigar = 353 / 60
TwoAxes = 223 / 66
CigTab = 362 / 60
Sphere = 223 / 58
Tablet = 223 / 58
DiffPow = 421 / 928
SsDiffPow = 614 / 219
Ackley = 757 / 97
Rastrigin = 340 / 64
The number for DiffPow should be dicussed with Michael Powell,
I will send him the details.
Open Problems:
Some checkstyle violations because of the original Fortran source:
- Original method comments were copied - doesn't follow javadoc standard
- Multiple variable declarations in one line as in the original source
- Problems related to goto conversions:
gotos not convertible in loops were transated into a finite automata
(switch statement)
no default in switch
fall through from previos case in switch
which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088001#comment-13088001 ] Gilles commented on MATH-621: - prelim cleaned up in revision 1159792. Another occurrence of a supposedly innocuous change (dividing by a number vs multiplying by the inverse of that number) induces the same two unit tests to fail. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088002#comment-13088002 ] Gilles commented on MATH-621: - Many code branches in prelim unexplored by the current set of unit tests. The unused code paths are marked by throwing an exception as their last statement. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088339#comment-13088339 ] Gilles commented on MATH-621: - Looking at the unit tests I see that, in the assertEquals, tolerance for the function values are not very stringent (e.g. 1e-8 instead of, say, 1e-15); so this means that your initial translation was already not expected to reproduce exactly the reference results (Fortran or C++ (?)). Am I correct? So, in the Ackley case, the tolerance is set to 1e-8, and the alternative computation produces 1.07319e-8 instead of 0.0. Thus the absolute change in tolerance is smaller than 1e-10, which might be put on the account of error propagation (?). However, in DiffPow, the number of evaluations with the your original code is 6016, while the alternative computation makes it fail even as 12000 are allowed. This looks like a much more drastic change in behaviour! Pardon my possible ignorance, but it makes we wonder whether the test is not too fragile or whether there is a bug in the implementation... In other words it would have been a lucky accident that the original computation succeeds. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-646) Unmodifiable views of RealVector
[
https://issues.apache.org/jira/browse/MATH-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090164#comment-13090164
]
Gilles commented on MATH-646:
-
Committed, with some small changes, in revision 1161064.
Before posting a patch, please don't forget to look at the output of mvn clean
site for Javadoc warnings and at checkstyle.html (in target/site).
Couldn't we call the unmodifiableRealVector method simply
unmodifiableVector?
Unmodifiable views of RealVector
Key: MATH-646
URL: https://issues.apache.org/jira/browse/MATH-646
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Labels: linear, vector
Attachments: MATH-646.patch, MATH-646.patch
The issue has been discussed on the [mailing
list|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/CAGRH7HqxUb2y1HmFt9VJ-kxsXwipk_MdO0D=rnuazmgpnot...@mail.gmail.com].
Please find attached a proposal for a new class {{UnmodifiableRealVector}}.
I chose not to nest it in {{AbstractRealVector}} because it would make the
corresponding file huge. Therefore, {{UnmodifiableRealVector}} is {{final}}.
Maybe you'd like it to be {{private}} as well? A static method is provided in
{{AbstractRealVector}} to build an {{UnmodifiableRealVector}} from any
{{RealVector}}.
Tests are also provided. Since iterating through different implementations of
{{RealVector}} is actually different, a test is provided for
{{UnmodifiableRealVector}} built on {{ArrayRealVector}} and
{{OpenMapRealVector}}. These tests both derive from the same abstract test
class. Hope everything works fine.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-646) Unmodifiable views of RealVector
[
https://issues.apache.org/jira/browse/MATH-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090190#comment-13090190
]
Gilles commented on MATH-646:
-
For unmodifiableRealVector - unmodifiableVector, I can do it; I was just
wondering whether there could be any side-effects (like the risk of having
another method like this in the future) or whether it would be better to have a
suffix that is exactly the name of the returned type...
For the matrix view, do you have a need for it now? If not, it could be delayed
to 3.1 and, if you want, you could tackle issues that must be resolved before
3.0.
Unmodifiable views of RealVector
Key: MATH-646
URL: https://issues.apache.org/jira/browse/MATH-646
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Labels: linear, vector
Attachments: MATH-646.patch, MATH-646.patch
The issue has been discussed on the [mailing
list|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/CAGRH7HqxUb2y1HmFt9VJ-kxsXwipk_MdO0D=rnuazmgpnot...@mail.gmail.com].
Please find attached a proposal for a new class {{UnmodifiableRealVector}}.
I chose not to nest it in {{AbstractRealVector}} because it would make the
corresponding file huge. Therefore, {{UnmodifiableRealVector}} is {{final}}.
Maybe you'd like it to be {{private}} as well? A static method is provided in
{{AbstractRealVector}} to build an {{UnmodifiableRealVector}} from any
{{RealVector}}.
Tests are also provided. Since iterating through different implementations of
{{RealVector}} is actually different, a test is provided for
{{UnmodifiableRealVector}} built on {{ArrayRealVector}} and
{{OpenMapRealVector}}. These tests both derive from the same abstract test
class. Hope everything works fine.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-413) Miscellaneous issues concerning the optimization package
[
https://issues.apache.org/jira/browse/MATH-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090885#comment-13090885
]
Gilles commented on MATH-413:
-
{{LevenbergMarquardtOptimizer}} updated in revision 1161463.
Miscellaneous issues concerning the optimization package
--
Key: MATH-413
URL: https://issues.apache.org/jira/browse/MATH-413
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
Revision 990792 contains changes triggered the following issues:
* [MATH-394|https://issues.apache.org/jira/browse/MATH-394]
* [MATH-397|https://issues.apache.org/jira/browse/MATH-397]
* [MATH-404|https://issues.apache.org/jira/browse/MATH-404]
This issue collects the currently still unsatisfactory code (not necessarily
sorted in order of annoyance):
# BrentOptimizer: a specific convergence checker must be used.
LevenbergMarquardtOptimizer also has specific convergence checks.
# Trying to make convergence checking independent of the optimization
algorithm creates problems (conceptual and practical):
** See BrentOptimizer and LevenbergMarquardtOptimizer, the algorithm
passes points to the convergence checker, but the actual meaning of the
points can very well be different in the caller (optimization algorithm) and
the callee (convergence checker).
** In PowellOptimizer the line search (BrentOptimizer) tolerances depend
on the tolerances within the main algorithm. Since tolerances come with
ConvergenceChecker and so can be changed at any time, it is awkward to
adapt the values within the line search optimizer without exposing its
internals (BrentOptimizer field) to the enclosing class (PowellOptimizer).
# Given the numerous changes, some Javadoc comments might be out-of-sync,
although I did try to update them all.
# Class DirectSearchOptimizer (in package optimization.direct) inherits
from class AbstractScalarOptimizer (in package optimization.general).
# Some interfaces are defined in package optimization but their base
implementations (abstract class that contain the boiler-plate code) are in
package optimization.general (e.g.
DifferentiableMultivariateVectorialOptimizer and
BaseAbstractVectorialOptimizer).
# No check is performed to ensure the the convergence checker has been set
(see e.g. BrentOptimizer and PowellOptimizer); if it hasn't there will be
a NPE. The alternative is to initialize a default checker that will never be
used in case the user had intended to explicitly sets the checker.
# NonLinearConjugateGradientOptimizer: Ugly workaround for the checked
ConvergenceException.
# Everywhere, we trail the checked FunctionEvaluationException although it
is never used.
# There remains some duplicate code (such as the multi-start loop in the
various MultiStart... implementations).
# The ConvergenceChecker interface is very general (the converged method
can take any number of ...PointValuePair). However there remains a
semantic problem: One cannot be sure that the list of points means the same
thing for the caller of converged and within the implementation of the
ConvergenceChecker that was independently set.
# It is not clear whether it is wise to aggregate the counter of gradient
evaluations to the function evaluation counter. In
LevenbergMarquartdOptimizer for example, it would be unfair to do so.
Currently I had to remove all tests referring to gradient and Jacobian
evaluations.
# In AbstractLeastSquaresOptimizer and LevenbergMarquardtOptimizer,
occurences of OptimizationException were replaced by the unchecked
ConvergenceException but in some cases it might not be the most appropriate
one.
# MultiStartUnivariateRealOptimizer: in the other classes
(MultiStartMultivariate...) similar to this one, the randomization is on
the firts-guess value while in this class, it is on the search interval. I
think that here also we should randomly choose the start value (within the
user-selected interval).
# The Javadoc utility raises warnings (see output of mvn site) which I
couldn't figure out how to correct.
# Some previously existing classes and interfaces have become no more than a
specialisation of new generics classes; it might be interesting to remove
them in order to reduce the number of classes and thus limit the potential
for confusion.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-653) Rename AbstractRealVector to RealVector
Rename AbstractRealVector to RealVector --- Key: MATH-653 URL: https://issues.apache.org/jira/browse/MATH-653 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Trivial Fix For: 3.0 AbstractRealVector is the only implementation of the RealVector interface. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-653) Rename AbstractRealVector to RealVector
[
https://issues.apache.org/jira/browse/MATH-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092083#comment-13092083
]
Gilles commented on MATH-653:
-
From Sébastien, on the dev ML (in the thread with subject
RealMatrix.set(double)):
{quote}
I personnaly have come to dislike the schizophrenia in the RealVector
interface between double[] and RealVector. As double[] is the simplest
representation of a vector, all methods which take a RealVector as an
argument in the RealVector interface are duplicated to also take a
double[] as an argument. While this is very flexible for end-users, it
is a bit of a pain when you want to extend this interface in a
consistent way (and it also make the classes implementing RealVector
quite cluttered). I'm just wondering what the real benefit is, since
the existing hierarchy allows (at virtually no cost) the creation of a
RealArrayVector from a double[] without taking first a (costly) deep
copy of the specified double[].
For example, for an end-user, it's not much of a hassle to write
v.add(new ArrayRealVector(w, false))
instead of v.add(w)
w being a double[].
{quote}
I agree.
Also because in AbstractRealVector many of the method that take a double[]
argument actually delegate to the sibling method that take an ArrayRealVector
argument, which looks fairly strange (a superclass relying on one of its
subclasses). Even stranger, some methods of the RealVector interface are not
defined in AbstractRealVector e.g.
{code}
RealVector ebeDivide(RealVector)
{code}
although its equivalent with a double[] is defined and seems to call the
non-existent one above!
Of course, it works because of polymorphism and the fact that
AbstractRealVector can never be instantiated, but it makes the code quite
unobvious.
Hence, I'd like to remove all the method that take a double[] argument as
part of this issue.
Is there any objections?
Rename AbstractRealVector to RealVector
---
Key: MATH-653
URL: https://issues.apache.org/jira/browse/MATH-653
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Fix For: 3.0
AbstractRealVector is the only implementation of the RealVector interface.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-653) Rename AbstractRealVector to RealVector
[ https://issues.apache.org/jira/browse/MATH-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092094#comment-13092094 ] Gilles commented on MATH-653: - Also, as already noted elsewhere, the getData() method is redundant with toArray(). One or the other should go. Rename AbstractRealVector to RealVector --- Key: MATH-653 URL: https://issues.apache.org/jira/browse/MATH-653 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Trivial Fix For: 3.0 AbstractRealVector is the only implementation of the RealVector interface. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-653) Rename AbstractRealVector to RealVector
[
https://issues.apache.org/jira/browse/MATH-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092083#comment-13092083
]
Gilles edited comment on MATH-653 at 8/26/11 10:23 PM:
---
From Sébastien, on the dev ML (in the thread with subject
RealMatrix.set(double)):
{quote}
I personnaly have come to dislike the schizophrenia in the RealVector
interface between double[] and RealVector. As double[] is the simplest
representation of a vector, all methods which take a RealVector as an
argument in the RealVector interface are duplicated to also take a
double[] as an argument. While this is very flexible for end-users, it
is a bit of a pain when you want to extend this interface in a
consistent way (and it also make the classes implementing RealVector
quite cluttered). I'm just wondering what the real benefit is, since
the existing hierarchy allows (at virtually no cost) the creation of a
RealArrayVector from a double[] without taking first a (costly) deep
copy of the specified double[].
For example, for an end-user, it's not much of a hassle to write
v.add(new ArrayRealVector(w, false))
instead of v.add(w)
w being a double[].
{quote}
I agree.
Also for the reason that in AbstractRealVector many of the methods taking a
double[] argument actually delegate to the sibling method that taking an
ArrayRealVector argument, which looks fairly strange (a superclass relying on
one of its subclasses). Even stranger, some methods of the RealVector
interface are not defined in AbstractRealVector e.g.
{code}
RealVector ebeDivide(RealVector)
{code}
although its equivalent with a double[] is defined and seems to call the
non-existent one above!
Of course, it works thanks to polymorphism and the fact that
AbstractRealVector can never be instantiated; however it makes the code quite
unobvious.
Hence, I'd like to remove all the methods that take a double[] argument as
part of this issue.
Is there any objection?
was (Author: erans):
From Sébastien, on the dev ML (in the thread with subject
RealMatrix.set(double)):
{quote}
I personnaly have come to dislike the schizophrenia in the RealVector
interface between double[] and RealVector. As double[] is the simplest
representation of a vector, all methods which take a RealVector as an
argument in the RealVector interface are duplicated to also take a
double[] as an argument. While this is very flexible for end-users, it
is a bit of a pain when you want to extend this interface in a
consistent way (and it also make the classes implementing RealVector
quite cluttered). I'm just wondering what the real benefit is, since
the existing hierarchy allows (at virtually no cost) the creation of a
RealArrayVector from a double[] without taking first a (costly) deep
copy of the specified double[].
For example, for an end-user, it's not much of a hassle to write
v.add(new ArrayRealVector(w, false))
instead of v.add(w)
w being a double[].
{quote}
I agree.
Also because in AbstractRealVector many of the method that take a double[]
argument actually delegate to the sibling method that take an ArrayRealVector
argument, which looks fairly strange (a superclass relying on one of its
subclasses). Even stranger, some methods of the RealVector interface are not
defined in AbstractRealVector e.g.
{code}
RealVector ebeDivide(RealVector)
{code}
although its equivalent with a double[] is defined and seems to call the
non-existent one above!
Of course, it works because of polymorphism and the fact that
AbstractRealVector can never be instantiated, but it makes the code quite
unobvious.
Hence, I'd like to remove all the method that take a double[] argument as
part of this issue.
Is there any objections?
Rename AbstractRealVector to RealVector
---
Key: MATH-653
URL: https://issues.apache.org/jira/browse/MATH-653
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Fix For: 3.0
AbstractRealVector is the only implementation of the RealVector interface.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-653) Rename AbstractRealVector to RealVector
[ https://issues.apache.org/jira/browse/MATH-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092479#comment-13092479 ] Gilles commented on MATH-653: - Renaming done in revision 1162511. Rename AbstractRealVector to RealVector --- Key: MATH-653 URL: https://issues.apache.org/jira/browse/MATH-653 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Trivial Fix For: 3.0 AbstractRealVector is the only implementation of the RealVector interface. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-653) Rename AbstractRealVector to RealVector
[ https://issues.apache.org/jira/browse/MATH-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092593#comment-13092593 ] Gilles commented on MATH-653: - Removed methods taking a double[] arguments from RealVector (revision 1162629). I've left them in ArrayRealVector; they seem to make sense there because the double[] is the underlying storage of that class. Also, they are called within methods that override the base class ones. However, if it is preferable that subclasses do not contain methods that are not in the base class interface, we can either * inline the specialized code and remove the methods, or * make those methods private. What do you think? Rename AbstractRealVector to RealVector --- Key: MATH-653 URL: https://issues.apache.org/jira/browse/MATH-653 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Trivial Fix For: 3.0 AbstractRealVector is the only implementation of the RealVector interface. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-653) Rename AbstractRealVector to RealVector
[
https://issues.apache.org/jira/browse/MATH-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092841#comment-13092841
]
Gilles commented on MATH-653:
-
{quote}
I would favor inlining.
{quote}
Done in revision 1162800.
{quote}
I can take care of RealLinearOperator [...]
{quote}
OK.
{quote}
any plan to rename AbstractRealMatrix to RealMatrix?
{quote}
That certainly should be done. ;)
Maybe better wait for the conclusion of the ongoing discussion on what to
remove/rename in that interface/class...
{quote}
DecompositionSolver [...] remove any methods taking double[] as an input.
{quote}
You are welcome to do it.
Rename AbstractRealVector to RealVector
---
Key: MATH-653
URL: https://issues.apache.org/jira/browse/MATH-653
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Fix For: 3.0
AbstractRealVector is the only implementation of the RealVector interface.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13094598#comment-13094598
]
Gilles commented on MATH-621:
-
{quote}
there is no trapping of max evaluations exception TooManyEvaluationsException
line 833
{quote}
Indeed, that's intended behaviour: The user sets the limit, and must catch the
exception if he wants to perform something instead of letting the application
abort.
As for changing the qualitative behaviour of the algorithm itself, we are not
there yet.
This (Java) code is brand-new and in a state of flux. You are very much welcome
to help make it more Java-like: The main task is to figure out how to replace
the big switch statements (i.e. a set of disguised gotos) into a sequence
of method calls.
BOBYQA is missing in optimization
-
Key: MATH-621
URL: https://issues.apache.org/jira/browse/MATH-621
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dr. Dietmar Wolz
Fix For: 3.0
Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch,
BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip
Original Estimate: 8h
Remaining Estimate: 8h
During experiments with space flight trajectory optimizations I recently
observed, that the direct optimization algorithm BOBYQA
http://plato.asu.edu/ftp/other_software/bobyqa.zip
from Mike Powell is significantly better than the simple Powell algorithm
already in commons.math. It uses significantly lower function calls and is
more reliable for high dimensional problems. You can replace CMA-ES in many
more application cases by BOBYQA than by the simple Powell optimizer.
I would like to contribute a Java port of the algorithm.
I maintained the structure of the original FORTRAN code, so the
code is fast but not very nice.
License status: Michael Powell has sent the agreement via snail mail
- it hasn't arrived yet.
Progress: The attached patch relative to the trunk contains both the
optimizer and the related unit tests - which are all green now.
Performance:
Performance difference (number of function evaluations)
PowellOptimizer / BOBYQA for different test functions (taken from
the unit test of BOBYQA, dimension=13 for most of the
tests.
Rosen = 9350 / 1283
MinusElli = 118 / 59
Elli = 223 / 58
ElliRotated = 8626 / 1379
Cigar = 353 / 60
TwoAxes = 223 / 66
CigTab = 362 / 60
Sphere = 223 / 58
Tablet = 223 / 58
DiffPow = 421 / 928
SsDiffPow = 614 / 219
Ackley = 757 / 97
Rastrigin = 340 / 64
The number for DiffPow should be dicussed with Michael Powell,
I will send him the details.
Open Problems:
Some checkstyle violations because of the original Fortran source:
- Original method comments were copied - doesn't follow javadoc standard
- Multiple variable declarations in one line as in the original source
- Problems related to goto conversions:
gotos not convertible in loops were transated into a finite automata
(switch statement)
no default in switch
fall through from previos case in switch
which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-413) Miscellaneous issues concerning the optimization package
[
https://issues.apache.org/jira/browse/MATH-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095264#comment-13095264
]
Gilles commented on MATH-413:
-
{{NonLinearConjugateGradientOptimizer}} updated in revision 1164044.
Miscellaneous issues concerning the optimization package
--
Key: MATH-413
URL: https://issues.apache.org/jira/browse/MATH-413
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
Revision 990792 contains changes triggered the following issues:
* [MATH-394|https://issues.apache.org/jira/browse/MATH-394]
* [MATH-397|https://issues.apache.org/jira/browse/MATH-397]
* [MATH-404|https://issues.apache.org/jira/browse/MATH-404]
This issue collects the currently still unsatisfactory code (not necessarily
sorted in order of annoyance):
# BrentOptimizer: a specific convergence checker must be used.
LevenbergMarquardtOptimizer also has specific convergence checks.
# Trying to make convergence checking independent of the optimization
algorithm creates problems (conceptual and practical):
** See BrentOptimizer and LevenbergMarquardtOptimizer, the algorithm
passes points to the convergence checker, but the actual meaning of the
points can very well be different in the caller (optimization algorithm) and
the callee (convergence checker).
** In PowellOptimizer the line search (BrentOptimizer) tolerances depend
on the tolerances within the main algorithm. Since tolerances come with
ConvergenceChecker and so can be changed at any time, it is awkward to
adapt the values within the line search optimizer without exposing its
internals (BrentOptimizer field) to the enclosing class (PowellOptimizer).
# Given the numerous changes, some Javadoc comments might be out-of-sync,
although I did try to update them all.
# Class DirectSearchOptimizer (in package optimization.direct) inherits
from class AbstractScalarOptimizer (in package optimization.general).
# Some interfaces are defined in package optimization but their base
implementations (abstract class that contain the boiler-plate code) are in
package optimization.general (e.g.
DifferentiableMultivariateVectorialOptimizer and
BaseAbstractVectorialOptimizer).
# No check is performed to ensure the the convergence checker has been set
(see e.g. BrentOptimizer and PowellOptimizer); if it hasn't there will be
a NPE. The alternative is to initialize a default checker that will never be
used in case the user had intended to explicitly sets the checker.
# NonLinearConjugateGradientOptimizer: Ugly workaround for the checked
ConvergenceException.
# Everywhere, we trail the checked FunctionEvaluationException although it
is never used.
# There remains some duplicate code (such as the multi-start loop in the
various MultiStart... implementations).
# The ConvergenceChecker interface is very general (the converged method
can take any number of ...PointValuePair). However there remains a
semantic problem: One cannot be sure that the list of points means the same
thing for the caller of converged and within the implementation of the
ConvergenceChecker that was independently set.
# It is not clear whether it is wise to aggregate the counter of gradient
evaluations to the function evaluation counter. In
LevenbergMarquartdOptimizer for example, it would be unfair to do so.
Currently I had to remove all tests referring to gradient and Jacobian
evaluations.
# In AbstractLeastSquaresOptimizer and LevenbergMarquardtOptimizer,
occurences of OptimizationException were replaced by the unchecked
ConvergenceException but in some cases it might not be the most appropriate
one.
# MultiStartUnivariateRealOptimizer: in the other classes
(MultiStartMultivariate...) similar to this one, the randomization is on
the firts-guess value while in this class, it is on the search interval. I
think that here also we should randomly choose the start value (within the
user-selected interval).
# The Javadoc utility raises warnings (see output of mvn site) which I
couldn't figure out how to correct.
# Some previously existing classes and interfaces have become no more than a
specialisation of new generics classes; it might be interesting to remove
them in order to reduce the number of classes and thus limit the potential
for confusion.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-413) Miscellaneous issues concerning the optimization package
[
https://issues.apache.org/jira/browse/MATH-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095677#comment-13095677
]
Gilles commented on MATH-413:
-
{{SimplexOptimizer}} updated in revision 1164300.
Miscellaneous issues concerning the optimization package
--
Key: MATH-413
URL: https://issues.apache.org/jira/browse/MATH-413
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
Revision 990792 contains changes triggered the following issues:
* [MATH-394|https://issues.apache.org/jira/browse/MATH-394]
* [MATH-397|https://issues.apache.org/jira/browse/MATH-397]
* [MATH-404|https://issues.apache.org/jira/browse/MATH-404]
This issue collects the currently still unsatisfactory code (not necessarily
sorted in order of annoyance):
# BrentOptimizer: a specific convergence checker must be used.
LevenbergMarquardtOptimizer also has specific convergence checks.
# Trying to make convergence checking independent of the optimization
algorithm creates problems (conceptual and practical):
** See BrentOptimizer and LevenbergMarquardtOptimizer, the algorithm
passes points to the convergence checker, but the actual meaning of the
points can very well be different in the caller (optimization algorithm) and
the callee (convergence checker).
** In PowellOptimizer the line search (BrentOptimizer) tolerances depend
on the tolerances within the main algorithm. Since tolerances come with
ConvergenceChecker and so can be changed at any time, it is awkward to
adapt the values within the line search optimizer without exposing its
internals (BrentOptimizer field) to the enclosing class (PowellOptimizer).
# Given the numerous changes, some Javadoc comments might be out-of-sync,
although I did try to update them all.
# Class DirectSearchOptimizer (in package optimization.direct) inherits
from class AbstractScalarOptimizer (in package optimization.general).
# Some interfaces are defined in package optimization but their base
implementations (abstract class that contain the boiler-plate code) are in
package optimization.general (e.g.
DifferentiableMultivariateVectorialOptimizer and
BaseAbstractVectorialOptimizer).
# No check is performed to ensure the the convergence checker has been set
(see e.g. BrentOptimizer and PowellOptimizer); if it hasn't there will be
a NPE. The alternative is to initialize a default checker that will never be
used in case the user had intended to explicitly sets the checker.
# NonLinearConjugateGradientOptimizer: Ugly workaround for the checked
ConvergenceException.
# Everywhere, we trail the checked FunctionEvaluationException although it
is never used.
# There remains some duplicate code (such as the multi-start loop in the
various MultiStart... implementations).
# The ConvergenceChecker interface is very general (the converged method
can take any number of ...PointValuePair). However there remains a
semantic problem: One cannot be sure that the list of points means the same
thing for the caller of converged and within the implementation of the
ConvergenceChecker that was independently set.
# It is not clear whether it is wise to aggregate the counter of gradient
evaluations to the function evaluation counter. In
LevenbergMarquartdOptimizer for example, it would be unfair to do so.
Currently I had to remove all tests referring to gradient and Jacobian
evaluations.
# In AbstractLeastSquaresOptimizer and LevenbergMarquardtOptimizer,
occurences of OptimizationException were replaced by the unchecked
ConvergenceException but in some cases it might not be the most appropriate
one.
# MultiStartUnivariateRealOptimizer: in the other classes
(MultiStartMultivariate...) similar to this one, the randomization is on
the firts-guess value while in this class, it is on the search interval. I
think that here also we should randomly choose the start value (within the
user-selected interval).
# The Javadoc utility raises warnings (see output of mvn site) which I
couldn't figure out how to correct.
# Some previously existing classes and interfaces have become no more than a
specialisation of new generics classes; it might be interesting to remove
them in order to reduce the number of classes and thus limit the potential
for confusion.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-413) Miscellaneous issues concerning the optimization package
[
https://issues.apache.org/jira/browse/MATH-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095682#comment-13095682
]
Gilles commented on MATH-413:
-
{{PowellOptimizer}} updated in revision 1164303.
Miscellaneous issues concerning the optimization package
--
Key: MATH-413
URL: https://issues.apache.org/jira/browse/MATH-413
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
Revision 990792 contains changes triggered the following issues:
* [MATH-394|https://issues.apache.org/jira/browse/MATH-394]
* [MATH-397|https://issues.apache.org/jira/browse/MATH-397]
* [MATH-404|https://issues.apache.org/jira/browse/MATH-404]
This issue collects the currently still unsatisfactory code (not necessarily
sorted in order of annoyance):
# BrentOptimizer: a specific convergence checker must be used.
LevenbergMarquardtOptimizer also has specific convergence checks.
# Trying to make convergence checking independent of the optimization
algorithm creates problems (conceptual and practical):
** See BrentOptimizer and LevenbergMarquardtOptimizer, the algorithm
passes points to the convergence checker, but the actual meaning of the
points can very well be different in the caller (optimization algorithm) and
the callee (convergence checker).
** In PowellOptimizer the line search (BrentOptimizer) tolerances depend
on the tolerances within the main algorithm. Since tolerances come with
ConvergenceChecker and so can be changed at any time, it is awkward to
adapt the values within the line search optimizer without exposing its
internals (BrentOptimizer field) to the enclosing class (PowellOptimizer).
# Given the numerous changes, some Javadoc comments might be out-of-sync,
although I did try to update them all.
# Class DirectSearchOptimizer (in package optimization.direct) inherits
from class AbstractScalarOptimizer (in package optimization.general).
# Some interfaces are defined in package optimization but their base
implementations (abstract class that contain the boiler-plate code) are in
package optimization.general (e.g.
DifferentiableMultivariateVectorialOptimizer and
BaseAbstractVectorialOptimizer).
# No check is performed to ensure the the convergence checker has been set
(see e.g. BrentOptimizer and PowellOptimizer); if it hasn't there will be
a NPE. The alternative is to initialize a default checker that will never be
used in case the user had intended to explicitly sets the checker.
# NonLinearConjugateGradientOptimizer: Ugly workaround for the checked
ConvergenceException.
# Everywhere, we trail the checked FunctionEvaluationException although it
is never used.
# There remains some duplicate code (such as the multi-start loop in the
various MultiStart... implementations).
# The ConvergenceChecker interface is very general (the converged method
can take any number of ...PointValuePair). However there remains a
semantic problem: One cannot be sure that the list of points means the same
thing for the caller of converged and within the implementation of the
ConvergenceChecker that was independently set.
# It is not clear whether it is wise to aggregate the counter of gradient
evaluations to the function evaluation counter. In
LevenbergMarquartdOptimizer for example, it would be unfair to do so.
Currently I had to remove all tests referring to gradient and Jacobian
evaluations.
# In AbstractLeastSquaresOptimizer and LevenbergMarquardtOptimizer,
occurences of OptimizationException were replaced by the unchecked
ConvergenceException but in some cases it might not be the most appropriate
one.
# MultiStartUnivariateRealOptimizer: in the other classes
(MultiStartMultivariate...) similar to this one, the randomization is on
the firts-guess value while in this class, it is on the search interval. I
think that here also we should randomly choose the start value (within the
user-selected interval).
# The Javadoc utility raises warnings (see output of mvn site) which I
couldn't figure out how to correct.
# Some previously existing classes and interfaces have become no more than a
specialisation of new generics classes; it might be interesting to remove
them in order to reduce the number of classes and thus limit the potential
for confusion.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-631) RegulaFalsiSolver failure
[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095914#comment-13095914
]
Gilles commented on MATH-631:
-
Committed (with minor additional Javadoc fixes) in revision 1164474.
Leaving open until confirmation that {{ConvergenceException}} is the right one
to use. I thought that we could make a difference between _theoretical_ and
_implementation_ convergence failures. But it might not be worth introducing
the distinction just for this one case, especially since it is quite clear
clear now that the class should not be used.
RegulaFalsiSolver failure
---
Key: MATH-631
URL: https://issues.apache.org/jira/browse/MATH-631
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
Attachments: ticket631.patch
The following unit test:
{code}
@Test
public void testBug() {
final UnivariateRealFunction f = new UnivariateRealFunction() {
@Override
public double value(double x) {
return Math.exp(x) - Math.pow(Math.PI, 3.0);
}
};
UnivariateRealSolver solver = new RegulaFalsiSolver();
double root = solver.solve(100, f, 1, 10);
}
{code}
fails with
{noformat}
illegal state: maximal count (100) exceeded: evaluations
{noformat}
Using PegasusSolver, the answer is found after 17 evaluations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-655) General framework for iterative algorithms
[
https://issues.apache.org/jira/browse/MATH-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095952#comment-13095952
]
Gilles commented on MATH-655:
-
There are many families of algorithms that have iterative implementations but
also share _other_ basic functionality (like the solvers family or the
optimizers family). But there is no multiple inheritance in Java; so, an
implementation that would benefit from the boiler-plate code of
{{IterativeAlgorithm}} cannot inherit from it and also from something else
(like a solver base class).
A solution would be that all these families have {{IterativeAlgorithm}} as
their common ancestor; but it would have major (IMHO) drawbacks:
* An implementation detail (e.g. the fact that some root solver performs
iterations) becomes most prominent.
* Some specific implementations that could in fact be non-iterative would
nevertheless look like they are.
So, how did you intend to plug {{IterativeAlgorithm}} into the design?
The presence of a protected method like {{resetIterationCount}} means that it
is to be inherited from (i.e. the above solution).
General framework for iterative algorithms
--
Key: MATH-655
URL: https://issues.apache.org/jira/browse/MATH-655
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Minor
Labels: algorithm, events
Attachments: iterative-algorithm.zip
Following the thread [Monitoring iterative
algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
here is a first attempt at defining a general enough framework for iterative
algorithms at large. At the moment, the classes provide support for
* maximum number of iterations
* events handling
** initialization event (prior to entering the main loop),
** iteration event (after completion of one iteration),
** termination event (after termination of the main loop).
These classes do not yet provide support for a stopping criterion.
Some points worth to note
* For the time being, the classes are part of the o.a.c.m.linear package.
* For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws
a {{TooManyEvaluationsException}}. If the proposed new feature is integrated
into CM, then a proper {{TooManyIterationsException}} should be created, from
which the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-655) General framework for iterative algorithms
[
https://issues.apache.org/jira/browse/MATH-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095983#comment-13095983
]
Gilles commented on MATH-655:
-
Do you mean that you are going back to the solution of merging monitoring with
actual work?
If so, I'd prefer that you focus on the actual work part and leave the
monitoring on the side for the time being. Otherwise, we'll again be stuck with
methods that can't be removed because of the backward compatibility
requirement...
General framework for iterative algorithms
--
Key: MATH-655
URL: https://issues.apache.org/jira/browse/MATH-655
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Minor
Labels: algorithm, events
Attachments: iterative-algorithm.zip
Following the thread [Monitoring iterative
algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
here is a first attempt at defining a general enough framework for iterative
algorithms at large. At the moment, the classes provide support for
* maximum number of iterations
* events handling
** initialization event (prior to entering the main loop),
** iteration event (after completion of one iteration),
** termination event (after termination of the main loop).
These classes do not yet provide support for a stopping criterion.
Some points worth to note
* For the time being, the classes are part of the o.a.c.m.linear package.
* For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws
a {{TooManyEvaluationsException}}. If the proposed new feature is integrated
into CM, then a proper {{TooManyIterationsException}} should be created, from
which the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-655) General framework for iterative algorithms
[
https://issues.apache.org/jira/browse/MATH-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096011#comment-13096011
]
Gilles commented on MATH-655:
-
{quote}
What I'll do, is copy/paste all methods from IterativeAlgorithm into
IterativeLinearSolver, [...]
{quote}
That's what I understood; the monitoring methods will become part of the API of
{{IterativeLinearSolver}} and it will be difficult to remove them (in 3.x).
I've no precise idea about how a general monitoring framework should be
designed but my impression is that a math algorithm class should be (as much as
possible) independent of it. We should probably explore all the various
suggestions that came up during the discussion on the ML before trying anything
lest we want to reinvent the wheel... ;)
General framework for iterative algorithms
--
Key: MATH-655
URL: https://issues.apache.org/jira/browse/MATH-655
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Minor
Labels: algorithm, events
Attachments: iterative-algorithm.zip
Following the thread [Monitoring iterative
algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
here is a first attempt at defining a general enough framework for iterative
algorithms at large. At the moment, the classes provide support for
* maximum number of iterations
* events handling
** initialization event (prior to entering the main loop),
** iteration event (after completion of one iteration),
** termination event (after termination of the main loop).
These classes do not yet provide support for a stopping criterion.
Some points worth to note
* For the time being, the classes are part of the o.a.c.m.linear package.
* For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws
a {{TooManyEvaluationsException}}. If the proposed new feature is integrated
into CM, then a proper {{TooManyIterationsException}} should be created, from
which the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-656) isSparse() method vs marker interfaces
isSparse() method vs marker interfaces Key: MATH-656 URL: https://issues.apache.org/jira/browse/MATH-656 Project: Commons Math Issue Type: Improvement Reporter: Gilles Priority: Trivial Fix For: 3.0 From discussions on the dev ML, it seems that it would be advantageous to introduce a method isSparse() in RealVector and in RealMatrix. For RealVector, it will make sense to use it to select between iterator() and sparseIterator() in methods implemented in that class. We could then remove the SparseRealVector and SparseRealMatrix interfaces. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-620) multiplication of infinity
[
https://issues.apache.org/jira/browse/MATH-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096432#comment-13096432
]
Gilles commented on MATH-620:
-
These
{quote}
Assert.assertEquals(w.getReal(), neginf, 0);
Assert.assertEquals(w.getImaginary(), neginf, 0);
{quote}
behave as intended: all infinities are mapped to a single point at infinity
(chosen to be INF a.k.a. (+inf, +inf)), which IIRC is a way to deal with the
infinite number of infinities along all the directions in the complex plane.
This one
{quote}
Assert.assertEquals(w, z.divide(Complex.ONE.divide(z)));
{quote}
looks wrong indeed.
multiplication of infinity
--
Key: MATH-620
URL: https://issues.apache.org/jira/browse/MATH-620
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Arne Plöse
Priority: Minor
Take the following testcase
{code}
Assert.assertEquals(neginf, inf* neginf, Double.MIN_VALUE); // --Passes
ordinary double
Assert.assertEquals(new Complex(neginf, 0), new Complex(inf, 0).multiply(new
Complex(neginf, 0)));// -- Fail only real parts no imaginary parts
{code}
The outcome of multiply is Complex.INF if one part is infinity.
why not simply compute the multiplication and thats is?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-620) multiplication of infinity
[
https://issues.apache.org/jira/browse/MATH-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096444#comment-13096444
]
Gilles commented on MATH-620:
-
I've create a new ticket for the above: MATH-657
multiplication of infinity
--
Key: MATH-620
URL: https://issues.apache.org/jira/browse/MATH-620
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Arne Plöse
Priority: Minor
Take the following testcase
{code}
Assert.assertEquals(neginf, inf* neginf, Double.MIN_VALUE); // --Passes
ordinary double
Assert.assertEquals(new Complex(neginf, 0), new Complex(inf, 0).multiply(new
Complex(neginf, 0)));// -- Fail only real parts no imaginary parts
{code}
The outcome of multiply is Complex.INF if one part is infinity.
why not simply compute the multiplication and thats is?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-620) multiplication of infinity
[
https://issues.apache.org/jira/browse/MATH-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096444#comment-13096444
]
Gilles edited comment on MATH-620 at 9/2/11 11:04 PM:
--
I've created a new ticket for the above: MATH-657
was (Author: erans):
I've create a new ticket for the above: MATH-657
multiplication of infinity
--
Key: MATH-620
URL: https://issues.apache.org/jira/browse/MATH-620
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Arne Plöse
Priority: Minor
Take the following testcase
{code}
Assert.assertEquals(neginf, inf* neginf, Double.MIN_VALUE); // --Passes
ordinary double
Assert.assertEquals(new Complex(neginf, 0), new Complex(inf, 0).multiply(new
Complex(neginf, 0)));// -- Fail only real parts no imaginary parts
{code}
The outcome of multiply is Complex.INF if one part is infinity.
why not simply compute the multiplication and thats is?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-657) Division by zero
[
https://issues.apache.org/jira/browse/MATH-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096457#comment-13096457
]
Gilles commented on MATH-657:
-
{{divide}} methods fixed in revision 1164756.
However, the change leads to a bug in {{atan}}: See test method
{{testAtanI()}}, at line 575 in ComplexTest.java.
Division by zero
Key: MATH-657
URL: https://issues.apache.org/jira/browse/MATH-657
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Assignee: Gilles
Priority: Minor
Fix For: 3.0
In class {{Complex}}, division by zero always returns NaN. I think that it
should return NaN only when the numerator is also {{ZERO}}, otherwise the
result should be {{INF}}. See
[here|http://en.wikipedia.org/wiki/Riemann_sphere#Arithmetic_operations].
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-657) Division by zero
[
https://issues.apache.org/jira/browse/MATH-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096621#comment-13096621
]
Gilles commented on MATH-657:
-
I've just posted a mail on dev.
IMO, the main argument is consistency. Also with how reals (i.e. {{double}})
work; IIUC, MATH-164 triggered a change for that same reason.
Arne Plöse is a user and [reported|MATH-620] that the previous behaviour was
not fine for him.
I don't think that this one change can have a discernible performance impact.
It might not be necessary to map all {{Complex}} instances that have an
infinite component to a single object. I pointed it as a convenient
justification for fixing a bug (and for not fixing the other two points
reported by Arne in MATH-620).
Division by zero
Key: MATH-657
URL: https://issues.apache.org/jira/browse/MATH-657
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Assignee: Gilles
Priority: Minor
Fix For: 3.0
In class {{Complex}}, division by zero always returns NaN. I think that it
should return NaN only when the numerator is also {{ZERO}}, otherwise the
result should be {{INF}}. See
[here|http://en.wikipedia.org/wiki/Riemann_sphere#Arithmetic_operations].
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-620) multiplication of infinity
[
https://issues.apache.org/jira/browse/MATH-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097118#comment-13097118
]
Gilles commented on MATH-620:
-
It would be helpful that you construct a complete unit test that compares
Commons Math with Octave.
Also, there is a discussion, on the dev ML (cf. thread with subject Complex
division), about how operations in Complex should behave. Mentioning your
problems and requirements might contribute to deciding which way to go.
multiplication of infinity
--
Key: MATH-620
URL: https://issues.apache.org/jira/browse/MATH-620
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Arne Plöse
Priority: Minor
Take the following testcase
{code}
Assert.assertEquals(neginf, inf* neginf, Double.MIN_VALUE); // --Passes
ordinary double
Assert.assertEquals(new Complex(neginf, 0), new Complex(inf, 0).multiply(new
Complex(neginf, 0)));// -- Fail only real parts no imaginary parts
{code}
The outcome of multiply is Complex.INF if one part is infinity.
why not simply compute the multiplication and thats is?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-620) multiplication of infinity
[
https://issues.apache.org/jira/browse/MATH-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097155#comment-13097155
]
Gilles commented on MATH-620:
-
Another bug (IMO) in CM:
{code}
Complex infInf = new Complex(Double.POSITIVE_INFINITY,
Double.POSITIVE_INFINITY);
Assert.assertTrue(infInf.multiply(infInf).isInfinite());
{code}
succeeds, but the formula would have produced NaN in the real part.
Octave computes:
{noformat}
NaN + Infi
{noformat}
Added unit test (with alternative expectation) in revision 1165296.
multiplication of infinity
--
Key: MATH-620
URL: https://issues.apache.org/jira/browse/MATH-620
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Arne Plöse
Priority: Minor
Take the following testcase
{code}
Assert.assertEquals(neginf, inf* neginf, Double.MIN_VALUE); // --Passes
ordinary double
Assert.assertEquals(new Complex(neginf, 0), new Complex(inf, 0).multiply(new
Complex(neginf, 0)));// -- Fail only real parts no imaginary parts
{code}
The outcome of multiply is Complex.INF if one part is infinity.
why not simply compute the multiplication and thats is?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097966#comment-13097966
]
Gilles commented on MATH-621:
-
You are right that there is a bug, but comparing with the original Fortran, I
think that the line should rather read:
{code}
curv = hq.getEntry((j + j * j) / 2);
{code}
Unfortunately, this statement is in a code path that is not explored by the
current unit tests.
By the way, when writing code excerpts here, don't forget to enclose them
within the appropriate tag:
{noformat}
{code}
// Code goes here
{code}
{noformat}
Otherwise it can get scrambled...
For the other line, I have no idea.
BOBYQA is missing in optimization
-
Key: MATH-621
URL: https://issues.apache.org/jira/browse/MATH-621
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dr. Dietmar Wolz
Fix For: 3.0
Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch,
BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip
Original Estimate: 8h
Remaining Estimate: 8h
During experiments with space flight trajectory optimizations I recently
observed, that the direct optimization algorithm BOBYQA
http://plato.asu.edu/ftp/other_software/bobyqa.zip
from Mike Powell is significantly better than the simple Powell algorithm
already in commons.math. It uses significantly lower function calls and is
more reliable for high dimensional problems. You can replace CMA-ES in many
more application cases by BOBYQA than by the simple Powell optimizer.
I would like to contribute a Java port of the algorithm.
I maintained the structure of the original FORTRAN code, so the
code is fast but not very nice.
License status: Michael Powell has sent the agreement via snail mail
- it hasn't arrived yet.
Progress: The attached patch relative to the trunk contains both the
optimizer and the related unit tests - which are all green now.
Performance:
Performance difference (number of function evaluations)
PowellOptimizer / BOBYQA for different test functions (taken from
the unit test of BOBYQA, dimension=13 for most of the
tests.
Rosen = 9350 / 1283
MinusElli = 118 / 59
Elli = 223 / 58
ElliRotated = 8626 / 1379
Cigar = 353 / 60
TwoAxes = 223 / 66
CigTab = 362 / 60
Sphere = 223 / 58
Tablet = 223 / 58
DiffPow = 421 / 928
SsDiffPow = 614 / 219
Ackley = 757 / 97
Rastrigin = 340 / 64
The number for DiffPow should be dicussed with Michael Powell,
I will send him the details.
Open Problems:
Some checkstyle violations because of the original Fortran source:
- Original method comments were copied - doesn't follow javadoc standard
- Multiple variable declarations in one line as in the original source
- Problems related to goto conversions:
gotos not convertible in loops were transated into a finite automata
(switch statement)
no default in switch
fall through from previos case in switch
which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097973#comment-13097973 ] Gilles commented on MATH-621: - Fixed first reported bug in revision 1165656. Thanks. BOBYQA is missing in optimization - Key: MATH-621 URL: https://issues.apache.org/jira/browse/MATH-621 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Fix For: 3.0 Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip, bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip Original Estimate: 8h Remaining Estimate: 8h During experiments with space flight trajectory optimizations I recently observed, that the direct optimization algorithm BOBYQA http://plato.asu.edu/ftp/other_software/bobyqa.zip from Mike Powell is significantly better than the simple Powell algorithm already in commons.math. It uses significantly lower function calls and is more reliable for high dimensional problems. You can replace CMA-ES in many more application cases by BOBYQA than by the simple Powell optimizer. I would like to contribute a Java port of the algorithm. I maintained the structure of the original FORTRAN code, so the code is fast but not very nice. License status: Michael Powell has sent the agreement via snail mail - it hasn't arrived yet. Progress: The attached patch relative to the trunk contains both the optimizer and the related unit tests - which are all green now. Performance: Performance difference (number of function evaluations) PowellOptimizer / BOBYQA for different test functions (taken from the unit test of BOBYQA, dimension=13 for most of the tests. Rosen = 9350 / 1283 MinusElli = 118 / 59 Elli = 223 / 58 ElliRotated = 8626 / 1379 Cigar = 353 / 60 TwoAxes = 223 / 66 CigTab = 362 / 60 Sphere = 223 / 58 Tablet = 223 / 58 DiffPow = 421 / 928 SsDiffPow = 614 / 219 Ackley = 757 / 97 Rastrigin = 340 / 64 The number for DiffPow should be dicussed with Michael Powell, I will send him the details. Open Problems: Some checkstyle violations because of the original Fortran source: - Original method comments were copied - doesn't follow javadoc standard - Multiple variable declarations in one line as in the original source - Problems related to goto conversions: gotos not convertible in loops were transated into a finite automata (switch statement) no default in switch fall through from previos case in switch which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-663) Remove getData in RealVector (package o.a.c.m.linear)
Remove getData in RealVector (package o.a.c.m.linear) --- Key: MATH-663 URL: https://issues.apache.org/jira/browse/MATH-663 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Trivial Fix For: 3.0 getData() is redundant with toArray(). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-664) Replace LUDecompostionImpl with QRDecompositionImpl in AbstractLeastSquaresOptimizer
Replace LUDecompostionImpl with QRDecompositionImpl in AbstractLeastSquaresOptimizer -- Key: MATH-664 URL: https://issues.apache.org/jira/browse/MATH-664 Project: Commons Math Issue Type: Improvement Reporter: Gilles Assignee: Gilles Priority: Minor Fix For: 3.0 In some cases, the getCovariances() method throws a SingularMatrixException. This can be avoided by using QR instead of LU decomposition. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13098967#comment-13098967
]
Gilles commented on MATH-621:
-
{quote}
I have written a lot of symmetric matrix code, and it ALWAYS outperforms any
Java library I can find, simply because I use the proper 1D array form of
storage.
{quote}
The point is that this issue deals with an optimization algorithm; not how to
properly store a symmetric matrix. Algorithms that _use_ matrices should not
have to re-implement matrix operations.
A matrix represented by a ...Matrix object certainly will help in
understanding what the BOBYQA code does and how to further adapt it to the Java
programming style.
Your knowledge might be a useful contribution (on the dev ML) to the
discussion on how to improve the design and efficiency of the various matrix
classes. Bringing some of your concrete arguments could lead to the creation of
an efficient SymmetricMatrix to be used in this algorithm.
BOBYQA is missing in optimization
-
Key: MATH-621
URL: https://issues.apache.org/jira/browse/MATH-621
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Dr. Dietmar Wolz
Fix For: 3.0
Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch,
BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
bobyqa_convert.pl, bobyqaoptimizer0.4.zip, bobyqav0.3.zip
Original Estimate: 8h
Remaining Estimate: 8h
During experiments with space flight trajectory optimizations I recently
observed, that the direct optimization algorithm BOBYQA
http://plato.asu.edu/ftp/other_software/bobyqa.zip
from Mike Powell is significantly better than the simple Powell algorithm
already in commons.math. It uses significantly lower function calls and is
more reliable for high dimensional problems. You can replace CMA-ES in many
more application cases by BOBYQA than by the simple Powell optimizer.
I would like to contribute a Java port of the algorithm.
I maintained the structure of the original FORTRAN code, so the
code is fast but not very nice.
License status: Michael Powell has sent the agreement via snail mail
- it hasn't arrived yet.
Progress: The attached patch relative to the trunk contains both the
optimizer and the related unit tests - which are all green now.
Performance:
Performance difference (number of function evaluations)
PowellOptimizer / BOBYQA for different test functions (taken from
the unit test of BOBYQA, dimension=13 for most of the
tests.
Rosen = 9350 / 1283
MinusElli = 118 / 59
Elli = 223 / 58
ElliRotated = 8626 / 1379
Cigar = 353 / 60
TwoAxes = 223 / 66
CigTab = 362 / 60
Sphere = 223 / 58
Tablet = 223 / 58
DiffPow = 421 / 928
SsDiffPow = 614 / 219
Ackley = 757 / 97
Rastrigin = 340 / 64
The number for DiffPow should be dicussed with Michael Powell,
I will send him the details.
Open Problems:
Some checkstyle violations because of the original Fortran source:
- Original method comments were copied - doesn't follow javadoc standard
- Multiple variable declarations in one line as in the original source
- Problems related to goto conversions:
gotos not convertible in loops were transated into a finite automata
(switch statement)
no default in switch
fall through from previos case in switch
which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13099632#comment-13099632 ] Gilles commented on MATH-650: - IIUC, only the initializations needed by a method call are performed. Thus max has become fast because it doesn't need any of those data arrays. For those methods that need the data, one has to compare the startup times between computing the data and loading precomputed data. For methods that only need some of the data, the time gain might not be worth trailing the huge precomputed arrays. If several calls are made to methods that need most of the data arrays, the initialization time will be increasingly negligible (with respect to the useful application running time). Which again renders the precomputed arrays unnecessary. So, in summary, lazy initialization is very nice, especially for short-lived applications that happen to call methods that don't need the data at all. It's still nice for applications that happen to need only part of the data. It's useless for applications that will need all the data arrays. (But it probably does not hurt.) However, I still don't see an advantage in storing precomputed values. I don't think that it should be adopted just for a toy application that would call a math function once and exit. 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 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13100221#comment-13100221
]
Gilles commented on MATH-650:
-
{quote}
In my tests, I found that pre-calculating the data is about twice as fast as
calculating it in the static block.
That seems a worthwhile improvement to me.
{quote}
Could you provide the absolute numbers?
What I contend is that we should not base this change on an extremely unlikely
use-case: Launching a JVM for an application that will run for a few seconds of
is very costly, and the additional cost of initializing FastMath must be
compared to the overall initialization time.
What I said in the previous comment is that IOD is _fine_ to use, if only
because it will avoid unnecessary memory usage, which might benefit
light-weight applications (_light-weight_ is a much more interesting use-case
than _short-lived_).
I don't like having tables that huge in the source code just for the sake of
saving a few seconds.
(If the data were coming from an external source or were really taking a lot of
time to compute, that would be a necessity. But not in this case.)
So, could you please post the timings (also, the total initialization time of
the JVM) of
* using neither IOD nor preset arrays
* using IOD, but no preset arrays
* using IOD with preset arrays
Thanks in advance.
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
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
