[jira] [Commented] (LANG-744) StringUtils throws java.security.AccessControlException on Google App Engine
[
https://issues.apache.org/jira/browse/LANG-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095211#comment-13095211
]
Sebb commented on LANG-744:
---
The message will be thrown even if the sun method is not needed; that does not
seem right.
If the sun method is unavailable, the code that conditionally calls it throws
UnsupportedOperationException:
The stripAccents(CharSequence) method requires at least Java 1.6 or a Sun
JVM);
We could record the Exception in the static block, and add it as the cause for
the UOE.
It would then only appear when necessary.
StringUtils throws java.security.AccessControlException on Google App Engine
Key: LANG-744
URL: https://issues.apache.org/jira/browse/LANG-744
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0.1
Environment: Google App Engine
Reporter: Clément Denis
Fix For: 3.0.2
In the static initializer of org.apache.commons.lang3.StringUtils, there is
an attempt to load the class sun.text.Normalizer.
Such a class is prohibited on Google App Engine, and the static intializer
throws a java.security.AccessControlException.
{code}
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.sun.text)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
at java.lang.Class.checkMemberAccess(Class.java:2164)
at java.lang.Class.getMethod(Class.java:1602)
at org.apache.commons.lang3.StringUtils.clinit(StringUtils.java:739)
{code}
The exception should be caught in the catch clauses around
loadClass(sun.text.Normalizer).
Commons lang 2 worked fine on GAE.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-413) Miscellaneous issues concerning the optimization package
[
https://issues.apache.org/jira/browse/MATH-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095264#comment-13095264
]
Gilles commented on MATH-413:
-
{{NonLinearConjugateGradientOptimizer}} updated in revision 1164044.
Miscellaneous issues concerning the optimization package
--
Key: MATH-413
URL: https://issues.apache.org/jira/browse/MATH-413
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
Revision 990792 contains changes triggered the following issues:
* [MATH-394|https://issues.apache.org/jira/browse/MATH-394]
* [MATH-397|https://issues.apache.org/jira/browse/MATH-397]
* [MATH-404|https://issues.apache.org/jira/browse/MATH-404]
This issue collects the currently still unsatisfactory code (not necessarily
sorted in order of annoyance):
# BrentOptimizer: a specific convergence checker must be used.
LevenbergMarquardtOptimizer also has specific convergence checks.
# Trying to make convergence checking independent of the optimization
algorithm creates problems (conceptual and practical):
** See BrentOptimizer and LevenbergMarquardtOptimizer, the algorithm
passes points to the convergence checker, but the actual meaning of the
points can very well be different in the caller (optimization algorithm) and
the callee (convergence checker).
** In PowellOptimizer the line search (BrentOptimizer) tolerances depend
on the tolerances within the main algorithm. Since tolerances come with
ConvergenceChecker and so can be changed at any time, it is awkward to
adapt the values within the line search optimizer without exposing its
internals (BrentOptimizer field) to the enclosing class (PowellOptimizer).
# Given the numerous changes, some Javadoc comments might be out-of-sync,
although I did try to update them all.
# Class DirectSearchOptimizer (in package optimization.direct) inherits
from class AbstractScalarOptimizer (in package optimization.general).
# Some interfaces are defined in package optimization but their base
implementations (abstract class that contain the boiler-plate code) are in
package optimization.general (e.g.
DifferentiableMultivariateVectorialOptimizer and
BaseAbstractVectorialOptimizer).
# No check is performed to ensure the the convergence checker has been set
(see e.g. BrentOptimizer and PowellOptimizer); if it hasn't there will be
a NPE. The alternative is to initialize a default checker that will never be
used in case the user had intended to explicitly sets the checker.
# NonLinearConjugateGradientOptimizer: Ugly workaround for the checked
ConvergenceException.
# Everywhere, we trail the checked FunctionEvaluationException although it
is never used.
# There remains some duplicate code (such as the multi-start loop in the
various MultiStart... implementations).
# The ConvergenceChecker interface is very general (the converged method
can take any number of ...PointValuePair). However there remains a
semantic problem: One cannot be sure that the list of points means the same
thing for the caller of converged and within the implementation of the
ConvergenceChecker that was independently set.
# It is not clear whether it is wise to aggregate the counter of gradient
evaluations to the function evaluation counter. In
LevenbergMarquartdOptimizer for example, it would be unfair to do so.
Currently I had to remove all tests referring to gradient and Jacobian
evaluations.
# In AbstractLeastSquaresOptimizer and LevenbergMarquardtOptimizer,
occurences of OptimizationException were replaced by the unchecked
ConvergenceException but in some cases it might not be the most appropriate
one.
# MultiStartUnivariateRealOptimizer: in the other classes
(MultiStartMultivariate...) similar to this one, the randomization is on
the firts-guess value while in this class, it is on the search interval. I
think that here also we should randomly choose the start value (within the
user-selected interval).
# The Javadoc utility raises warnings (see output of mvn site) which I
couldn't figure out how to correct.
# Some previously existing classes and interfaces have become no more than a
specialisation of new generics classes; it might be interesting to remove
them in order to reduce the number of classes and thus limit the potential
for confusion.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-3) Import existing issues from old bug tracker
[ https://issues.apache.org/jira/browse/OGNL-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095316#comment-13095316 ] Maurizio Cucchiara commented on OGNL-3: --- Please ignore my last message, I mistook OGNL with XWORK. Anyway, looks like Lukasz asked to the INFRA team to import OGNL issues as well. Import existing issues from old bug tracker --- Key: OGNL-3 URL: https://issues.apache.org/jira/browse/OGNL-3 Project: OGNL Issue Type: Task Reporter: Simone Tripodi All old existing issues recorded on previous bug tracker have to be imported to ASF JIRA -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-463) Monte Carlo engine with 1D path
[ https://issues.apache.org/jira/browse/MATH-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095368#comment-13095368 ] Pavel Ryzhov commented on MATH-463: --- The patch is quite old. The code has been used quite heavily by me and evolved. But anyway as I'm the only developer and user of code I would love to see discussion of the design. Just to find out my pitfalls in the design. So, I'm going to re-integrate it back into Commons Math hopefully at the end of week or during the next week. Monte Carlo engine with 1D path --- Key: MATH-463 URL: https://issues.apache.org/jira/browse/MATH-463 Project: Commons Math Issue Type: New Feature Reporter: Pavel Ryzhov Fix For: 3.1 Attachments: mc1.patch Quite simple Monte-Carlo engine: 1. Generates N samples (paths) of Ito process with given drift and diffusion. It uses simple Euler discretization on equally spaced time scale. 2. For each path evaluate some path function and provide this value to SummaryStatistics. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-283) When using the 2.0 Commons IO, there is no sort method for LastModifiedFileComparator
When using the 2.0 Commons IO, there is no sort method for LastModifiedFileComparator - Key: IO-283 URL: https://issues.apache.org/jira/browse/IO-283 Project: Commons IO Issue Type: Bug Affects Versions: 2.0 Environment: Sparc Solaris 2.10 Reporter: Ulises Flynn Priority: Minor Although the javadocs and source code from version 2.0 of Apache Commons makes mentions of a sort method, the actual jar does not have the sort method that is available. It seems that the LastModifiedFileComparator in the jar is not extending AbstractFileComparator like it is in the source code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OGNL-19) Ability to programatically step through an Ognl execution.
Ability to programatically step through an Ognl execution. Key: OGNL-19 URL: https://issues.apache.org/jira/browse/OGNL-19 Project: OGNL Issue Type: Wish Environment: All. Reporter: Daniel Pitts First, let me describe in abstract terms my use case: I have several resources which I need to retrieve (by URI). I'm using Ognl to describe the URI of these resources. Some of the resource URI's might be dependent on content in other resources. I'd like to be able to set up my own queuing mechanism which will put on hold any such dependent URI until the resource is retrieved. Right now, the Ognl expression is evaluated using the Java stack, which makes it extremely difficult to pause an expression. It would be nice if the expression state could be externalized and run iteratively instead of recursively. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-413) Miscellaneous issues concerning the optimization package
[
https://issues.apache.org/jira/browse/MATH-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095677#comment-13095677
]
Gilles commented on MATH-413:
-
{{SimplexOptimizer}} updated in revision 1164300.
Miscellaneous issues concerning the optimization package
--
Key: MATH-413
URL: https://issues.apache.org/jira/browse/MATH-413
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
Revision 990792 contains changes triggered the following issues:
* [MATH-394|https://issues.apache.org/jira/browse/MATH-394]
* [MATH-397|https://issues.apache.org/jira/browse/MATH-397]
* [MATH-404|https://issues.apache.org/jira/browse/MATH-404]
This issue collects the currently still unsatisfactory code (not necessarily
sorted in order of annoyance):
# BrentOptimizer: a specific convergence checker must be used.
LevenbergMarquardtOptimizer also has specific convergence checks.
# Trying to make convergence checking independent of the optimization
algorithm creates problems (conceptual and practical):
** See BrentOptimizer and LevenbergMarquardtOptimizer, the algorithm
passes points to the convergence checker, but the actual meaning of the
points can very well be different in the caller (optimization algorithm) and
the callee (convergence checker).
** In PowellOptimizer the line search (BrentOptimizer) tolerances depend
on the tolerances within the main algorithm. Since tolerances come with
ConvergenceChecker and so can be changed at any time, it is awkward to
adapt the values within the line search optimizer without exposing its
internals (BrentOptimizer field) to the enclosing class (PowellOptimizer).
# Given the numerous changes, some Javadoc comments might be out-of-sync,
although I did try to update them all.
# Class DirectSearchOptimizer (in package optimization.direct) inherits
from class AbstractScalarOptimizer (in package optimization.general).
# Some interfaces are defined in package optimization but their base
implementations (abstract class that contain the boiler-plate code) are in
package optimization.general (e.g.
DifferentiableMultivariateVectorialOptimizer and
BaseAbstractVectorialOptimizer).
# No check is performed to ensure the the convergence checker has been set
(see e.g. BrentOptimizer and PowellOptimizer); if it hasn't there will be
a NPE. The alternative is to initialize a default checker that will never be
used in case the user had intended to explicitly sets the checker.
# NonLinearConjugateGradientOptimizer: Ugly workaround for the checked
ConvergenceException.
# Everywhere, we trail the checked FunctionEvaluationException although it
is never used.
# There remains some duplicate code (such as the multi-start loop in the
various MultiStart... implementations).
# The ConvergenceChecker interface is very general (the converged method
can take any number of ...PointValuePair). However there remains a
semantic problem: One cannot be sure that the list of points means the same
thing for the caller of converged and within the implementation of the
ConvergenceChecker that was independently set.
# It is not clear whether it is wise to aggregate the counter of gradient
evaluations to the function evaluation counter. In
LevenbergMarquartdOptimizer for example, it would be unfair to do so.
Currently I had to remove all tests referring to gradient and Jacobian
evaluations.
# In AbstractLeastSquaresOptimizer and LevenbergMarquardtOptimizer,
occurences of OptimizationException were replaced by the unchecked
ConvergenceException but in some cases it might not be the most appropriate
one.
# MultiStartUnivariateRealOptimizer: in the other classes
(MultiStartMultivariate...) similar to this one, the randomization is on
the firts-guess value while in this class, it is on the search interval. I
think that here also we should randomly choose the start value (within the
user-selected interval).
# The Javadoc utility raises warnings (see output of mvn site) which I
couldn't figure out how to correct.
# Some previously existing classes and interfaces have become no more than a
specialisation of new generics classes; it might be interesting to remove
them in order to reduce the number of classes and thus limit the potential
for confusion.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-413) Miscellaneous issues concerning the optimization package
[
https://issues.apache.org/jira/browse/MATH-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095682#comment-13095682
]
Gilles commented on MATH-413:
-
{{PowellOptimizer}} updated in revision 1164303.
Miscellaneous issues concerning the optimization package
--
Key: MATH-413
URL: https://issues.apache.org/jira/browse/MATH-413
Project: Commons Math
Issue Type: Bug
Reporter: Gilles
Fix For: 3.0
Revision 990792 contains changes triggered the following issues:
* [MATH-394|https://issues.apache.org/jira/browse/MATH-394]
* [MATH-397|https://issues.apache.org/jira/browse/MATH-397]
* [MATH-404|https://issues.apache.org/jira/browse/MATH-404]
This issue collects the currently still unsatisfactory code (not necessarily
sorted in order of annoyance):
# BrentOptimizer: a specific convergence checker must be used.
LevenbergMarquardtOptimizer also has specific convergence checks.
# Trying to make convergence checking independent of the optimization
algorithm creates problems (conceptual and practical):
** See BrentOptimizer and LevenbergMarquardtOptimizer, the algorithm
passes points to the convergence checker, but the actual meaning of the
points can very well be different in the caller (optimization algorithm) and
the callee (convergence checker).
** In PowellOptimizer the line search (BrentOptimizer) tolerances depend
on the tolerances within the main algorithm. Since tolerances come with
ConvergenceChecker and so can be changed at any time, it is awkward to
adapt the values within the line search optimizer without exposing its
internals (BrentOptimizer field) to the enclosing class (PowellOptimizer).
# Given the numerous changes, some Javadoc comments might be out-of-sync,
although I did try to update them all.
# Class DirectSearchOptimizer (in package optimization.direct) inherits
from class AbstractScalarOptimizer (in package optimization.general).
# Some interfaces are defined in package optimization but their base
implementations (abstract class that contain the boiler-plate code) are in
package optimization.general (e.g.
DifferentiableMultivariateVectorialOptimizer and
BaseAbstractVectorialOptimizer).
# No check is performed to ensure the the convergence checker has been set
(see e.g. BrentOptimizer and PowellOptimizer); if it hasn't there will be
a NPE. The alternative is to initialize a default checker that will never be
used in case the user had intended to explicitly sets the checker.
# NonLinearConjugateGradientOptimizer: Ugly workaround for the checked
ConvergenceException.
# Everywhere, we trail the checked FunctionEvaluationException although it
is never used.
# There remains some duplicate code (such as the multi-start loop in the
various MultiStart... implementations).
# The ConvergenceChecker interface is very general (the converged method
can take any number of ...PointValuePair). However there remains a
semantic problem: One cannot be sure that the list of points means the same
thing for the caller of converged and within the implementation of the
ConvergenceChecker that was independently set.
# It is not clear whether it is wise to aggregate the counter of gradient
evaluations to the function evaluation counter. In
LevenbergMarquartdOptimizer for example, it would be unfair to do so.
Currently I had to remove all tests referring to gradient and Jacobian
evaluations.
# In AbstractLeastSquaresOptimizer and LevenbergMarquardtOptimizer,
occurences of OptimizationException were replaced by the unchecked
ConvergenceException but in some cases it might not be the most appropriate
one.
# MultiStartUnivariateRealOptimizer: in the other classes
(MultiStartMultivariate...) similar to this one, the randomization is on
the firts-guess value while in this class, it is on the search interval. I
think that here also we should randomly choose the start value (within the
user-selected interval).
# The Javadoc utility raises warnings (see output of mvn site) which I
couldn't figure out how to correct.
# Some previously existing classes and interfaces have become no more than a
specialisation of new generics classes; it might be interesting to remove
them in order to reduce the number of classes and thus limit the potential
for confusion.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-744) StringUtils throws java.security.AccessControlException on Google App Engine
[
https://issues.apache.org/jira/browse/LANG-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095689#comment-13095689
]
Gary D. Gregory commented on LANG-744:
--
Well, I've ruminated, pondered and experimented.
Running all unit tests with a security managers results in:
Tests run: 2046, Failures: 2, Errors: 115, Skipped: 0
Clearly, we need a good overall solution to avoid 117 new Jiras (an
exaggeration I know.)
I've created a JAAS policy file to grant just enough permissions to run the
unit tests in {{src/test/resource/java.policy}}
The file contains instructions for using it with JAAS.
What this shows is that we should either:
# Run all unit tests a second time with JAAS enabled, or
# Run all unit tests with JAAS enabled, always
We should our solution as a pattern for other Commons component.
Specifically for StringUtils, should we have a SunStringUtils? This would let
you know that you are depending on com.sun code.
StringUtils throws java.security.AccessControlException on Google App Engine
Key: LANG-744
URL: https://issues.apache.org/jira/browse/LANG-744
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0.1
Environment: Google App Engine
Reporter: Clément Denis
Fix For: 3.0.2
In the static initializer of org.apache.commons.lang3.StringUtils, there is
an attempt to load the class sun.text.Normalizer.
Such a class is prohibited on Google App Engine, and the static intializer
throws a java.security.AccessControlException.
{code}
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.sun.text)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:166)
at
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
at java.lang.Class.checkMemberAccess(Class.java:2164)
at java.lang.Class.getMethod(Class.java:1602)
at org.apache.commons.lang3.StringUtils.clinit(StringUtils.java:739)
{code}
The exception should be caught in the catch clauses around
loadClass(sun.text.Normalizer).
Commons lang 2 worked fine on GAE.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-655) General framework for iterative algorithms
General framework for iterative algorithms
--
Key: MATH-655
URL: https://issues.apache.org/jira/browse/MATH-655
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Minor
Following the thread [Monitoring iterative
algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
here is a first attempt at defining a general enough framework for iterative
algorithms at large. At the moment, the classes provide support for
* maximum number of iterations
* events handling
** initialization event (prior to entering the main loop),
** iteration event (after completion of one iteration),
** termination event (after termination of the main loop).
These classes do not yet provide support for a stopping criterion.
Some points worth to note
* For the time being, the classes are part of the o.a.c.m.linear package.
* For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws a
{{TooManyEvaluationsException}}. If the proposed new feature is integrated into
CM, then a proper {{TooManyIterationsException}} should be created, from which
the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-655) General framework for iterative algorithms
[
https://issues.apache.org/jira/browse/MATH-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard updated MATH-655:
---
Attachment: iterative-algorithm.zip
General framework for iterative algorithms
--
Key: MATH-655
URL: https://issues.apache.org/jira/browse/MATH-655
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Minor
Labels: algorithm, events
Attachments: iterative-algorithm.zip
Following the thread [Monitoring iterative
algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
here is a first attempt at defining a general enough framework for iterative
algorithms at large. At the moment, the classes provide support for
* maximum number of iterations
* events handling
** initialization event (prior to entering the main loop),
** iteration event (after completion of one iteration),
** termination event (after termination of the main loop).
These classes do not yet provide support for a stopping criterion.
Some points worth to note
* For the time being, the classes are part of the o.a.c.m.linear package.
* For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws
a {{TooManyEvaluationsException}}. If the proposed new feature is integrated
into CM, then a proper {{TooManyIterationsException}} should be created, from
which the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-196) add support to constrained parameter estimation
[ https://issues.apache.org/jira/browse/MATH-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095734#comment-13095734 ] greg sterijevski commented on MATH-196: --- Luc, I am not sure if we are talking about the same implementation, but this paper argues differently: http://www.damtp.cam.ac.uk/user/na/NA_papers/NA2009_06.pdf -Greg add support to constrained parameter estimation --- Key: MATH-196 URL: https://issues.apache.org/jira/browse/MATH-196 Project: Commons Math Issue Type: New Feature Affects Versions: 1.2 Reporter: Luc Maisonobe Assignee: Luc Maisonobe Fix For: 3.0 The current estimation package supports only unconstrained problems. It should at least support simple bounds constrains on parameters. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-655) General framework for iterative algorithms
[
https://issues.apache.org/jira/browse/MATH-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095737#comment-13095737
]
greg sterijevski commented on MATH-655:
---
In the IterativeAlgorithm class you use the generic Collection class which you
instantiate with an ArrayList. Don't you think it would be better to use one of
the classes like CopyOnWriteArraySet? This way you can have listeners attach
and detach without explicit synchronization.
General framework for iterative algorithms
--
Key: MATH-655
URL: https://issues.apache.org/jira/browse/MATH-655
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.0
Reporter: Sébastien Brisard
Priority: Minor
Labels: algorithm, events
Attachments: iterative-algorithm.zip
Following the thread [Monitoring iterative
algorithms|http://mail-archives.apache.org/mod_mbox/commons-dev/201108.mbox/%3CCAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=k...@mail.gmail.com%3E],
here is a first attempt at defining a general enough framework for iterative
algorithms at large. At the moment, the classes provide support for
* maximum number of iterations
* events handling
** initialization event (prior to entering the main loop),
** iteration event (after completion of one iteration),
** termination event (after termination of the main loop).
These classes do not yet provide support for a stopping criterion.
Some points worth to note
* For the time being, the classes are part of the o.a.c.m.linear package.
* For the time being, {{IterativeAlgorithm.incrementIterationCount()}} throws
a {{TooManyEvaluationsException}}. If the proposed new feature is integrated
into CM, then a proper {{TooManyIterationsException}} should be created, from
which the former could derive.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
