[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-tabpanelfocusedCommentId=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.
[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-tabpanelfocusedCommentId=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: (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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] 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] 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] 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-437) Kolmogorov Smirnov Distribution
[ https://issues.apache.org/jira/browse/MATH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 Simardsima...@iro.umontreal.ca 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-tabpanelfocusedCommentId=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-442) CMA evolution strategy is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-437) Kolmogorov Smirnov Distribution
[
https://issues.apache.org/jira/browse/MATH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-437) Kolmogorov Smirnov Distribution
[ https://issues.apache.org/jira/browse/MATH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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-439) Refactoring of solvers (package analysis.solvers)
[
https://issues.apache.org/jira/browse/MATH-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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] 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] 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] 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] 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-tabpanelfocusedCommentId=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.
