[jira] [Commented] (LANG-820) TypeUtils.normalizeUpperBounds broken?
[
https://issues.apache.org/jira/browse/LANG-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461322#comment-13461322
]
Duncan Jones commented on LANG-820:
---
I don't believe this is a bug. The following unit test passes:
\\
{code}
@Test
public void testLang820() throws Exception {
Type[] typeArray = {String.class, String.class};
Type[] expectedArray = {String.class};
Assert.assertArrayEquals(expectedArray,
TypeUtils.normalizeUpperBounds(typeArray));
}
{code}
> TypeUtils.normalizeUpperBounds broken?
> --
>
> Key: LANG-820
> URL: https://issues.apache.org/jira/browse/LANG-820
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.0.1
>Reporter: Shevek
>
> I looked at TypeUtils.normalizeUpperBounds, and I think (from code review)
> that:
> normalize(new Class[] { String.class, String.class }) == { String.class,
> String.class }
> which is not normalized. Didn't prove it with junit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461300#comment-13461300 ] Gilles commented on MATH-867: - bq. This is because it internally maps the fitted parameter range into the interval [0,1] If this is indeed the reason, not much can be done short of modifying the algorithm. The implementation we have in CM was ported from the original code under the supervision of the original author. Maybe you should ask him this question. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-868) Default sigma for CMAESOptimizer is wrong when using bounds
[ https://issues.apache.org/jira/browse/MATH-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461294#comment-13461294 ] Gilles commented on MATH-868: - While running the code which you provided in MATH-867, I noticed that having an "inputSigma" either much larger or much smaller than 0.3 gives even worse results for that test (both when the optimum is near the lower bound and whne it's near the upper bound). >From this, I'd suspect that the code is correct (always divided by the range), >but that the documentation is wrong to suggest multiplying 0.3 by the range as >a good value for "inputSigma". I propose to modify the doc of "inputSigma", indicating that it should be about 0.3. That looks strange, and the problem may well lie deeper (in how constraints are taken into account). Unless you have a test case, there isn't much more I can do, unfortunately. > Default sigma for CMAESOptimizer is wrong when using bounds > --- > > Key: MATH-868 > URL: https://issues.apache.org/jira/browse/MATH-868 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > > The documentation suggests setting inputSigma to 1/3 the range you are > fitting over. However, in CMAESOptimizer.initializeCMA() if boundaries are > specified the sigmaArray is by default assigned a value of 0.3 divided by the > range. If the user had specified the inputSigma to be 0.3 of the range (as > suggested by the docs) then sigmaArray would have been assigned the value of > 0.3. Thus, it looks like the 0.3 should not be divided by the range, only a > user-specified inputSigma should get divided by the range. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-757) StringEscapeUtils.unescapeHtml: handle HTML escapes without semicolon
[ https://issues.apache.org/jira/browse/LANG-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duncan Jones updated LANG-757: -- Attachment: commons-lang3-LANG-757.patch Attached is a patch that adds overloaded unescapeHtml3 and unescapeHtml4 methods, which accept a boolean parameter to indicate if semicolons are optional (plus tests). > StringEscapeUtils.unescapeHtml: handle HTML escapes without semicolon > - > > Key: LANG-757 > URL: https://issues.apache.org/jira/browse/LANG-757 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Affects Versions: 2.x >Reporter: Steve Hale >Priority: Minor > Attachments: commons-lang3-LANG-757.patch > > > org.apache.commons.lang.StringEscapeUtils.unescapeHtml is useful in detecting > and correcting Cross-Site Scripting (XSS) attempts by converting escaped > chars like &# 60; or & lt; (remove spaces) into normal chars like < so > patterns like HTML tags can be detected. Many browsers will allow variations > without semicolons, particularly the long UTF-8 encoding like <. > Please see: http://ha.ckers.org/xss.html > Since this may not be standard HTML, maybe adding a boolean bLenient > parameter to the method could allow better backward compatibility. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-678) NonLinear Optimizers seem to have a hard time hitting NIST standards
[ https://issues.apache.org/jira/browse/MATH-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-678: Assignee: (was: greg sterijevski) Greg Sterijevski does not seem to be around this forum anymore. > NonLinear Optimizers seem to have a hard time hitting NIST standards > > > Key: MATH-678 > URL: https://issues.apache.org/jira/browse/MATH-678 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 > Environment: Java >Reporter: greg sterijevski >Priority: Minor > Labels: NIST, NonLinear, Optimization > > As per a discussion on the mailing list, I am opening this ticket. In > applying the nonlinear optimizers in commons, I noticed what I believe to be > instability in the techniques. Further investigation investigation (both of > my tests) and the code in prod is warranted. > I will be pushing a first set of tests which should illustrate what I am > seeing. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-863) new Quaternion class added in complex package
[ https://issues.apache.org/jira/browse/MATH-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-863: Fix Version/s: 3.1 > new Quaternion class added in complex package > - > > Key: MATH-863 > URL: https://issues.apache.org/jira/browse/MATH-863 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Julien Anxionnat > Fix For: 3.1 > > Attachments: quaternion_adjustments.patch, quaternion.patch, > quaternion_v2.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > This patch provides a new class for the mathematical object "Quaternion" in > the complex package. > This quaternion is considered as a mathematical object (the Hamilton's > hypercomplex number). > Note that it's not a rotation quaternion which has to be a quaternion of norm > one. Although this feature could be used for a getter in the Rotation class. > This patch provides also some improvements in Precision class : a "double > comparison epsilon" and a method to compute relative comparison. > (Please, note that's it's my first contribution, and I apologize in advance > for my mistakes…) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-863) new Quaternion class added in complex package
[ https://issues.apache.org/jira/browse/MATH-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461236#comment-13461236 ] Gilles commented on MATH-863: - If the class contains a working implementation of the basic functionality of a quaternion, I propose to resolve this issue. The class can be enhanced later if needed (through a new JIRA ticket). > new Quaternion class added in complex package > - > > Key: MATH-863 > URL: https://issues.apache.org/jira/browse/MATH-863 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Julien Anxionnat > Fix For: 3.1 > > Attachments: quaternion_adjustments.patch, quaternion.patch, > quaternion_v2.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > This patch provides a new class for the mathematical object "Quaternion" in > the complex package. > This quaternion is considered as a mathematical object (the Hamilton's > hypercomplex number). > Note that it's not a rotation quaternion which has to be a quaternion of norm > one. Although this feature could be used for a getter in the Rotation class. > This patch provides also some improvements in Precision class : a "double > comparison epsilon" and a method to compute relative comparison. > (Please, note that's it's my first contribution, and I apologize in advance > for my mistakes…) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-827) Replace class "LegendreGaussIntegrator" with "IterativeLegendreGaussIntegrator" class
[ https://issues.apache.org/jira/browse/MATH-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-827: Fix Version/s: (was: 3.1) > Replace class "LegendreGaussIntegrator" with > "IterativeLegendreGaussIntegrator" class > - > > Key: MATH-827 > URL: https://issues.apache.org/jira/browse/MATH-827 > Project: Commons Math > Issue Type: Task >Reporter: Gilles >Assignee: Gilles >Priority: Minor > Labels: api-change > Fix For: 4.0 > > Attachments: IterativeLegendreGaussIntegrator.java > > > The "LegendreGaussIntegrator" class (in package > "o.a.c.m.analysis.integration") has a misleading name. Internally, it uses > the Legendre-Gauss quadrature rule on sub-intervals of the integration range > but, additionally, it performs an iterative procedure to automatically > determine the number of sub-intervals over which the rule will be > successively applied. > The strict Gauss-Legendre quadrature scheme has now been implemented (cf. > MATH-797) in package "o.a.c.m.analysis.integration.gauss". > I thus propose to: > # Deprecate "LegendreGaussIntegrator" in 3.1. > # Create a new "IterativeLegendreGaussIntegrator" class that will perform the > same procedure as "LegendreGaussIntegrator" but will internally use the > classes in package "o.a.c.m.analysis.integration.gauss" to perform the > Gauss-Legendre quadrature part. > # Remove "LegendreGaussIntegrator" in 4.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-800) Deprecating "PolynomialFitter"
[ https://issues.apache.org/jira/browse/MATH-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-800. - Resolution: Won't Fix Fix Version/s: (was: 4.0) (was: 3.1) > Deprecating "PolynomialFitter" > -- > > Key: MATH-800 > URL: https://issues.apache.org/jira/browse/MATH-800 > Project: Commons Math > Issue Type: Task >Affects Versions: 3.0 >Reporter: Gilles >Assignee: Gilles >Priority: Minor > Labels: api-change > > As [proposed|http://markmail.org/message/bhx6oxduzktohec5] on the "dev" ML, > the "PolynomialFitter" should be deprecated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-799) Remove default values for tolerances in "AbstractConvergenceChecker"
[ https://issues.apache.org/jira/browse/MATH-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461235#comment-13461235 ] Gilles commented on MATH-799: - Work done for 3.1; issue will be finalized when preparing 4.0. > Remove default values for tolerances in "AbstractConvergenceChecker" > > > Key: MATH-799 > URL: https://issues.apache.org/jira/browse/MATH-799 > Project: Commons Math > Issue Type: Task >Affects Versions: 3.0 >Reporter: Gilles >Assignee: Gilles >Priority: Trivial > Labels: api-change > Fix For: 4.0 > > > The custom convergence checkers let users override the ad-hoc convergence > criteria that most optimization algorithms provide. > CM defines "simple" checkers that inherit from "AbstractConvergenceChecker" > and use the default values provided in that class. However good values for > the tolerances are problem-dependent. > User control cannot come without the user paying attention to those values, > or "strange" failures can happen (cf. issue MATH-798). > It is thus proposed to remove the default values defined in > "AbstractConvergenceChecker", and also to remove the default (no-arg) > constructor for all the convergence checkers defined in CM, i.e.: > * AbstractConvergenceChecker > * SimpleValueChecker > * SimpleUnivariateValueChecker > * SimplePointChecker > * SimpleVectorValueChecker > In turn, this implies the removal of some of the constructors (which call the > above constructors) in the following classes: > * SimplexOptimizer > * BaseAbstractMultivariateOptimizer > * BaseAbstractMultivariateVectorOptimizer > * CMAESOptimizer > * BaseAbstractMultivariateSimpleBoundsOptimizer > * AbstractScalarDifferentiableOptimizer > * GaussNewtonOptimizer > * AbstractLeastSquaresOptimizer > * NonLinearConjugateGradientOptimizer > * LevenbergMarquardtOptimizer > To maintain backwards-compatibility, the fields and constructors will be > deprecated but not removed until the preparation of release 4.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-799) Remove default values for tolerances in "AbstractConvergenceChecker"
[ https://issues.apache.org/jira/browse/MATH-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-799: Fix Version/s: (was: 3.1) > Remove default values for tolerances in "AbstractConvergenceChecker" > > > Key: MATH-799 > URL: https://issues.apache.org/jira/browse/MATH-799 > Project: Commons Math > Issue Type: Task >Affects Versions: 3.0 >Reporter: Gilles >Assignee: Gilles >Priority: Trivial > Labels: api-change > Fix For: 4.0 > > > The custom convergence checkers let users override the ad-hoc convergence > criteria that most optimization algorithms provide. > CM defines "simple" checkers that inherit from "AbstractConvergenceChecker" > and use the default values provided in that class. However good values for > the tolerances are problem-dependent. > User control cannot come without the user paying attention to those values, > or "strange" failures can happen (cf. issue MATH-798). > It is thus proposed to remove the default values defined in > "AbstractConvergenceChecker", and also to remove the default (no-arg) > constructor for all the convergence checkers defined in CM, i.e.: > * AbstractConvergenceChecker > * SimpleValueChecker > * SimpleUnivariateValueChecker > * SimplePointChecker > * SimpleVectorValueChecker > In turn, this implies the removal of some of the constructors (which call the > above constructors) in the following classes: > * SimplexOptimizer > * BaseAbstractMultivariateOptimizer > * BaseAbstractMultivariateVectorOptimizer > * CMAESOptimizer > * BaseAbstractMultivariateSimpleBoundsOptimizer > * AbstractScalarDifferentiableOptimizer > * GaussNewtonOptimizer > * AbstractLeastSquaresOptimizer > * NonLinearConjugateGradientOptimizer > * LevenbergMarquardtOptimizer > To maintain backwards-compatibility, the fields and constructors will be > deprecated but not removed until the preparation of release 4.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-839) In "RealDistribution" implementations, rename method "cumulativeProbability(double,double)" to "probability(double,double)"
[ https://issues.apache.org/jira/browse/MATH-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-839: Fix Version/s: (was: 3.1) > In "RealDistribution" implementations, rename method > "cumulativeProbability(double,double)" to "probability(double,double)" > --- > > Key: MATH-839 > URL: https://issues.apache.org/jira/browse/MATH-839 > Project: Commons Math > Issue Type: Task >Affects Versions: 3.0 >Reporter: Gilles >Assignee: Gilles >Priority: Trivial > Labels: api-change > Fix For: 4.0 > > > Cf. http://en.wikipedia.org/wiki/Cumulative_distribution_function > Cf. http://en.wikipedia.org/wiki/Probability_density_function > The method currently named "cumulativeProbability(double,double)" in fact > provides the _probability_ of the variable to be within the given interval. > The name "probability" would thus be more accurate (and shorter). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-809) Encapsulate trival equal test into a method to avoid repeating over and over.....
[
https://issues.apache.org/jira/browse/LANG-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461233#comment-13461233
]
Duncan Jones commented on LANG-809:
---
Having given this some thought, I'm not sure there is an easy solution.
Firstly, if we create a method as you've suggested:
{code}
boolean possiblyEquals(Object lhs, Object rhs) {
if (rhs == null) { return false; }
if (lhs == rhs) { return true; } // definitely equal, but how to know?
return (lhs.getClass() == rhs.getClass()); // possibly equal
}
{code}
We must express three possible results (they are equal, they are not equal, we
are not sure yet) with a binary value. Not only is this confusing, it also
means we will continue to evaluate the EqualsBuilder even if we already know
the object is equal.
I then considered if we could add a new appendXXX method, but the best we can
do is as follows:
{code}
public boolean equals(Object obj) {
// Have to check this, otherwise we cannot cast
if (obj.getClass() != getClass()) {
return false;
}
// Have to do this, in order to get access to fields
MyClass rhs = (MyClass) obj;
// Have to do this, otherwise NullPointerException when accessing fields
if (rhs == null) {
return false;
}
return new EqualsBuilder()
// this method can then only do a basic (this == obj) check
.appendBasic(this, obj)
.appendSuper(super.equals(obj))
.append(field1, rhs.field1)
.append(field2, rhs.field2)
.append(field3, rhs.field3)
.isEquals();
}
{code}
If you can think of an alternative, please comment! Otherwise, this might need
to be closed as won't fix (i.e. can't improve).
> Encapsulate trival equal test into a method to avoid repeating over and
> over.
> -
>
> Key: LANG-809
> URL: https://issues.apache.org/jira/browse/LANG-809
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
>Affects Versions: 3.1
> Environment: Windows 7
>Reporter: Colbert Philippe
>Priority: Minor
> Labels: Encapsulate, EqualsBuilder, in, test, trivial
>
> In class EqualsBuilder, the documentation gives sample code on how to use
> EqualsBuilder. The proper usage of class EqualsBuilder is a bit long. My
> suggestion is to encapsulate the following trivial test into a method inside
> the class EqualsBuilder. You call it the new method trivalTest(Object obj1,
> Object obj2).
>// This is the code that should be put in a method to avoid repeating
>if (obj == null) { return false; }
>if (obj == this) { return true; }
>if (obj.getClass() != getClass()) {
> return false;
>}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-856) Deprecate "NullArgumentException"
[ https://issues.apache.org/jira/browse/MATH-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-856. - Resolution: Won't Fix This issue is superseded by MATH-869. > Deprecate "NullArgumentException" > - > > Key: MATH-856 > URL: https://issues.apache.org/jira/browse/MATH-856 > Project: Commons Math > Issue Type: Task >Affects Versions: 3.0 >Reporter: Gilles >Priority: Trivial > Fix For: 3.1, 4.0 > > > [Discussions|http://markmail.org/message/cl2e6c4pqbluo63e] on the "dev" ML > concluded that "NullArgumentException" was more of a burden to maintain than > it brings benefits. > It will be deprecated in 3.1 and removed in 4.0. > Checks for "null" in CM code will either be maintained or be removed. > Whenever checks for "null" are performed, the exception to be thrown is the > standard "NullPointerException" (instantiated with the no-arg constructor). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-580) FastMath Performance Test should use larger ranges where the functions support them
[ https://issues.apache.org/jira/browse/MATH-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-580: Fix Version/s: (was: 3.1) 3.2 > FastMath Performance Test should use larger ranges where the functions > support them > --- > > Key: MATH-580 > URL: https://issues.apache.org/jira/browse/MATH-580 > Project: Commons Math > Issue Type: Bug >Reporter: Sebb > Fix For: 3.2 > > > FastMath calculations should be faster than Math, especially over larger > ranges of operands. > The Performance test code currently uses a very small range of operands > (probably so the same range can be used for all tests). > The test should be enhanced to use much larger ranges where this is supported > by the function under test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-869) Make "NullArgumentException" inherit from "java.lang.NullPointerException"
Gilles created MATH-869: --- Summary: Make "NullArgumentException" inherit from "java.lang.NullPointerException" Key: MATH-869 URL: https://issues.apache.org/jira/browse/MATH-869 Project: Commons Math Issue Type: Task Affects Versions: 3.1, 3.2 Reporter: Gilles Assignee: Gilles Priority: Trivial Fix For: 4.0 After long [discussions|http://markmail.org/message/cl2e6c4pqbluo63e], we decided to have all CM exceptions in the same hierarchy, except "NullArgumentException" which will inherit from the standard NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-857) Include a VIF and TOLERANCE check for a 2 dimensional double array, to determine variables that cause multi-colinearity issues and should be excluded from the models
[ https://issues.apache.org/jira/browse/MATH-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-857: Fix Version/s: (was: 3.1) 3.2 > Include a VIF and TOLERANCE check for a 2 dimensional double array, to > determine variables that cause multi-colinearity issues and should be > excluded from the models > - > > Key: MATH-857 > URL: https://issues.apache.org/jira/browse/MATH-857 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 > Environment: can apply to all operating systems >Reporter: Marios Michaelidis >Priority: Minor > Labels: build, test > Fix For: 3.2 > > Attachments: FOR TOLERANCE.rar, Multicolinearity.java > > Original Estimate: 48h > Remaining Estimate: 48h > > Multicollinearity is a statistical phenomenon in which two or more predictor > variables in any multiple regression model are highly correlated. Tolerance > and VIF are checks that allows to avoid optimization failes due to "inability > to converge". Most of the times, the major packages (SAS, SPSS etc), have a > check prior to running the model and they exclude variables that might cause > these kind of problems. It is quite a useful tool to be in common maths. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-845) Basic number theory features such as primality testing, factorization and prime number generation
[ https://issues.apache.org/jira/browse/MATH-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-845: Fix Version/s: (was: 3.1) 3.2 > Basic number theory features such as primality testing, factorization and > prime number generation > - > > Key: MATH-845 > URL: https://issues.apache.org/jira/browse/MATH-845 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.1 > Environment: ubuntu/java6/intel-i5 >Reporter: Sebastien Riou >Priority: Minor > Labels: features > Fix For: 3.2 > > Attachments: primes-src.zip > > Original Estimate: 24h > Remaining Estimate: 24h > > A set of static methods to perform primality test, factorization and prime > number generation. Currently it is limited to the int data type, extension to > long/BigInteger will follow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-621:
Fix Version/s: (was: 3.1)
3.2
> BOBYQA is missing in optimization
> -
>
> Key: MATH-621
> URL: https://issues.apache.org/jira/browse/MATH-621
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Dr. Dietmar Wolz
> Fix For: 3.2
>
> Attachments: bobyqa_convert.pl, BOBYQA.math.patch,
> bobyqaoptimizer0.4.zip, BOBYQAOptimizer0.4.zip, BOBYQAOptimizer.java.patch,
> BOBYQA.v02.math.patch, bobyqav0.3.zip, bobyqa.zip
>
>
> During experiments with space flight trajectory optimizations I recently
> observed, that the direct optimization algorithm BOBYQA
> http://plato.asu.edu/ftp/other_software/bobyqa.zip
> from Mike Powell is significantly better than the simple Powell algorithm
> already in commons.math. It uses significantly lower function calls and is
> more reliable for high dimensional problems. You can replace CMA-ES in many
> more application cases by BOBYQA than by the simple Powell optimizer.
> I would like to contribute a Java port of the algorithm.
> I maintained the structure of the original FORTRAN code, so the
> code is fast but not very nice.
> License status: Michael Powell has sent the agreement via snail mail
> - it hasn't arrived yet.
> Progress: The attached patch relative to the trunk contains both the
> optimizer and the related unit tests - which are all green now.
> Performance:
> Performance difference (number of function evaluations)
> PowellOptimizer / BOBYQA for different test functions (taken from
> the unit test of BOBYQA, dimension=13 for most of the
> tests.
> Rosen = 9350 / 1283
> MinusElli = 118 / 59
> Elli = 223 / 58
> ElliRotated = 8626 / 1379
> Cigar = 353 / 60
> TwoAxes = 223 / 66
> CigTab = 362 / 60
> Sphere = 223 / 58
> Tablet = 223 / 58
> DiffPow = 421 / 928
> SsDiffPow = 614 / 219
> Ackley = 757 / 97
> Rastrigin = 340 / 64
> The number for DiffPow should be discussed with Michael Powell,
> I will send him the details.
> h3. Open Problems
> * Checkstyle violations[1] because of the original Fortran source:
> ** Original method comments were copied: Javadoc standard documentation
> should be added, but the original documentation should stay (as a reference
> to what the original intended behaviour was) untouched until we are sure that
> the code behaves as expected.
> ** Multiple variable declarations per line.
> ** "goto" conversions:
> *** "goto"s not convertible in loops were translated into a finite automaton
> (switch statement)
> *** "no default in switch"
> *** "fall through from previous case in switch"
> * Unexplored code paths: "throw" statements have been introduced in the code.
> Each should be triggered by at least one unit test. They are currently
> commented out in provision of the 3.0 release (cf. MATH-712) but should be
> re-enabled afterwards.
> [1] Once the violations are solved, the following lines should be removed
> from the source file:
> * {{// CHECKSTYLE: stop all}}
> * {{//CHECKSTYLE: resume all}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-641) Implement distance methods on 2D and 3D Lines as well as Line Segments.
[ https://issues.apache.org/jira/browse/MATH-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461225#comment-13461225 ] Gilles commented on MATH-641: - Would you provide a patch? > Implement distance methods on 2D and 3D Lines as well as Line Segments. > --- > > Key: MATH-641 > URL: https://issues.apache.org/jira/browse/MATH-641 > Project: Commons Math > Issue Type: New Feature >Reporter: Curtis Jensen >Priority: Minor > Fix For: 3.1 > > Original Estimate: 4h > Remaining Estimate: 4h > > Implement a method that calculates the distance from a point to 3D and 2D > lines and line segements (similar to what already exists in the 3D Line > class). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-607) Current Multiple Regression Object does calculations with all data incore. There are non incore techniques which would be useful with large datasets.
[ https://issues.apache.org/jira/browse/MATH-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-607. - Resolution: Implemented Nobody seems to be able to answer this question. If someone wants to make further updates, a new ticket can be created... > Current Multiple Regression Object does calculations with all data incore. > There are non incore techniques which would be useful with large datasets. > - > > Key: MATH-607 > URL: https://issues.apache.org/jira/browse/MATH-607 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 > Environment: Java >Reporter: greg sterijevski > Labels: Gentleman's, QR, Regression, Updating, decomposition, > lemma > Fix For: 3.1 > > Attachments: millerreg, millerreg_take2, millerregtest, > regres_change1, RegressResults2, updating_reg_cut2, updating_reg_ifaces > > Original Estimate: 840h > Remaining Estimate: 840h > > The current multiple regression class does a QR decomposition on the complete > data set. This necessitates the loading incore of the complete dataset. For > large datasets, or large datasets and a requirement to do datamining or > stepwise regression this is not practical. There are techniques which form > the normal equations on the fly, as well as ones which form the QR > decomposition on an update basis. I am proposing, first, the specification of > an "UpdatingLinearRegression" interface which defines basic functionality all > such techniques must fulfill. > Related to this 'updating' regression, the results of running a regression on > some subset of the data should be encapsulated in an immutable object. This > is to ensure that subsequent additions of observations do not corrupt or > render inconsistent parameter estimates. I am calling this interface > "RegressionResults". > Once the community has reached a consensus on the interface, work on the > concrete implementation of these techniques will take place. > Thanks, > -Greg -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default locale; add Locale support
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461219#comment-13461219
]
Duncan Jones commented on LANG-799:
---
bq. Does not fail for me, even if I change the default Locale to
Locale.GERMAN(Y)
This appears to be related to Java version. I was inadvertently compiling and
executing the tests with JDK 7 not 6. The test passes under 6 and fails under 7.
> DateUtils#parseDate uses default locale; add Locale support
> ---
>
> Key: LANG-799
> URL: https://issues.apache.org/jira/browse/LANG-799
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
>Reporter: Oliver Kopp
>Priority: Minor
> Labels: features
> Fix For: 3.2
>
> Attachments: commons-lang3-LANG-799.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
> Following line throws an ParseException on a German system:
> d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", new String[] {"EEE,
> dd MMM HH:mm:ss zzz"});
> Reason: parseDate internally calls SimpleDateFormat without providing a
> locale. This causes "MMM" to be interpreted using the system locale. If the
> system is German, the date is trying to be interpreted as German date.
> I see following solutions:
> A) Always instantiate SimpleDateFormat with Locale.ENGLISH
> B) Make two instances of SimpleDateFormat. One without providing a locale
> and one with Locale.ENGLISH. Try two parsings
> C) Make as many SimpleDateFormat instances as locales are availble iterate
> over all instances at the parsing attempts.
> D) provide an additional (optional) parameter to parseDate for providing a
> Locale
> I would prefer B) as this seems the best trade-off between
> internationalization and local usage.
> What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default locale; add Locale support
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461198#comment-13461198
]
Sebb commented on LANG-799:
---
bq. Please, ensure the tests ruin with Java 5 as well as with newer ones.
The pom specifies Java 1.6 for Lang3
bq. And note, that the JDK switched the behavior between Java 5 and 6. Java 5
always uses English time zone short cuts (e.g. "CET" for Central European
Time), while they are localized since Java 6 ("MEZ" for Mitteleuropäische Zeit).
Not sure what that refers to; sounds like a separate bug (if any).
> DateUtils#parseDate uses default locale; add Locale support
> ---
>
> Key: LANG-799
> URL: https://issues.apache.org/jira/browse/LANG-799
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
>Reporter: Oliver Kopp
>Priority: Minor
> Labels: features
> Fix For: 3.2
>
> Attachments: commons-lang3-LANG-799.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
> Following line throws an ParseException on a German system:
> d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", new String[] {"EEE,
> dd MMM HH:mm:ss zzz"});
> Reason: parseDate internally calls SimpleDateFormat without providing a
> locale. This causes "MMM" to be interpreted using the system locale. If the
> system is German, the date is trying to be interpreted as German date.
> I see following solutions:
> A) Always instantiate SimpleDateFormat with Locale.ENGLISH
> B) Make two instances of SimpleDateFormat. One without providing a locale
> and one with Locale.ENGLISH. Try two parsings
> C) Make as many SimpleDateFormat instances as locales are availble iterate
> over all instances at the parsing attempts.
> D) provide an additional (optional) parameter to parseDate for providing a
> Locale
> I would prefer B) as this seems the best trade-off between
> internationalization and local usage.
> What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default locale; add Locale support
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461196#comment-13461196
]
Sebb commented on LANG-799:
---
bq. That last commit now breaks the build, as my test
testParseNonSystemLocale() assumed the localized pattern change and now fails.
Does not fail for me, even if I change the default Locale to Locale.GERMAN(Y)
> DateUtils#parseDate uses default locale; add Locale support
> ---
>
> Key: LANG-799
> URL: https://issues.apache.org/jira/browse/LANG-799
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
>Reporter: Oliver Kopp
>Priority: Minor
> Labels: features
> Fix For: 3.2
>
> Attachments: commons-lang3-LANG-799.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
> Following line throws an ParseException on a German system:
> d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", new String[] {"EEE,
> dd MMM HH:mm:ss zzz"});
> Reason: parseDate internally calls SimpleDateFormat without providing a
> locale. This causes "MMM" to be interpreted using the system locale. If the
> system is German, the date is trying to be interpreted as German date.
> I see following solutions:
> A) Always instantiate SimpleDateFormat with Locale.ENGLISH
> B) Make two instances of SimpleDateFormat. One without providing a locale
> and one with Locale.ENGLISH. Try two parsings
> C) Make as many SimpleDateFormat instances as locales are availble iterate
> over all instances at the parsing attempts.
> D) provide an additional (optional) parameter to parseDate for providing a
> Locale
> I would prefer B) as this seems the best trade-off between
> internationalization and local usage.
> What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default locale; add Locale support
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461197#comment-13461197
]
Sebb commented on LANG-799:
---
URL: http://svn.apache.org/viewvc?rev=1388818&view=rev
Log:
LANG-799 - DateUtils#parseDate uses default locale; add Locale support
Remove unnecessary test
Modified:
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java
URL: http://svn.apache.org/viewvc?rev=1388821&view=rev
Log:
LANG-799 - DateUtils#parseDate uses default locale; add Locale support
Parse German date with English Locale, specifying German Locale override
Modified:
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java
> DateUtils#parseDate uses default locale; add Locale support
> ---
>
> Key: LANG-799
> URL: https://issues.apache.org/jira/browse/LANG-799
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
>Reporter: Oliver Kopp
>Priority: Minor
> Labels: features
> Fix For: 3.2
>
> Attachments: commons-lang3-LANG-799.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
> Following line throws an ParseException on a German system:
> d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", new String[] {"EEE,
> dd MMM HH:mm:ss zzz"});
> Reason: parseDate internally calls SimpleDateFormat without providing a
> locale. This causes "MMM" to be interpreted using the system locale. If the
> system is German, the date is trying to be interpreted as German date.
> I see following solutions:
> A) Always instantiate SimpleDateFormat with Locale.ENGLISH
> B) Make two instances of SimpleDateFormat. One without providing a locale
> and one with Locale.ENGLISH. Try two parsings
> C) Make as many SimpleDateFormat instances as locales are availble iterate
> over all instances at the parsing attempts.
> D) provide an additional (optional) parameter to parseDate for providing a
> Locale
> I would prefer B) as this seems the best trade-off between
> internationalization and local usage.
> What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default locale; add Locale support
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461160#comment-13461160
]
Duncan Jones commented on LANG-799:
---
Also, we should now remove {{testParseBadLocale()}} as we are no longer
checking the Locale upon entry to the method.
> DateUtils#parseDate uses default locale; add Locale support
> ---
>
> Key: LANG-799
> URL: https://issues.apache.org/jira/browse/LANG-799
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
>Reporter: Oliver Kopp
>Priority: Minor
> Labels: features
> Fix For: 3.2
>
> Attachments: commons-lang3-LANG-799.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
> Following line throws an ParseException on a German system:
> d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", new String[] {"EEE,
> dd MMM HH:mm:ss zzz"});
> Reason: parseDate internally calls SimpleDateFormat without providing a
> locale. This causes "MMM" to be interpreted using the system locale. If the
> system is German, the date is trying to be interpreted as German date.
> I see following solutions:
> A) Always instantiate SimpleDateFormat with Locale.ENGLISH
> B) Make two instances of SimpleDateFormat. One without providing a locale
> and one with Locale.ENGLISH. Try two parsings
> C) Make as many SimpleDateFormat instances as locales are availble iterate
> over all instances at the parsing attempts.
> D) provide an additional (optional) parameter to parseDate for providing a
> Locale
> I would prefer B) as this seems the best trade-off between
> internationalization and local usage.
> What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default locale; add Locale support
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461159#comment-13461159
]
Joerg Schaible commented on LANG-799:
-
Please, ensure the tests ruin with Java 5 as well as with newer ones. And note,
that the JDK switched the behavior between Java 5 and 6. Java 5 always uses
English time zone short cuts (e.g. "CET" for Central European Time), while they
are localized since Java 6 ("MEZ" for Mitteleuropäische Zeit).
> DateUtils#parseDate uses default locale; add Locale support
> ---
>
> Key: LANG-799
> URL: https://issues.apache.org/jira/browse/LANG-799
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
>Reporter: Oliver Kopp
>Priority: Minor
> Labels: features
> Fix For: 3.2
>
> Attachments: commons-lang3-LANG-799.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
> Following line throws an ParseException on a German system:
> d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", new String[] {"EEE,
> dd MMM HH:mm:ss zzz"});
> Reason: parseDate internally calls SimpleDateFormat without providing a
> locale. This causes "MMM" to be interpreted using the system locale. If the
> system is German, the date is trying to be interpreted as German date.
> I see following solutions:
> A) Always instantiate SimpleDateFormat with Locale.ENGLISH
> B) Make two instances of SimpleDateFormat. One without providing a locale
> and one with Locale.ENGLISH. Try two parsings
> C) Make as many SimpleDateFormat instances as locales are availble iterate
> over all instances at the parsing attempts.
> D) provide an additional (optional) parameter to parseDate for providing a
> Locale
> I would prefer B) as this seems the best trade-off between
> internationalization and local usage.
> What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default locale; add Locale support
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461157#comment-13461157
]
Duncan Jones commented on LANG-799:
---
That last commit now breaks the build, as my test
{{testParseNonSystemLocale()}} assumed the localized pattern change and now
fails.
I suggest you add a couple of tests, based on your new tests. E.g. you have:
{code}
// Parse German date with English Locale
@Test(expected=ParseException.class)
public void testLANG799_EN_FAIL() throws ParseException {
Locale dflt = Locale.getDefault();
Locale.setDefault(Locale.ENGLISH);
try {
DateUtils.parseDate("Mi, 09 Apr 2008 23:55:38 GMT", "EEE, dd MMM
HH:mm:ss zzz");
} finally {
Locale.setDefault(dflt);
}
}
{code}
And so I would now add, for example:
{code}
// Parse German date with English Locale, specifying German Locale override
@Test
public void testLANG799_EN_WITH_DE_LOCALE() throws ParseException {
Locale dflt = Locale.getDefault();
Locale.setDefault(Locale.ENGLISH);
try {
DateUtils.parseDate("Mi, 09 Apr 2008 23:55:38 GMT", Locale.GERMAN,
"EEE, dd MMM HH:mm:ss zzz");
} finally {
Locale.setDefault(dflt);
}
}
{code}
You can ditch my test {{testParseNonSystemLocale}} and the associated
{{getLongDateFormatForLocale}}.
> DateUtils#parseDate uses default locale; add Locale support
> ---
>
> Key: LANG-799
> URL: https://issues.apache.org/jira/browse/LANG-799
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
>Reporter: Oliver Kopp
>Priority: Minor
> Labels: features
> Fix For: 3.2
>
> Attachments: commons-lang3-LANG-799.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
> Following line throws an ParseException on a German system:
> d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", new String[] {"EEE,
> dd MMM HH:mm:ss zzz"});
> Reason: parseDate internally calls SimpleDateFormat without providing a
> locale. This causes "MMM" to be interpreted using the system locale. If the
> system is German, the date is trying to be interpreted as German date.
> I see following solutions:
> A) Always instantiate SimpleDateFormat with Locale.ENGLISH
> B) Make two instances of SimpleDateFormat. One without providing a locale
> and one with Locale.ENGLISH. Try two parsings
> C) Make as many SimpleDateFormat instances as locales are availble iterate
> over all instances at the parsing attempts.
> D) provide an additional (optional) parameter to parseDate for providing a
> Locale
> I would prefer B) as this seems the best trade-off between
> internationalization and local usage.
> What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-799) DateUtils#parseDate uses default locale; add Locale support
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved LANG-799.
---
Resolution: Fixed
Fix Version/s: 3.2
Applied patch with minor tweaks:
- dropped check for valid Locale
- use applyPattern not applyLocalizedPattern
URL: http://svn.apache.org/viewvc?rev=1388806&view=rev
Log:
LANG-799 - DateUtils#parseDate uses default locale; add Locale support
Modified:
commons/proper/lang/trunk/src/changes/changes.xml
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DateUtils.java
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java
> DateUtils#parseDate uses default locale; add Locale support
> ---
>
> Key: LANG-799
> URL: https://issues.apache.org/jira/browse/LANG-799
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
>Reporter: Oliver Kopp
>Priority: Minor
> Labels: features
> Fix For: 3.2
>
> Attachments: commons-lang3-LANG-799.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
> Following line throws an ParseException on a German system:
> d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", new String[] {"EEE,
> dd MMM HH:mm:ss zzz"});
> Reason: parseDate internally calls SimpleDateFormat without providing a
> locale. This causes "MMM" to be interpreted using the system locale. If the
> system is German, the date is trying to be interpreted as German date.
> I see following solutions:
> A) Always instantiate SimpleDateFormat with Locale.ENGLISH
> B) Make two instances of SimpleDateFormat. One without providing a locale
> and one with Locale.ENGLISH. Try two parsings
> C) Make as many SimpleDateFormat instances as locales are availble iterate
> over all instances at the parsing attempts.
> D) provide an additional (optional) parameter to parseDate for providing a
> Locale
> I would prefer B) as this seems the best trade-off between
> internationalization and local usage.
> What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-799) DateUtils#parseDate uses default locale; add Locale support
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated LANG-799:
--
Summary: DateUtils#parseDate uses default locale; add Locale support (was:
DateUtils#parseDate uses default locale instead of US (or trying both default
locale and Locale.English))
> DateUtils#parseDate uses default locale; add Locale support
> ---
>
> Key: LANG-799
> URL: https://issues.apache.org/jira/browse/LANG-799
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
>Reporter: Oliver Kopp
>Priority: Minor
> Labels: features
> Attachments: commons-lang3-LANG-799.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
> Following line throws an ParseException on a German system:
> d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", new String[] {"EEE,
> dd MMM HH:mm:ss zzz"});
> Reason: parseDate internally calls SimpleDateFormat without providing a
> locale. This causes "MMM" to be interpreted using the system locale. If the
> system is German, the date is trying to be interpreted as German date.
> I see following solutions:
> A) Always instantiate SimpleDateFormat with Locale.ENGLISH
> B) Make two instances of SimpleDateFormat. One without providing a locale
> and one with Locale.ENGLISH. Try two parsings
> C) Make as many SimpleDateFormat instances as locales are availble iterate
> over all instances at the parsing attempts.
> D) provide an additional (optional) parameter to parseDate for providing a
> Locale
> I would prefer B) as this seems the best trade-off between
> internationalization and local usage.
> What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default locale instead of US (or trying both default locale and Locale.English)
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461148#comment-13461148
]
Sebb commented on LANG-799:
---
The patch breaks the tests I just added for UK and DE parsing.
This is because the patch now uses
parser.applyLocalizedPattern(pattern);
whereas previously it used
parser.applyPattern(pattern);
I think it's wrong to assume that the patterns are localised; it will
potentially break existing applications (just as it broke the tests I just
added).
> DateUtils#parseDate uses default locale instead of US (or trying both default
> locale and Locale.English)
>
>
> Key: LANG-799
> URL: https://issues.apache.org/jira/browse/LANG-799
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
>Reporter: Oliver Kopp
>Priority: Minor
> Labels: features
> Attachments: commons-lang3-LANG-799.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
> Following line throws an ParseException on a German system:
> d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", new String[] {"EEE,
> dd MMM HH:mm:ss zzz"});
> Reason: parseDate internally calls SimpleDateFormat without providing a
> locale. This causes "MMM" to be interpreted using the system locale. If the
> system is German, the date is trying to be interpreted as German date.
> I see following solutions:
> A) Always instantiate SimpleDateFormat with Locale.ENGLISH
> B) Make two instances of SimpleDateFormat. One without providing a locale
> and one with Locale.ENGLISH. Try two parsings
> C) Make as many SimpleDateFormat instances as locales are availble iterate
> over all instances at the parsing attempts.
> D) provide an additional (optional) parameter to parseDate for providing a
> Locale
> I would prefer B) as this seems the best trade-off between
> internationalization and local usage.
> What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default locale instead of US (or trying both default locale and Locale.English)
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461140#comment-13461140
]
Sebb commented on LANG-799:
---
Not sure it's necessary for the code to check that the Locale is supported.
Seems to me such a check should be done by the caller if required.
> DateUtils#parseDate uses default locale instead of US (or trying both default
> locale and Locale.English)
>
>
> Key: LANG-799
> URL: https://issues.apache.org/jira/browse/LANG-799
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
>Reporter: Oliver Kopp
>Priority: Minor
> Labels: features
> Attachments: commons-lang3-LANG-799.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
> Following line throws an ParseException on a German system:
> d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", new String[] {"EEE,
> dd MMM HH:mm:ss zzz"});
> Reason: parseDate internally calls SimpleDateFormat without providing a
> locale. This causes "MMM" to be interpreted using the system locale. If the
> system is German, the date is trying to be interpreted as German date.
> I see following solutions:
> A) Always instantiate SimpleDateFormat with Locale.ENGLISH
> B) Make two instances of SimpleDateFormat. One without providing a locale
> and one with Locale.ENGLISH. Try two parsings
> C) Make as many SimpleDateFormat instances as locales are availble iterate
> over all instances at the parsing attempts.
> D) provide an additional (optional) parameter to parseDate for providing a
> Locale
> I would prefer B) as this seems the best trade-off between
> internationalization and local usage.
> What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default locale instead of US (or trying both default locale and Locale.English)
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461137#comment-13461137
]
Sebb commented on LANG-799:
---
Added tests to show current behaviour, i.e. ParseException occurs if default
Locale does not match date:
URL: http://svn.apache.org/viewvc?rev=1388787&view=rev
Log:
LANG-799 Add tests to show ParseException when default Locale is wrong
Modified:
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java
Some of these would need to be changed if option D is not used.
> DateUtils#parseDate uses default locale instead of US (or trying both default
> locale and Locale.English)
>
>
> Key: LANG-799
> URL: https://issues.apache.org/jira/browse/LANG-799
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
>Reporter: Oliver Kopp
>Priority: Minor
> Labels: features
> Attachments: commons-lang3-LANG-799.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
> Following line throws an ParseException on a German system:
> d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", new String[] {"EEE,
> dd MMM HH:mm:ss zzz"});
> Reason: parseDate internally calls SimpleDateFormat without providing a
> locale. This causes "MMM" to be interpreted using the system locale. If the
> system is German, the date is trying to be interpreted as German date.
> I see following solutions:
> A) Always instantiate SimpleDateFormat with Locale.ENGLISH
> B) Make two instances of SimpleDateFormat. One without providing a locale
> and one with Locale.ENGLISH. Try two parsings
> C) Make as many SimpleDateFormat instances as locales are availble iterate
> over all instances at the parsing attempts.
> D) provide an additional (optional) parameter to parseDate for providing a
> Locale
> I would prefer B) as this seems the best trade-off between
> internationalization and local usage.
> What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-868) Default sigma for CMAESOptimizer is wrong when using bounds
[ https://issues.apache.org/jira/browse/MATH-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461128#comment-13461128 ] Gilles commented on MATH-868: - IIUC, the "inputSigma" should never be divided by the "range" but rather should be enforced to lie in the (0, 1) interval (and the documentation should suggest that "0.3" is a good default, and the value that is used when the user did not pass an "inputSigma" argument). What do you think? > Default sigma for CMAESOptimizer is wrong when using bounds > --- > > Key: MATH-868 > URL: https://issues.apache.org/jira/browse/MATH-868 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > > The documentation suggests setting inputSigma to 1/3 the range you are > fitting over. However, in CMAESOptimizer.initializeCMA() if boundaries are > specified the sigmaArray is by default assigned a value of 0.3 divided by the > range. If the user had specified the inputSigma to be 0.3 of the range (as > suggested by the docs) then sigmaArray would have been assigned the value of > 0.3. Thus, it looks like the 0.3 should not be divided by the range, only a > user-specified inputSigma should get divided by the range. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
[
https://issues.apache.org/jira/browse/LANG-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461108#comment-13461108
]
Duncan Jones commented on LANG-796:
---
I agree with Nicola. A class that intends to work with Date values should not
be interested in daylight savings. I suspect this was an unintentional error on
the part of the original implementation.
At the very least, the Javadocs need to change to reflect this behaviour.
The issue with changing the code is that people may already be relying on this
behaviour. All of the {{addXXX}} methods use Calendars and would be impacted.
> DateUtils.addDays does not work properly with daylight saving time (DST)
>
>
> Key: LANG-796
> URL: https://issues.apache.org/jira/browse/LANG-796
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 2.6
>Reporter: Nicola Barbiero
>
> DateUtils.addDays does not work properly with daylight saving time.
> The signature of the method is
> Date addDays(Date date, int amount)
> and the javadocs says "Adds a number of days to a date returning a new
> object. The original date object is unchanged",
> so if X=date.getTime() is the number of milliseconds of the date in input,
> the expected behaviour is that the returned Date has a number of milliseconds
> equal to X+amount*(8640), where 8640 is the number of milliseconds in
> one day.
> But when the calculation goes across the DST change date, the number of
> milliseconds added does not correspond to whole days.
> For example, here in Brussels, this code fragment:
>Date input = DateUtils.parseDateStrictly("25-03-2012_00:00", new String[]
> { "dd-MM-_HH:mm" });
>Date output = DateUtils.addDays(input, 1);
> will give:
> 'input' equals to "Sun Mar 25 00:00:00 CET 2012"==> input.getTime()
> equals to 133263000
> 'output' equals to "Mon Mar 26 00:00:00 CEST 2012" ==> output.getTime()
> equals to 133271280
> where 133271280-133263000=8280 < 8640
> (in fact 8280 is equivalent to 23h).
> Since addDays is working with objects Date, it should not be influenced by
> events like the DST.
> Proposed solution: replace the current implementation
> public static Date add(Date date, int calendarField, int amount) {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> Calendar c = Calendar.getInstance();
> c.setTime(date);
> c.add(calendarField, amount);
> return c.getTime();
> }
> based on Calendar with an implementation that works only with Date objects,
> for example:
> public static Date add(Date date, int calendarField, int amount) {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> return new Date(input.getTime() + amount * 8640l);
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-864) CMAESOptimizer does not enforce bounds
[ https://issues.apache.org/jira/browse/MATH-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-864. - Resolution: Fixed > CMAESOptimizer does not enforce bounds > -- > > Key: MATH-864 > URL: https://issues.apache.org/jira/browse/MATH-864 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Frank Hess >Assignee: Gilles > Fix For: 3.1 > > Attachments: Math864Test.java > > > The CMAESOptimizer can exceed the bounds passed to optimize. Looking at the > generationLoop in doOptimize(), it does a bounds check by calling > isFeasible() but if checkFeasableCount is zero (the default) then > isFeasible() is never even called. Also, even with non-zero > checkFeasableCount it may give up before finding an in-bounds offspring and > go forward with an out-of-bounds offspring. This is against svn revision > 1387637. I can provide an example program where the optimizer ends up with a > fit outside the prescribed bounds if that would help. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-865) Wide bounds to CMAESOptimizer result in NaN parameters passed to fitness function
[ https://issues.apache.org/jira/browse/MATH-865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-865. - Resolution: Fixed > Wide bounds to CMAESOptimizer result in NaN parameters passed to fitness > function > - > > Key: MATH-865 > URL: https://issues.apache.org/jira/browse/MATH-865 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Frank Hess >Assignee: Gilles > Fix For: 3.1 > > Attachments: Math865Test.java > > > If you give large values as lower/upper bounds (for example -Double.MAX_VALUE > as a lower bound), the optimizer can call the fitness function with > parameters set to NaN. My guess is this is due to > FitnessFunction.encode/decode generating NaN when normalizing/denormalizing > parameters. For example, if the difference between the lower and upper bound > is greater than Double.MAX_VALUE, encode could divide infinity by infinity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-815) DurationFormatUtils.formatPeriod() miss-calculation
[
https://issues.apache.org/jira/browse/LANG-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461101#comment-13461101
]
Duncan Jones commented on LANG-815:
---
I don't believe this is a bug. Below is a test case that should demonstrate the
issue, but it passes just fine:
{code}
@Test
public void testLANG815() {
Calendar calendar = Calendar.getInstance();
calendar.set(2012, 6, 30, 0, 0, 0);
long startMillis = calendar.getTimeInMillis();
calendar.set(2012, 8, 8);
long endMillis = calendar.getTimeInMillis();
assertEquals("1 9", DurationFormatUtils
.formatPeriod(startMillis, endMillis, "M d"));
}
{code}
> DurationFormatUtils.formatPeriod() miss-calculation
> ---
>
> Key: LANG-815
> URL: https://issues.apache.org/jira/browse/LANG-815
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.1
> Environment: JDK 1.7
>Reporter: Naoya Sugioka
> Attachments: duration-format.diff
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Hello,
> I just encountered an issue with DurationFormatUtils.formatPeriod()
> and here I suggest the patch.
> The problem is found when calcurating a duration between June 30 to August 8.
> Duration must be 1 month and 9 days (June 30 + 1 month = July 30,
> July 30 + 9 Days = August 8)
> but current logic tells this duration is 1 month and 8 days.
> then I found out the logic to adjust days value if it was negative by
> initial estimate. it uses start date
> (June in above case) but must use prev month of end date (July in
> above case). then days value was
> wrong since getActualMaximum() will return a wrong number.
> thank you,
> -Naoya
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
