[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 ] Dr. Dietmar Wolz updated MATH-621: -- Attachment: BOBYQAOptimizer.java.patch remove unused variables Would you take that one? patch related to remove unused variables and remove unused imports 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=13086976#comment-13086976
]
Dr. Dietmar Wolz commented on MATH-621:
---
I checked out immediately before producing the patch immediately before
attaching it here, strange that
there was a conflict. Is it a good idea to maintain a import order inconsistent
with organize imports in
eclipse? This makes organize imports useless. But ok, so should I again
produce a patch without
the imports? But I cannot avoid a conflict if you check in just as I produce
the
patch. By the way: such situations
are much easier to handle using git, but this is no option here.
- Ursprüngliche Mail
Von: Gilles (JIRA) j...@apache.org
An: drdietmarw...@yahoo.de
Gesendet: Donnerstag, den 18. August 2011, 13:42:27 Uhr
Betreff: [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=13086967#comment-13086967
]
Gilles commented on MATH-621:
-
The patch does not apply cleanly on the last revision. Are you submitted to the
commits ML?
If not, we should really _coordinate_. In my mind, that meant that while
waiting
for your answer to my questions here, I can continue updating the code...
{quote}
remove unused imports
{quote}
Please don't do that. Or in a separate patch. Or not with Eclipse: Because it
reordered the import lines, out of 12 changed lines, only 2 were really
suppressing unused import statements.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
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=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-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087006#comment-13087006 ] Dr. Dietmar Wolz commented on MATH-621: --- So you want to force Eclipse users not to use the organize import functionality? What is the advantage for the non-Eclipse-users? Are there other tools with organize import functionality which produce a different order of imports? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira 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=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] [Resolved] (MATH-593) 3D SubLine
[ https://issues.apache.org/jira/browse/MATH-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-593. Resolution: Fixed Fix Version/s: (was: 3.1) 3.0 Fixed in subversion repository as of r1159353 3D SubLine -- Key: MATH-593 URL: https://issues.apache.org/jira/browse/MATH-593 Project: Commons Math Issue Type: New Feature Reporter: Curtis Jensen Priority: Minor Labels: Geometry, math Fix For: 3.0 Original Estimate: 24h Remaining Estimate: 24h Add a SubLine class in the org.apache.commons.math.geometry.euclidean.threed package (similar to 2D and 3D lines). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-641) Implement distance methods on 2D and 3D Lines as well as Line Segments.
[ https://issues.apache.org/jira/browse/MATH-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087204#comment-13087204 ] Luc Maisonobe commented on MATH-641: 2D lines are hyperplanes, hence they do implement the getOffset method, which is basically a signed distance. So if you have point p and line l, the distance between p and l is FastMath.abs(l.getOffset(p)). The sign is in fact chosen to have negative offsets on the left half place and positive offsets on the right half-plane. Considering segments, I'm not sure what you want. If we don't consider the endpoints but only the support line, we can retrieve this support line by subLine.getHyperplane() (because sub-lines implement SubHyperplane). If we consider the endpoints, the computation is much more complex, as it is basically the distance to the support line if the closest line point is in the segment, or it is min(d(P, Ei)) where Ei are all the endpoints of the segment. Are the current methods sufficient for your needs and if not what are exactly your needs ? Implement distance methods on 2D and 3D Lines as well as Line Segments. --- Key: MATH-641 URL: https://issues.apache.org/jira/browse/MATH-641 Project: Commons Math Issue Type: New Feature Reporter: Curtis Jensen Priority: Minor Fix For: 3.1 Original Estimate: 4h Remaining Estimate: 4h Implement a method that calculates the distance from a point to 3D and 2D lines and line segements (similar to what already exists in the 3D Line class). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CHAIN-53) Global Update of Chain - Generics, JDK 1.5, Update Dependency Versions
[
https://issues.apache.org/jira/browse/CHAIN-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elijah Zupancic updated CHAIN-53:
-
Attachment: v2_patch_2011-08-18.diff
This patch supersedes the previous patch. It incorporates changes that are a
result of fixing issues reported by checkstyle.
Global Update of Chain - Generics, JDK 1.5, Update Dependency Versions
--
Key: CHAIN-53
URL: https://issues.apache.org/jira/browse/CHAIN-53
Project: Commons Chain
Issue Type: Improvement
Reporter: Elijah Zupancic
Labels: newbie, patch
Attachments: v2_patch.diff, v2_patch_2011-08-18.diff
As posted in the mailing list, I've done this work outside of an offical
branch.
In this patch:
* Global upgrade to the JDK 1.5
* Added @Override annotations
* Upgraded to the Servlet 2.5 API
* Upgraded to the Faces 2.1 API
* Upgraded to the Portlet 2.0 API
* Upgraded the Maven Parent POM version
* Added generics support to Command so that Command's API looks like:
public interface CommandT extends Context {
...
boolean execute(T context) throws Exception;
}
The only incompatibility with the existing API is in:
org.apache.commons.chain.web.servlet.ServletHeaderValuesMap on line 97.
Previously the API was returning SetEntryString, EnumerationString when
by all indications it actually should have been returning SetEntryString,
String[]. I believe that I fixed a previously undiscovered bug here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CHAIN-53) Global Update of Chain - Generics, JDK 1.5, Update Dependency Versions
[
https://issues.apache.org/jira/browse/CHAIN-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elijah Zupancic updated CHAIN-53:
-
Attachment: (was: v2_patch.diff)
Global Update of Chain - Generics, JDK 1.5, Update Dependency Versions
--
Key: CHAIN-53
URL: https://issues.apache.org/jira/browse/CHAIN-53
Project: Commons Chain
Issue Type: Improvement
Reporter: Elijah Zupancic
Labels: newbie, patch
Attachments: v2_patch_2011-08-18.diff
As posted in the mailing list, I've done this work outside of an offical
branch.
In this patch:
* Global upgrade to the JDK 1.5
* Added @Override annotations
* Upgraded to the Servlet 2.5 API
* Upgraded to the Faces 2.1 API
* Upgraded to the Portlet 2.0 API
* Upgraded the Maven Parent POM version
* Added generics support to Command so that Command's API looks like:
public interface CommandT extends Context {
...
boolean execute(T context) throws Exception;
}
The only incompatibility with the existing API is in:
org.apache.commons.chain.web.servlet.ServletHeaderValuesMap on line 97.
Previously the API was returning SetEntryString, EnumerationString when
by all indications it actually should have been returning SetEntryString,
String[]. I believe that I fixed a previously undiscovered bug 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
