[jira] Commented: (MATH-439) Refactoring of solvers (package "analysis.solvers")
[
https://issues.apache.org/jira/browse/MATH-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933268#action_12933268
]
Gilles commented on MATH-439:
-
And another regression (maybe).
{noformat}
Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.271 sec <<<
FAILURE!
testCircleFitting(org.apache.commons.math.optimization.general.NonLinearConjugateGradientOptimizerTest)
Time elapsed: 0.012 sec <<< FAILURE!
java.lang.AssertionError: expected:<69.960161753> but was:<5.9097119121754055E9>
at org.junit.Assert.fail(Assert.java:74)
at org.junit.Assert.failNotEquals(Assert.java:448)
at org.junit.Assert.assertEquals(Assert.java:315)
at org.junit.Assert.assertEquals(Assert.java:346)
at
org.apache.commons.math.optimization.general.NonLinearConjugateGradientOptimizerTest.testCircleFitting(NonLinearConjugateGradientOptimizerTest.java:355)
[...]
{noformat}
The problem is at those lines:
{code}
NonLinearConjugateGradientOptimizer optimizer =
new
NonLinearConjugateGradientOptimizer(ConjugateGradientFormula.POLAK_RIBIERE);
optimizer.setMaxEvaluations(100);
optimizer.setConvergenceChecker(new SimpleScalarValueChecker(1.0e-30,
1.0e-30)); // <--- here
UnivariateRealSolver solver = new BrentSolver(1e-15, 1e-13);
optimizer.setLineSearchSolver(solver);
RealPointValuePair optimum =
optimizer.optimize(circle, GoalType.MINIMIZE, new double[] { 98.680, 47.345
});
{code}
Now, when, in the above, the line marked "<--- here" is commented out, the test
passes.
However, if the line is left in but another solver is used (I tried
{{BisectionSolver}} and {{SecantSolver}}), the test also passes!
Does someone have an idea of what could be going on?
> Refactoring of solvers (package "analysis.solvers")
> ---
>
> Key: MATH-439
> URL: https://issues.apache.org/jira/browse/MATH-439
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Priority: Minor
> Fix For: 3.0
>
> Attachments: AbstractUnivariateRealSolver.java
>
>
> The classes in package "analysis.solvers" could be refactored similarly to
> what was done for package {{optimization}}.
> * Replace {{MaxIterationsExceededException}} with
> {{TooManyEvaluationsException}}:
> Apart from the class {{MaxIterationsExceededException}} being deprecated,
> this approach makes it difficult to compare different algorithms: While the
> concept of iteration is algorithm-dependent, the user is probably mostly
> interested in the number of function evaluations.
> * Implement the method {{solve}} in the base class
> ({{UnivariateRealSolverImpl}}) and define an abstract method {{doSolve}} to
> be implemented in derived classes. This method would then use a new
> {{computeObjectiveFunction}} method that will take care of the counting of
> the function evaluations.
> * Remove "protected" fields (the root is unnecessary since it is returned by
> {{solve}}). Arguingly the function value is also not very useful (as we know
> what it should be), except for debugging purposes (in which case, it might
> not be a problem to call the function's {{value}} method once more).
> * Remove the tolerance setter (accuracy) and make the corresponding fields
> "final".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (EMAIL-101) Specified Content-ID is not used when embedding a File object in an HtmlEmail
[ https://issues.apache.org/jira/browse/EMAIL-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Starodub updated EMAIL-101: -- Attachment: HtmlEmailTest.patch Attaching a patch that includes a regression test for making sure the returned CID is the same as the user-specified CID. > Specified Content-ID is not used when embedding a File object in an HtmlEmail > - > > Key: EMAIL-101 > URL: https://issues.apache.org/jira/browse/EMAIL-101 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.0, 1.1, 1.2 >Reporter: Andrew Starodub > Fix For: 1.3 > > Attachments: HtmlEmail.patch, HtmlEmailTest.patch > > > When calling the .embed(File file, String cid) method on HtmlEmail, the cid > argument is never used within the method. > Consequently, even when the user specifies a Content-ID for the embedded > File, a new randomly generated Content-ID is generated every time. > I believe this is as simple as changing the last line of .embed(File file, > String cid) from: > return embed(new FileDataSource(file), file.getName()); > To: > return embed(new FileDataSource(file), file.getName(), cid); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (EMAIL-101) Specified Content-ID is not used when embedding a File object in an HtmlEmail
[ https://issues.apache.org/jira/browse/EMAIL-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Starodub updated EMAIL-101: -- Attachment: HtmlEmail.patch Attaching patch file to correct return line in HtmlEmail.embed(File file, String cid) > Specified Content-ID is not used when embedding a File object in an HtmlEmail > - > > Key: EMAIL-101 > URL: https://issues.apache.org/jira/browse/EMAIL-101 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.0, 1.1, 1.2 >Reporter: Andrew Starodub > Fix For: 1.3 > > Attachments: HtmlEmail.patch > > > When calling the .embed(File file, String cid) method on HtmlEmail, the cid > argument is never used within the method. > Consequently, even when the user specifies a Content-ID for the embedded > File, a new randomly generated Content-ID is generated every time. > I believe this is as simple as changing the last line of .embed(File file, > String cid) from: > return embed(new FileDataSource(file), file.getName()); > To: > return embed(new FileDataSource(file), file.getName(), cid); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EMAIL-101) Specified Content-ID is not used when embedding a File object in an HtmlEmail
Specified Content-ID is not used when embedding a File object in an HtmlEmail - Key: EMAIL-101 URL: https://issues.apache.org/jira/browse/EMAIL-101 Project: Commons Email Issue Type: Bug Affects Versions: 1.2, 1.1, 1.0 Reporter: Andrew Starodub Fix For: 1.3 When calling the .embed(File file, String cid) method on HtmlEmail, the cid argument is never used within the method. Consequently, even when the user specifies a Content-ID for the embedded File, a new randomly generated Content-ID is generated every time. I believe this is as simple as changing the last line of .embed(File file, String cid) from: return embed(new FileDataSource(file), file.getName()); To: return embed(new FileDataSource(file), file.getName(), cid); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-439) Refactoring of solvers (package "analysis.solvers")
[
https://issues.apache.org/jira/browse/MATH-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933211#action_12933211
]
Gilles commented on MATH-439:
-
Another failing test:
{noformat}
testEvents(org.apache.commons.math.ode.nonstiff.DormandPrince853IntegratorTest)
Time elapsed: 0.001 sec <<< FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at
org.apache.commons.math.ode.nonstiff.DormandPrince853IntegratorTest.testEvents(DormandPrince853IntegratorTest.java:238)
[...]
{noformat}
Line 238 in the test code is:
{code}
assertTrue(handler.getMaximalValueError() < 5.0e-8);
{code}
> Refactoring of solvers (package "analysis.solvers")
> ---
>
> Key: MATH-439
> URL: https://issues.apache.org/jira/browse/MATH-439
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Priority: Minor
> Fix For: 3.0
>
> Attachments: AbstractUnivariateRealSolver.java
>
>
> The classes in package "analysis.solvers" could be refactored similarly to
> what was done for package {{optimization}}.
> * Replace {{MaxIterationsExceededException}} with
> {{TooManyEvaluationsException}}:
> Apart from the class {{MaxIterationsExceededException}} being deprecated,
> this approach makes it difficult to compare different algorithms: While the
> concept of iteration is algorithm-dependent, the user is probably mostly
> interested in the number of function evaluations.
> * Implement the method {{solve}} in the base class
> ({{UnivariateRealSolverImpl}}) and define an abstract method {{doSolve}} to
> be implemented in derived classes. This method would then use a new
> {{computeObjectiveFunction}} method that will take care of the counting of
> the function evaluations.
> * Remove "protected" fields (the root is unnecessary since it is returned by
> {{solve}}). Arguingly the function value is also not very useful (as we know
> what it should be), except for debugging purposes (in which case, it might
> not be a problem to call the function's {{value}} method once more).
> * Remove the tolerance setter (accuracy) and make the corresponding fields
> "final".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-439) Refactoring of solvers (package "analysis.solvers")
[
https://issues.apache.org/jira/browse/MATH-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933203#action_12933203
]
Gilles commented on MATH-439:
-
Changes are again cascading to faraway places.
This issue led to changes in {{BrentSolver}} so that the loop is now
evaluation-based (instead iteration-based) and it now throws
{{TooManyEvaluationsException}}.
The {{HighamHall54IntegratorTest}} test fails:
{noformat}
testEventsNoConvergence(org.apache.commons.math.ode.nonstiff.HighamHall54IntegratorTest)
Time elapsed: 0.006 sec <<< ERROR!
org.apache.commons.math.exception.TooManyEvaluationsException: maximal count
(3) exceeded: evaluations
at
org.apache.commons.math.analysis.solvers.BaseAbstractUnivariateRealSolver.incrementEvaluationCount(BaseAbstractUnivariateRealSolver.java:298)
at
org.apache.commons.math.analysis.solvers.BaseAbstractUnivariateRealSolver.computeObjectiveValue(BaseAbstractUnivariateRealSolver.java:158)
at
org.apache.commons.math.analysis.solvers.BrentSolver.solve(BrentSolver.java:203)
at
org.apache.commons.math.analysis.solvers.BrentSolver.doSolve(BrentSolver.java:89)
at
org.apache.commons.math.analysis.solvers.BaseAbstractUnivariateRealSolver.solve(BaseAbstractUnivariateRealSolver.java:195)
at
org.apache.commons.math.analysis.solvers.BaseAbstractUnivariateRealSolver.solve(BaseAbstractUnivariateRealSolver.java:200)
at
org.apache.commons.math.ode.events.EventState.evaluateStep(EventState.java:260)
at
org.apache.commons.math.ode.events.CombinedEventsManager.evaluateStep(CombinedEventsManager.java:149)
at
org.apache.commons.math.ode.nonstiff.EmbeddedRungeKuttaIntegrator.integrate(EmbeddedRungeKuttaIntegrator.java:293)
at
org.apache.commons.math.ode.nonstiff.HighamHall54IntegratorTest.testEventsNoConvergence(HighamHall54IntegratorTest.java:267)
[...]
{noformat}
Because of the interface change in {{BrentSolver}}, the new set of lines
(around line 260) in "EventState.java" are:
{code}
final BrentSolver solver = new BrentSolver(convergence);
solver.setMaxEvaluations(maxIterationCount);
final double root = (ta <= tb) ? solver.solve(f, ta, tb) : solver.solve(f, tb,
ta);
{code}
Obviously, the new exception is thrown here and is never caught. I don't know
what else to change in order to get the same behaviour as before...
Expert advice welcome!
> Refactoring of solvers (package "analysis.solvers")
> ---
>
> Key: MATH-439
> URL: https://issues.apache.org/jira/browse/MATH-439
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Priority: Minor
> Fix For: 3.0
>
> Attachments: AbstractUnivariateRealSolver.java
>
>
> The classes in package "analysis.solvers" could be refactored similarly to
> what was done for package {{optimization}}.
> * Replace {{MaxIterationsExceededException}} with
> {{TooManyEvaluationsException}}:
> Apart from the class {{MaxIterationsExceededException}} being deprecated,
> this approach makes it difficult to compare different algorithms: While the
> concept of iteration is algorithm-dependent, the user is probably mostly
> interested in the number of function evaluations.
> * Implement the method {{solve}} in the base class
> ({{UnivariateRealSolverImpl}}) and define an abstract method {{doSolve}} to
> be implemented in derived classes. This method would then use a new
> {{computeObjectiveFunction}} method that will take care of the counting of
> the function evaluations.
> * Remove "protected" fields (the root is unnecessary since it is returned by
> {{solve}}). Arguingly the function value is also not very useful (as we know
> what it should be), except for debugging purposes (in which case, it might
> not be a problem to call the function's {{value}} method once more).
> * Remove the tolerance setter (accuracy) and make the corresponding fields
> "final".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-437) Kolmogorov Smirnov Distribution
[ https://issues.apache.org/jira/browse/MATH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikkel Meyer Andersen updated MATH-437: --- Attachment: (was: KolmogorovSmirnovDistribution.java) > Kolmogorov Smirnov Distribution > --- > > Key: MATH-437 > URL: https://issues.apache.org/jira/browse/MATH-437 > Project: Commons Math > Issue Type: New Feature >Reporter: Mikkel Meyer Andersen >Assignee: Mikkel Meyer Andersen >Priority: Minor > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Kolmogorov-Smirnov test (see [1]) is used to test if one sample against a > known probability density functions or if two samples are from the same > distribution. To evaluate the test statistic, the Kolmogorov-Smirnov > distribution is used. Quite good asymptotics exist for the one-sided test, > but it's more difficult for the two-sided test. > [1]: http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-437) Kolmogorov Smirnov Distribution
[ https://issues.apache.org/jira/browse/MATH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933166#action_12933166 ] Richard Simard commented on MATH-437: - If you used the same x in all 3 cases, I believe there is a bug in your exact and not exact codes because you get only 2 decimal digits of precision. > Kolmogorov Smirnov Distribution > --- > > Key: MATH-437 > URL: https://issues.apache.org/jira/browse/MATH-437 > Project: Commons Math > Issue Type: New Feature >Reporter: Mikkel Meyer Andersen >Assignee: Mikkel Meyer Andersen >Priority: Minor > Attachments: KolmogorovSmirnovDistribution.java > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Kolmogorov-Smirnov test (see [1]) is used to test if one sample against a > known probability density functions or if two samples are from the same > distribution. To evaluate the test statistic, the Kolmogorov-Smirnov > distribution is used. Quite good asymptotics exist for the one-sided test, > but it's more difficult for the two-sided test. > [1]: http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-437) Kolmogorov Smirnov Distribution
[
https://issues.apache.org/jira/browse/MATH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933161#action_12933161
]
Mikkel Meyer Andersen commented on MATH-437:
Richard,
Thanks for your knowledgeable comment. To quote you:
{quote}"The argument x that you used in the Simard-L'écuyer program is not the
same that you used for the other two programs."{quote}
I'm not sure what you mean by that? Which argument should I then use to expect
the same result?
> Kolmogorov Smirnov Distribution
> ---
>
> Key: MATH-437
> URL: https://issues.apache.org/jira/browse/MATH-437
> Project: Commons Math
> Issue Type: New Feature
>Reporter: Mikkel Meyer Andersen
>Assignee: Mikkel Meyer Andersen
>Priority: Minor
> Attachments: KolmogorovSmirnovDistribution.java
>
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> Kolmogorov-Smirnov test (see [1]) is used to test if one sample against a
> known probability density functions or if two samples are from the same
> distribution. To evaluate the test statistic, the Kolmogorov-Smirnov
> distribution is used. Quite good asymptotics exist for the one-sided test,
> but it's more difficult for the two-sided test.
> [1]: http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-442) CMA evolution strategy is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933089#action_12933089 ] Luc Maisonobe commented on MATH-442: Thanks for the explanation of the CMA-ES properties. The subscribing information for the various commons list is here: [http://commons.apache.org/mail-lists.html] Beware that these lists are shared among all commons components. In order to help filtering, put a \[math\] marker in the subject line > CMA evolution strategy is missing in optimization > - > > Key: MATH-442 > URL: https://issues.apache.org/jira/browse/MATH-442 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dr. Dietmar Wolz > Original Estimate: 48h > Remaining Estimate: 48h > > Recently I implemented the optimization algorithm CMA-ES based on > org.apache.commons.math.linear and used it for the GTOC5 global trajectory > optimization contest http://gtoc5.math.msu.su/. It implements the > MultivariateRealOptimizer interface and would nicely fit into the > org.apache.commons.math.optimization package. The original author of CMA-ES > (Nikolaus Hansen) volunteered to support me (proof-reading + testing) in the > creation of a CMA-ES contribution for commons.math. > The CMA evolution strategy http://www.lri.fr/~hansen/cmaesintro.html is a > very powerful algorithm for difficult non-linear non-convex optimization > problems in continuous domain. See http://www.lri.fr/~hansen/cec2005.html for > a comparison chart. If there is interest I will create a patch including the > proposed Implementation for evaluation. It seems we would need an additional > sub-package - org.apache.commons.math.optimization.evolutionary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-442) CMA evolution strategy is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933083#action_12933083 ] Nikolaus Hansen commented on MATH-442: -- I think the CMA-ES fits fine into to direct category (but I am familiar with the meaning of the word direct search, I don't assume everyone is). Nelder-Mead and CMA-ES are similar in that they do not need derivatives and they do not even need function values: they are comparison based and only use a ranking between a number of candidate solutions. Moreover, Nelder-Mead and CMA-ES share all their invariance properties (not many other optimization algorithms do). Being rank-based implies invariance under monotonous transformations of the objective function value, but there are others (e.g. invariance under coordinate system changes). I believe these are important properties, also from the application viewpoint. The main conceptional different to Nelder-Mead: CMA-ES is stochastic (randomized, if you like). The main practical difference: CMA-ES works also in large dimension and there is a control parameter for tuning the locality of search. You could have an elaborate discussion whether CMA-ES estimates a gradient. My take on it: methods that move opposite to the gradient will regularly fail anyway. I also find it strange that algorithms in the general category are in fact less general. Where can I subscribe to the list? > CMA evolution strategy is missing in optimization > - > > Key: MATH-442 > URL: https://issues.apache.org/jira/browse/MATH-442 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dr. Dietmar Wolz > Original Estimate: 48h > Remaining Estimate: 48h > > Recently I implemented the optimization algorithm CMA-ES based on > org.apache.commons.math.linear and used it for the GTOC5 global trajectory > optimization contest http://gtoc5.math.msu.su/. It implements the > MultivariateRealOptimizer interface and would nicely fit into the > org.apache.commons.math.optimization package. The original author of CMA-ES > (Nikolaus Hansen) volunteered to support me (proof-reading + testing) in the > creation of a CMA-ES contribution for commons.math. > The CMA evolution strategy http://www.lri.fr/~hansen/cmaesintro.html is a > very powerful algorithm for difficult non-linear non-convex optimization > problems in continuous domain. See http://www.lri.fr/~hansen/cec2005.html for > a comparison chart. If there is interest I will create a patch including the > proposed Implementation for evaluation. It seems we would need an additional > sub-package - org.apache.commons.math.optimization.evolutionary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-437) Kolmogorov Smirnov Distribution
[ https://issues.apache.org/jira/browse/MATH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933077#action_12933077 ] Richard Simard commented on MATH-437: - http://www.mail-archive.com/issues@commons.apache.org/msg15829.html F(n, x) = F(200, 0.03): Lecuyer (2.0 ms.) = 0.012916146481628863 KolmogorovSmirnovDistribution exact (51902.0 ms.) = 0.012149763742041911 KolmogorovSmirnovDistribution !exact (9.0 ms.) = 0.012149763742041922 The argument x that you used in the Simard-L'écuyer program is not the same that you used for the other two programs. Of course you then get very different results. If I compute exactly in Mathematica, I obtain F(200, 0.03) = 0.0129161464816289 which is very different than your exact results above and agrees well with our program. = Richard Simard Laboratoire de simulation et d'optimisation Université de Montréal, IRO > Kolmogorov Smirnov Distribution > --- > > Key: MATH-437 > URL: https://issues.apache.org/jira/browse/MATH-437 > Project: Commons Math > Issue Type: New Feature >Reporter: Mikkel Meyer Andersen >Assignee: Mikkel Meyer Andersen >Priority: Minor > Attachments: KolmogorovSmirnovDistribution.java > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Kolmogorov-Smirnov test (see [1]) is used to test if one sample against a > known probability density functions or if two samples are from the same > distribution. To evaluate the test statistic, the Kolmogorov-Smirnov > distribution is used. Quite good asymptotics exist for the one-sided test, > but it's more difficult for the two-sided test. > [1]: http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-442) CMA evolution strategy is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932961#action_12932961 ] Dr. Dietmar Wolz commented on MATH-442: --- Will subscribe today > CMA evolution strategy is missing in optimization > - > > Key: MATH-442 > URL: https://issues.apache.org/jira/browse/MATH-442 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dr. Dietmar Wolz > Original Estimate: 48h > Remaining Estimate: 48h > > Recently I implemented the optimization algorithm CMA-ES based on > org.apache.commons.math.linear and used it for the GTOC5 global trajectory > optimization contest http://gtoc5.math.msu.su/. It implements the > MultivariateRealOptimizer interface and would nicely fit into the > org.apache.commons.math.optimization package. The original author of CMA-ES > (Nikolaus Hansen) volunteered to support me (proof-reading + testing) in the > creation of a CMA-ES contribution for commons.math. > The CMA evolution strategy http://www.lri.fr/~hansen/cmaesintro.html is a > very powerful algorithm for difficult non-linear non-convex optimization > problems in continuous domain. See http://www.lri.fr/~hansen/cec2005.html for > a comparison chart. If there is interest I will create a patch including the > proposed Implementation for evaluation. It seems we would need an additional > sub-package - org.apache.commons.math.optimization.evolutionary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-442) CMA evolution strategy is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932955#action_12932955 ] Luc Maisonobe commented on MATH-442: I agree the package name does not fit anymore with its content. I suggest to move this discussion to the dev mailing list as it is easier for all persons interested in commons-math to follow it. Dietmar, are you already subscribed to this list ? > CMA evolution strategy is missing in optimization > - > > Key: MATH-442 > URL: https://issues.apache.org/jira/browse/MATH-442 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dr. Dietmar Wolz > Original Estimate: 48h > Remaining Estimate: 48h > > Recently I implemented the optimization algorithm CMA-ES based on > org.apache.commons.math.linear and used it for the GTOC5 global trajectory > optimization contest http://gtoc5.math.msu.su/. It implements the > MultivariateRealOptimizer interface and would nicely fit into the > org.apache.commons.math.optimization package. The original author of CMA-ES > (Nikolaus Hansen) volunteered to support me (proof-reading + testing) in the > creation of a CMA-ES contribution for commons.math. > The CMA evolution strategy http://www.lri.fr/~hansen/cmaesintro.html is a > very powerful algorithm for difficult non-linear non-convex optimization > problems in continuous domain. See http://www.lri.fr/~hansen/cec2005.html for > a comparison chart. If there is interest I will create a patch including the > proposed Implementation for evaluation. It seems we would need an additional > sub-package - org.apache.commons.math.optimization.evolutionary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-442) CMA evolution strategy is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932951#action_12932951
]
Gilles commented on MATH-442:
-
So, as I said, it was perhaps a bad choice of the package names. From a usage
perspective it is more useful to make categories based on the properties of the
objective function rather than on the heart of the algorithms.
I think that the interfaces should be based on familiarity (e.g. identically
named methods) and ease of use, and that implementations similarities should be
shared through inheritance.
What do you propose instead of the current {{direct}} and {{general}} package
names?
> CMA evolution strategy is missing in optimization
> -
>
> Key: MATH-442
> URL: https://issues.apache.org/jira/browse/MATH-442
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Dr. Dietmar Wolz
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Recently I implemented the optimization algorithm CMA-ES based on
> org.apache.commons.math.linear and used it for the GTOC5 global trajectory
> optimization contest http://gtoc5.math.msu.su/. It implements the
> MultivariateRealOptimizer interface and would nicely fit into the
> org.apache.commons.math.optimization package. The original author of CMA-ES
> (Nikolaus Hansen) volunteered to support me (proof-reading + testing) in the
> creation of a CMA-ES contribution for commons.math.
> The CMA evolution strategy http://www.lri.fr/~hansen/cmaesintro.html is a
> very powerful algorithm for difficult non-linear non-convex optimization
> problems in continuous domain. See http://www.lri.fr/~hansen/cec2005.html for
> a comparison chart. If there is interest I will create a patch including the
> proposed Implementation for evaluation. It seems we would need an additional
> sub-package - org.apache.commons.math.optimization.evolutionary.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-442) CMA evolution strategy is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932936#action_12932936 ] Dr. Dietmar Wolz commented on MATH-442: --- http://cm.bell-labs.com/cm/cs/doc/96/4-02.ps.gz states that a method should not 'in its heart' develop an approximate gradient as for instance quasi-Newton methods. I don't think this qualifies CMA-ES as 'direct' method. "Adaptation of the covariance matrix amounts to learning a second order model of the underlying objective function similar to the approximation of the inverse Hessian matrix in the Quasi-Newton method in classical optimization ". > CMA evolution strategy is missing in optimization > - > > Key: MATH-442 > URL: https://issues.apache.org/jira/browse/MATH-442 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dr. Dietmar Wolz > Original Estimate: 48h > Remaining Estimate: 48h > > Recently I implemented the optimization algorithm CMA-ES based on > org.apache.commons.math.linear and used it for the GTOC5 global trajectory > optimization contest http://gtoc5.math.msu.su/. It implements the > MultivariateRealOptimizer interface and would nicely fit into the > org.apache.commons.math.optimization package. The original author of CMA-ES > (Nikolaus Hansen) volunteered to support me (proof-reading + testing) in the > creation of a CMA-ES contribution for commons.math. > The CMA evolution strategy http://www.lri.fr/~hansen/cmaesintro.html is a > very powerful algorithm for difficult non-linear non-convex optimization > problems in continuous domain. See http://www.lri.fr/~hansen/cec2005.html for > a comparison chart. If there is interest I will create a patch including the > proposed Implementation for evaluation. It seems we would need an additional > sub-package - org.apache.commons.math.optimization.evolutionary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LOGGING-140) Request of source code of
[ https://issues.apache.org/jira/browse/LOGGING-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved LOGGING-140. -- Resolution: Invalid There is no such product as Commons Logging Log4Net. Perhaps you meant Apache log4Net? See: http://logging.apache.org/log4net/index.html and follow the links. > Request of source code of > -- > > Key: LOGGING-140 > URL: https://issues.apache.org/jira/browse/LOGGING-140 > Project: Commons Logging > Issue Type: Wish > Environment: .Net 2008 >Reporter: Jothi Rmasamy > Original Estimate: 1h > Remaining Estimate: 1h > > Can you please tell us the from where we can download the > common.Logging.Log4Net - 1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LOGGING-140) Request of source code of
Request of source code of -- Key: LOGGING-140 URL: https://issues.apache.org/jira/browse/LOGGING-140 Project: Commons Logging Issue Type: Wish Environment: .Net 2008 Reporter: Jothi Rmasamy Can you please tell us the from where we can download the common.Logging.Log4Net - 1.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-442) CMA evolution strategy is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932913#action_12932913
]
Gilles commented on MATH-442:
-
[Replying to the comment before last.]
In the Javadoc of the {{SimplexOptimizer}}, the word "direct" refers to this
paper:
http://cm.bell-labs.com/cm/cs/doc/96/4-02.ps.gz
If the meaning is not clear, maybe the packages should be renamed (?).
In fact, I've always wondered why methods that need derivatives would be
considered more "general" than those that don't :).
> CMA evolution strategy is missing in optimization
> -
>
> Key: MATH-442
> URL: https://issues.apache.org/jira/browse/MATH-442
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Dr. Dietmar Wolz
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Recently I implemented the optimization algorithm CMA-ES based on
> org.apache.commons.math.linear and used it for the GTOC5 global trajectory
> optimization contest http://gtoc5.math.msu.su/. It implements the
> MultivariateRealOptimizer interface and would nicely fit into the
> org.apache.commons.math.optimization package. The original author of CMA-ES
> (Nikolaus Hansen) volunteered to support me (proof-reading + testing) in the
> creation of a CMA-ES contribution for commons.math.
> The CMA evolution strategy http://www.lri.fr/~hansen/cmaesintro.html is a
> very powerful algorithm for difficult non-linear non-convex optimization
> problems in continuous domain. See http://www.lri.fr/~hansen/cec2005.html for
> a comparison chart. If there is interest I will create a patch including the
> proposed Implementation for evaluation. It seems we would need an additional
> sub-package - org.apache.commons.math.optimization.evolutionary.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMMONSSITE-62) J2SE 1.5.0 javadoc "http://java.sun.com/j2se/1.5.0/docs/api/*" is not alive
[ https://issues.apache.org/jira/browse/COMMONSSITE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932900#action_12932900 ] Sebb commented on COMMONSSITE-62: - And now it doesn't (for me). Seems to be very erratic. Note: we will be changing the Javadoc Java API link in future releases; not sure it's worth fixing old links when it's not our fault. There will be millions of other references to the java.sun.com URLs across the internet. > J2SE 1.5.0 javadoc "http://java.sun.com/j2se/1.5.0/docs/api/*"; is not alive > > > Key: COMMONSSITE-62 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-62 > Project: Commons All > Issue Type: Bug > Components: Site > Environment: Almost of javadocs in http://commons.apache.org/ > For example: http://commons.apache.org/dbcp/api-1.4/index.html >Reporter: Masahiro Yamada >Priority: Minor > > Now, http://java.sun.com/j2se/1.5.0/docs/api/ and all files under it is not > accesible. > Oracle has been moved them to > http://download.oracle.com/javase/1.5.0/docs/api/ > I think there are two solutions. > 1. Change all links in javadocs in http://commons.apache.org/ that refers > http://java.sun.com/j2se/1.5.0/docs/api/ to > http://download.oracle.com/javase/1.5.0/docs/api/ > 2. Now, Oracle redirects accesses for http://java.sun.com/ to > http://www.oracle.com/technetwork/java/index.html, >If Oracle redirects access for http://java.sun.com/j2se/1.5.0/docs/api/ > to http://download.oracle.com/javase/1.5.0/docs/api/ , >No change is needed on http://commons.apache.org/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-442) CMA evolution strategy is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932873#action_12932873 ] Dr. Dietmar Wolz commented on MATH-442: --- We already invested some time to merge the algo to be based on commons.math. If the code is accepted I will support it in the future including bug fixes. The author of the algorithm volunteered to support me. For discussions regarding IP issues I propose to involve also the original author (Nikolaus Hansen) via e-mail. > CMA evolution strategy is missing in optimization > - > > Key: MATH-442 > URL: https://issues.apache.org/jira/browse/MATH-442 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dr. Dietmar Wolz > Original Estimate: 48h > Remaining Estimate: 48h > > Recently I implemented the optimization algorithm CMA-ES based on > org.apache.commons.math.linear and used it for the GTOC5 global trajectory > optimization contest http://gtoc5.math.msu.su/. It implements the > MultivariateRealOptimizer interface and would nicely fit into the > org.apache.commons.math.optimization package. The original author of CMA-ES > (Nikolaus Hansen) volunteered to support me (proof-reading + testing) in the > creation of a CMA-ES contribution for commons.math. > The CMA evolution strategy http://www.lri.fr/~hansen/cmaesintro.html is a > very powerful algorithm for difficult non-linear non-convex optimization > problems in continuous domain. See http://www.lri.fr/~hansen/cec2005.html for > a comparison chart. If there is interest I will create a patch including the > proposed Implementation for evaluation. It seems we would need an additional > sub-package - org.apache.commons.math.optimization.evolutionary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-442) CMA evolution strategy is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932872#action_12932872 ] Dr. Dietmar Wolz commented on MATH-442: --- If all optimization algos which don't require derivatives go into "direct" this would be the right package for CMA-ES. But the term "direct" is often used with another meaning, see for instance http://en.wikipedia.org/wiki/Numerical_analysis#Direct_and_iterative_methods > CMA evolution strategy is missing in optimization > - > > Key: MATH-442 > URL: https://issues.apache.org/jira/browse/MATH-442 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dr. Dietmar Wolz > Original Estimate: 48h > Remaining Estimate: 48h > > Recently I implemented the optimization algorithm CMA-ES based on > org.apache.commons.math.linear and used it for the GTOC5 global trajectory > optimization contest http://gtoc5.math.msu.su/. It implements the > MultivariateRealOptimizer interface and would nicely fit into the > org.apache.commons.math.optimization package. The original author of CMA-ES > (Nikolaus Hansen) volunteered to support me (proof-reading + testing) in the > creation of a CMA-ES contribution for commons.math. > The CMA evolution strategy http://www.lri.fr/~hansen/cmaesintro.html is a > very powerful algorithm for difficult non-linear non-convex optimization > problems in continuous domain. See http://www.lri.fr/~hansen/cec2005.html for > a comparison chart. If there is interest I will create a patch including the > proposed Implementation for evaluation. It seems we would need an additional > sub-package - org.apache.commons.math.optimization.evolutionary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
