[jira] [Issue Comment Edited] (MATH-728) Errors in BOBYQAOptimizer when numberOfInterpolationPoints is greater than 2*dim+1
[
https://issues.apache.org/jira/browse/MATH-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206296#comment-13206296
]
Gilles edited comment on MATH-728 at 2/11/12 11:47 PM:
---
Although the bug that triggered this issue is fixed, failures of the unit test
still miss an explanation...
The poor performance is to be expected given the current state of the code
(e.g. many matrix calculations are done explicitly, with getters and setters,
instead of calling methods of the matrix objects).
was (Author: erans):
Although the bug that triggered this issue is fixed, failures of the unit
test are still miss an explanation...
The poor performance is to be expected given the current state of the code
(e.g. many matrix calculations are done explicitly, with getters and setters,
instead of calling methods of the matrix objects).
> Errors in BOBYQAOptimizer when numberOfInterpolationPoints is greater than
> 2*dim+1
> --
>
> Key: MATH-728
> URL: https://issues.apache.org/jira/browse/MATH-728
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Mac Java(TM) SE Runtime Environment (build
> 1.6.0_29-b11-402-11M3527)
>Reporter: Bruce A Johnson
> Fix For: 3.0
>
>
> I've been having trouble getting BOBYQA to minimize a function (actually a
> non-linear least squares fit) so as one change I increased the number of
> interpolation points. It seems that anything larger than 2*dim+1 causes an
> error (typically at
> line 1662
>interpolationPoints.setEntry(nfm, ipt,
> interpolationPoints.getEntry(ipt, ipt));
> I'm guessing there is an off by one error in the translation from FORTRAN.
> Changing the BOBYQAOptimizerTest as follows (increasing number of
> interpolation points by one) will cause failures.
> Bruce
> Index:
> src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java
> ===
> ---
> src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java
> (revision 1221065)
> +++
> src/test/java/org/apache/commons/math/optimization/direct/BOBYQAOptimizerTest.java
> (working copy)
> @@ -258,7 +258,7 @@
> //RealPointValuePair result = optim.optimize(10, func, goal,
> startPoint);
> final double[] lB = boundaries == null ? null : boundaries[0];
> final double[] uB = boundaries == null ? null : boundaries[1];
> -BOBYQAOptimizer optim = new BOBYQAOptimizer(2 * dim + 1);
> +BOBYQAOptimizer optim = new BOBYQAOptimizer(2 * dim + 2);
> RealPointValuePair result = optim.optimize(maxEvaluations, func,
> goal, startPoint, lB, uB);
> //System.out.println(func.getClass().getName() + " = "
> // + optim.getEvaluations() + " f(");
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-725) use initialized static final arrays, instead of initializing it in constructors
[
https://issues.apache.org/jira/browse/MATH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13199279#comment-13199279
]
Gilles edited comment on MATH-725 at 2/2/12 10:22 PM:
--
Those arrays cannot be "static" since their size depends on a parameter ("k")
passed to the constructor.
Please clarify what you proposed (or, better: provide a patch). Thanks.
was (Author: erans):
Those arrays cannot be "static" since their size depends on a parameter
("k") passed to the constructor.
> use initialized static final arrays, instead of initializing it in
> constructors
> ---
>
> Key: MATH-725
> URL: https://issues.apache.org/jira/browse/MATH-725
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Eldar Agalarov
>Priority: Minor
> Fix For: 3.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The Well PRNG's implementations have arrays iRm1, iRm2, iRm3, i1, i2, i3. All
> these arrays are unmodifiable, so we can replace this arrays initialization
> block
> final int w = 32;
> final int r = (k + w - 1) / w;
> this.v = new int[r];
> this.index = 0;
>
> // precompute indirection index tables. These tables are used for
> optimizing access
> // they allow saving computations like "(j + r - 2) % r" with costly
> modulo operations
> iRm1 = new int[r];
> iRm2 = new int[r];
> i1 = new int[r];
> i2 = new int[r];
> i3 = new int[r];
> for (int j = 0; j < r; ++j) {
> iRm1[j] = (j + r - 1) % r;
> iRm2[j] = (j + r - 2) % r;
> i1[j] = (j + m1) % r;
> i2[j] = (j + m2) % r;
> i3[j] = (j + m3) % r;
> }
> with inline initialized static final arrays.
> This is much better and faster implementation, freed from unnecessary costly
> calculations (such as %).
> Another solution: leave as is, but make all these arrays static.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-707) Naming confusion
[
https://issues.apache.org/jira/browse/MATH-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166117#comment-13166117
]
Gilles edited comment on MATH-707 at 12/9/11 12:43 PM:
---
Changed "...RealOptimizer" (r1212344, r1212373 and r1212377).
was (Author: erans):
Changed "...RealOptimizer" (r1212344 and r1212373).
> Naming confusion
>
>
> Key: MATH-707
> URL: https://issues.apache.org/jira/browse/MATH-707
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Labels: api-change
> Fix For: 3.0
>
>
> This issue was raised in [this
> thread|http://markmail.org/thread/4h6omyqsik65rcgv] on the "dev" ML.
> It proposes to consistently name classes/interfaces that refer to number
> types (e.g. "Real", "Complex", ...) and structure (e.g. "Scalar",
> "Vectorial", ...), with "Real" and "Scalar" components in names being assumed
> (thus, not to be included in the name).
> For example, for the "Univariate..." interfaces (in package "analysis"), the
> proposal is to operate the following renaming:
> * {{UnivariateRealFunction}} -> {{UnivariateFunction}}
> * {{UnivariateRealVectorialFunction}} -> {{UnivariateVectorFunction}}
> * {{UnivariateMatrixFunction}} -> {{UnivariateMatrixFunction}}
> Similar changes are in order in the package "optimization" (where "Real" is
> sometimes included in the name and sometimes not, or used instead of
> "Scalar").
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-707) Naming confusion
[
https://issues.apache.org/jira/browse/MATH-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166117#comment-13166117
]
Gilles edited comment on MATH-707 at 12/9/11 12:36 PM:
---
Changed "...RealOptimizer" (r1212344 and r1212373).
was (Author: erans):
Changed "...MultiStart...RealOptimizer" (r1212344).
> Naming confusion
>
>
> Key: MATH-707
> URL: https://issues.apache.org/jira/browse/MATH-707
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Labels: api-change
> Fix For: 3.0
>
>
> This issue was raised in [this
> thread|http://markmail.org/thread/4h6omyqsik65rcgv] on the "dev" ML.
> It proposes to consistently name classes/interfaces that refer to number
> types (e.g. "Real", "Complex", ...) and structure (e.g. "Scalar",
> "Vectorial", ...), with "Real" and "Scalar" components in names being assumed
> (thus, not to be included in the name).
> For example, for the "Univariate..." interfaces (in package "analysis"), the
> proposal is to operate the following renaming:
> * {{UnivariateRealFunction}} -> {{UnivariateFunction}}
> * {{UnivariateRealVectorialFunction}} -> {{UnivariateVectorFunction}}
> * {{UnivariateMatrixFunction}} -> {{UnivariateMatrixFunction}}
> Similar changes are in order in the package "optimization" (where "Real" is
> sometimes included in the name and sometimes not, or used instead of
> "Scalar").
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-707) Naming confusion
[
https://issues.apache.org/jira/browse/MATH-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166123#comment-13166123
]
Gilles edited comment on MATH-707 at 12/9/11 12:28 PM:
---
Changed "...VectorialOptimizer" (r1212361 and r1212371).
was (Author: erans):
Changed "...VectorialOptimizer" (r1212361).
> Naming confusion
>
>
> Key: MATH-707
> URL: https://issues.apache.org/jira/browse/MATH-707
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Labels: api-change
> Fix For: 3.0
>
>
> This issue was raised in [this
> thread|http://markmail.org/thread/4h6omyqsik65rcgv] on the "dev" ML.
> It proposes to consistently name classes/interfaces that refer to number
> types (e.g. "Real", "Complex", ...) and structure (e.g. "Scalar",
> "Vectorial", ...), with "Real" and "Scalar" components in names being assumed
> (thus, not to be included in the name).
> For example, for the "Univariate..." interfaces (in package "analysis"), the
> proposal is to operate the following renaming:
> * {{UnivariateRealFunction}} -> {{UnivariateFunction}}
> * {{UnivariateRealVectorialFunction}} -> {{UnivariateVectorFunction}}
> * {{UnivariateMatrixFunction}} -> {{UnivariateMatrixFunction}}
> Similar changes are in order in the package "optimization" (where "Real" is
> sometimes included in the name and sometimes not, or used instead of
> "Scalar").
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-701) Seeding a default RNG
[
https://issues.apache.org/jira/browse/MATH-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143944#comment-13143944
]
Gilles edited comment on MATH-701 at 11/4/11 1:00 PM:
--
* From Harmony's implementation of "java.util.Random":
{code}
public Random() {
setSeed(System.currentTimeMillis() + hashCode());
}
{code}
* I'd also prefer setting both RNGs at construction.
A user would have to write
{code}
SecureRandom secRand = SecureRandom.getInstance(algorithm, provider);
{code}
in his application's code, and that would make it clearer for him why and how
an exception can be generated (and that CM's code is not the cause of it).
* I also favour a new "SecureRandomDataImpl" as a subclass of "RandomDataImpl";
the constructor would be something like:
{code}
public SecureRandomDataImpl(SecureRandom rng) {
super(rng);
}
{code}
This would ensure that _all_ the {{next...}} methods use a secure RNG, whereas
currently only some of the accessors have a secure alternative (e.g.
"nextGaussian" is not using "secRand"). This would be less confusing without
requiring long explanations...
was (Author: erans):
* Harmony:
{code}
seed = System.currentTimeMillis() + hashCode();
{code}
* I'd also prefer setting both RNGs at construction.
A user would have to write
{code}
SecureRandom secRand = SecureRandom.getInstance(algorithm, provider);
{code}
in his application's code, and that would make it clearer for him why and how
an exception can be generated (and that CM's code is not the cause of it).
* I also favour a new "SecureRandomDataImpl" as a subclass of "RandomDataImpl";
the constructor would be something like:
{code}
public SecureRandomDataImpl(SecureRandom rng) {
super(rng);
}
{code}
This would ensure that _all_ the {{next...}} methods use a secure RNG, whereas
currently only some of the accessors have a secure alternative (e.g.
"nextGaussian" is not using "secRand"). This would be less confusing without
requiring long explanations...
> Seeding a default RNG
> -
>
> Key: MATH-701
> URL: https://issues.apache.org/jira/browse/MATH-701
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles
>Assignee: Gilles
> Fix For: 3.0
>
>
> In "RandomDataImpl":
> {code}
> private RandomGenerator getRan() {
> if (rand == null) {
> rand = new JDKRandomGenerator();
> rand.setSeed(System.currentTimeMillis());
> }
> return rand;
> }
> {code}
> The conditional branch is used by "sample()" in
> "AbstractContinuousDistribution".
> When several "...Distribution" objects are instantiated in a short time
> interval, they are seeded with the same value.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-689) Breaking up "MathUtils"
[
https://issues.apache.org/jira/browse/MATH-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125462#comment-13125462
]
Gilles edited comment on MATH-689 at 10/11/11 11:38 PM:
bq. I'll do "MathArrays".
Done in revisions 1182134, 1182137, 1182147.
was (Author: erans):
bq. I'll do "MathArrays".
Done in revision 1182134.
> Breaking up "MathUtils"
> ---
>
> Key: MATH-689
> URL: https://issues.apache.org/jira/browse/MATH-689
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Trivial
> Labels: api-change
> Fix For: 3.0
>
>
> Issue related to this
> [proposal|http://www.mail-archive.com/dev@commons.apache.org/msg25617.html].
> There seemed to be a global agreement on the following break-up:
> * Arithmetics (for "addAndCheck", "factorial", "gcd", ...)
> * Precision (for "equals", "compare", ...)
> * Binomial (for "binomialCoefficient")
> * MathArrays (for "linearCombination", "distance", "safeNorm",
> "sortInPlace", "copyOf", ...)
> I think that "ordinary" mathematical functions ("pow", "cosh", ...) should go
> into "FastMath" (if not already available there).
> Those who are willing to work on this issue, please coordinate here.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
