[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-tabpanel&focusedCommentId=13615855#comment-13615855 ] Pavel Ryzhov commented on MATH-463: --- Just to say that it was moved to GitHub: https://github.com/paulrzcz/montecarlo > 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 > 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. 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] [Reopened] (MATH-463) Monte Carlo engine with 1D path
[ https://issues.apache.org/jira/browse/MATH-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart reopened MATH-463: -- Reopened as this would be a nice addition, and the code is availabe on google code. > 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 > 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. 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-949) LevenbergMarquardtOptimizer reports 0 iterations
[
https://issues.apache.org/jira/browse/MATH-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated MATH-949:
-
Fix Version/s: 3.2
> LevenbergMarquardtOptimizer reports 0 iterations
>
>
> Key: MATH-949
> URL: https://issues.apache.org/jira/browse/MATH-949
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.2
>Reporter: Evan Ward
> Fix For: 3.2
>
>
> The method LevenbergMarquardtOptimizer.getIterations() does not report the
> correct number of iterations; It always returns 0. A quick look at the code
> shows that only SimplexOptimizer calls
> BaseOptimizer.incrementEvaluationsCount()
> I've put a test case below. Notice how the evaluations count is correctly
> incremented, but the iterations count is not.
> {noformat}
> @Test
> public void testGetIterations() {
> // setup
> LevenbergMarquardtOptimizer otim = new LevenbergMarquardtOptimizer();
> // action
> otim.optimize(new MaxEval(100), new Target(new double[] { 1 }),
> new Weight(new double[] { 1 }), new InitialGuess(
> new double[] { 3 }), new ModelFunction(
> new MultivariateVectorFunction() {
> @Override
> public double[] value(double[] point)
> throws IllegalArgumentException {
> return new double[] { FastMath.pow(point[0],
> 4) };
> }
> }), new ModelFunctionJacobian(
> new MultivariateMatrixFunction() {
> @Override
> public double[][] value(double[] point)
> throws IllegalArgumentException {
> return new double[][] { { 0.25 * FastMath.pow(
> point[0], 3) } };
> }
> }));
> // verify
> assertThat(otim.getEvaluations(), greaterThan(1));
> assertThat(otim.getIterations(), greaterThan(1));
> }
> {noformat}
--
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-935) DerivativeStructure.atan2(y,x) does not handle special cases properly
[ https://issues.apache.org/jira/browse/MATH-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated MATH-935: - Fix Version/s: 3.2 > DerivativeStructure.atan2(y,x) does not handle special cases properly > - > > Key: MATH-935 > URL: https://issues.apache.org/jira/browse/MATH-935 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Luc Maisonobe >Priority: Minor > Fix For: 3.2 > > > The four special cases +/-0 for both x and y should give the same values as > Math.atan2 and FastMath.atan2. However, they give NaN for the value in all > cases. -- 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-892) Add a constructor for SpearmansCorrelation that allows to solely set the Ranking algorithm
[
https://issues.apache.org/jira/browse/MATH-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart updated MATH-892:
-
Fix Version/s: 3.1
> Add a constructor for SpearmansCorrelation that allows to solely set the
> Ranking algorithm
> --
>
> Key: MATH-892
> URL: https://issues.apache.org/jira/browse/MATH-892
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Thomas Neidhart
> Fix For: 3.1
>
>
> As suggested by Patrick Meyer on the users mailinglist:
> currently there is no way to create an instance of SpearmansCorrelation and
> set the used RankingAlgorithm.
> There are ctors to provide both data and algorithm, but it would be
> convenient to have a ctor that only sets the algorithm and allows for later
> calls to correlate, suggested signature:
> {noformat}
> public SpearmansCorrelation(final RankingAlgorithm rankingAlgorithm)
> {noformat}
--
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] [Closed] (MATH-892) Add a constructor for SpearmansCorrelation that allows to solely set the Ranking algorithm
[
https://issues.apache.org/jira/browse/MATH-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart closed MATH-892.
> Add a constructor for SpearmansCorrelation that allows to solely set the
> Ranking algorithm
> --
>
> Key: MATH-892
> URL: https://issues.apache.org/jira/browse/MATH-892
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Thomas Neidhart
> Fix For: 3.1
>
>
> As suggested by Patrick Meyer on the users mailinglist:
> currently there is no way to create an instance of SpearmansCorrelation and
> set the used RankingAlgorithm.
> There are ctors to provide both data and algorithm, but it would be
> convenient to have a ctor that only sets the algorithm and allows for later
> calls to correlate, suggested signature:
> {noformat}
> public SpearmansCorrelation(final RankingAlgorithm rankingAlgorithm)
> {noformat}
--
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-959) Add HAC clustering algorithm
Thomas Neidhart created MATH-959: Summary: Add HAC clustering algorithm Key: MATH-959 URL: https://issues.apache.org/jira/browse/MATH-959 Project: Commons Math Issue Type: Sub-task Reporter: Thomas Neidhart Fix For: 4.0 Add at least one hierarchical clustering algorithm. With the refactoring of the clustering package, this should now be feasible as the Cluster class can be extended. -- 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-917) More distance measurements are needed in o.a.c.m.stat.clustering.
[ https://issues.apache.org/jira/browse/MATH-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-917. -- Resolution: Fixed Fix Version/s: (was: 4.0) 3.2 Finalized in r1461873. > More distance measurements are needed in o.a.c.m.stat.clustering. > - > > Key: MATH-917 > URL: https://issues.apache.org/jira/browse/MATH-917 > Project: Commons Math > Issue Type: Improvement >Reporter: Reid Hochstedler > Fix For: 3.2 > > Attachments: clustering_v2.zip, clustering.zip > > > Currently only Euclidean distance is used for distance measurement, it would > be easy to quickly add Manhattan and Chebyshev distance among others. -- 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-919) Chebyshev distance
[ https://issues.apache.org/jira/browse/MATH-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-919. -- Resolution: Fixed Fix Version/s: (was: 4.0) 3.2 Added in r1461862. Thanks for the report and patch. > Chebyshev distance > -- > > Key: MATH-919 > URL: https://issues.apache.org/jira/browse/MATH-919 > Project: Commons Math > Issue Type: Sub-task >Reporter: Reid Hochstedler > Fix For: 3.2 > > Attachments: MATH-919.patch > > -- 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-920) Canberra Distance
[ https://issues.apache.org/jira/browse/MATH-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-920. -- Resolution: Fixed Fix Version/s: (was: 4.0) 3.2 Added in r1461862. Thanks for the report and patch! > Canberra Distance > - > > Key: MATH-920 > URL: https://issues.apache.org/jira/browse/MATH-920 > Project: Commons Math > Issue Type: Sub-task >Reporter: Reid Hochstedler > Fix For: 3.2 > > Attachments: MATH-920.patch > > -- 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-918) Manhattan distance
[ https://issues.apache.org/jira/browse/MATH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-918. -- Resolution: Fixed Fix Version/s: (was: 4.0) 3.2 Added in r1461862. > Manhattan distance > -- > > Key: MATH-918 > URL: https://issues.apache.org/jira/browse/MATH-918 > Project: Commons Math > Issue Type: Sub-task >Reporter: Reid Hochstedler > Fix For: 3.2 > > Attachments: MATH-918.patch > > -- 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-917) More distance measurements are needed in o.a.c.m.stat.clustering.
[ https://issues.apache.org/jira/browse/MATH-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615802#comment-13615802 ] Thomas Neidhart commented on MATH-917: -- Applied patch with changes + tests in r1461862: * changed Clusterer to an abstract class * changed Clusterable interface to require only one method: double[] getPoint() * kept DoublePoint, and it also wraps an int[]: imho this class makes sense as it does not require someone to implement Clusterable for simple use-cases * created overridden constructors for providing a DistanceMeasure * added tests * added getters for the customisable arguments of a clusterer I guess we could continue discussing the API, but for now it is pretty fine imho, we can evaluate if it is well suited and adjust if needed in 4.0. Still need to deprecate the old package. > More distance measurements are needed in o.a.c.m.stat.clustering. > - > > Key: MATH-917 > URL: https://issues.apache.org/jira/browse/MATH-917 > Project: Commons Math > Issue Type: Improvement >Reporter: Reid Hochstedler > Fix For: 4.0 > > Attachments: clustering_v2.zip, clustering.zip > > > Currently only Euclidean distance is used for distance measurement, it would > be easy to quickly add Manhattan and Chebyshev distance among others. -- 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-891) SpearmansCorrelation fails when using NaturalRanking together with NaNStrategy.REMOVED
[ https://issues.apache.org/jira/browse/MATH-891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-891. -- Resolution: Fixed Fix Version/s: 3.2 Applied changes in r1461822 and created MATH-958. > SpearmansCorrelation fails when using NaturalRanking together with > NaNStrategy.REMOVED > -- > > Key: MATH-891 > URL: https://issues.apache.org/jira/browse/MATH-891 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Thomas Neidhart > Fix For: 3.2 > > Attachments: MATH-891.patch > > > As reported by Martin Rosellen on the users mailinglist: > Using a NaturalRanking with a REMOVED NaNStrategy can result in an exception > when NaN are contained in the input arrays. > The current implementation just removes the NaN values where they occur, > without taken care to remove the corresponding values in the other array. -- 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-958) Remove support for NaNStrategy.REMOVED in SpearmansCorrelation
Thomas Neidhart created MATH-958: Summary: Remove support for NaNStrategy.REMOVED in SpearmansCorrelation Key: MATH-958 URL: https://issues.apache.org/jira/browse/MATH-958 Project: Commons Math Issue Type: Task Reporter: Thomas Neidhart Fix For: 4.0 The temporary fix applied for MATH-891 shall be removed and in case a RankingAlgorithm with a NaNStrategy.Removed is used, an Exception shall be thrown. -- 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-957) Use analytical function for UniformRealDistribution.inverseCumulativeProbability
[ https://issues.apache.org/jira/browse/MATH-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evan Ward updated MATH-957: --- Attachment: uniform.patch Implementation and test case. > Use analytical function for > UniformRealDistribution.inverseCumulativeProbability > > > Key: MATH-957 > URL: https://issues.apache.org/jira/browse/MATH-957 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Evan Ward > Attachments: uniform.patch > > > The inverse CDF is currently solved by a root finding function. It would be > much simpler (and faster) to use the analytical expression. This would save > the user from having to set the inverseCumAccuracy correctly. > I've attached a patch that implements this. -- 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] [Comment Edited] (MATH-957) Use analytical function for UniformRealDistribution.inverseCumulativeProbability
[ https://issues.apache.org/jira/browse/MATH-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615646#comment-13615646 ] Evan Ward edited comment on MATH-957 at 3/27/13 7:20 PM: - Implementation and test case attached. was (Author: evanward1): Implementation and test case. > Use analytical function for > UniformRealDistribution.inverseCumulativeProbability > > > Key: MATH-957 > URL: https://issues.apache.org/jira/browse/MATH-957 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Evan Ward > Attachments: uniform.patch > > > The inverse CDF is currently solved by a root finding function. It would be > much simpler (and faster) to use the analytical expression. This would save > the user from having to set the inverseCumAccuracy correctly. > I've attached a patch that implements this. -- 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-957) Use analytical function for UniformRealDistribution.inverseCumulativeProbability
Evan Ward created MATH-957: -- Summary: Use analytical function for UniformRealDistribution.inverseCumulativeProbability Key: MATH-957 URL: https://issues.apache.org/jira/browse/MATH-957 Project: Commons Math Issue Type: Bug Affects Versions: 3.2 Reporter: Evan Ward The inverse CDF is currently solved by a root finding function. It would be much simpler (and faster) to use the analytical expression. This would save the user from having to set the inverseCumAccuracy correctly. I've attached a patch that implements this. -- 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] (JCS-100) JCS never going out of the dispose methode
[ https://issues.apache.org/jira/browse/JCS-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615616#comment-13615616 ] Thomas Vandahl commented on JCS-100: I'm sorry to hear that. Does the current trunk show the same behavior? A lot of those race-condition-type issues have been addressed. > JCS never going out of the dispose methode > -- > > Key: JCS-100 > URL: https://issues.apache.org/jira/browse/JCS-100 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-1.3 > Environment: Windows >Reporter: Jean-Marc Spaggiari > > I have an application using many threads all calling JCS. When I close the > application, the cache is usually working fine, but sometime, it stays > stucked on the dispose methode. > The cacheEventQueue never going empty. Then it's looping on while ( keepGoing > ) and never ending. I have to kill the application to exit. > It's difficult to reproduce. There is no fixed pattern so far. -- 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-891) SpearmansCorrelation fails when using NaturalRanking together with NaNStrategy.REMOVED
[ https://issues.apache.org/jira/browse/MATH-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615500#comment-13615500 ] Phil Steitz commented on MATH-891: -- I am OK with committing this patch, but lets keep the issue open, or open another one for handling missing data in multivariate stats. I think it is OK to leave the RankingAlgorithm interface and impls as is - they are doing what they should be doing by contract. I think multivariate stats should just not allow the REMOVED NAN strategy (i.e. throw in this case). Once we agree on how to implement and represent missing data strategies at least just for this class, the Spearman's constructor should then be modified to include specification of missing data strategy. I think it is better to commit the workaround now, since behavior is currently broken; but note in the javadoc and release notes that as of 4.0, the constructor will throw on REMOVED NaNStrategy and NANs should not be used to represent missing data. Practical advice to users is to preprocess data to remove / replace / impute missing data in preparation for this. > SpearmansCorrelation fails when using NaturalRanking together with > NaNStrategy.REMOVED > -- > > Key: MATH-891 > URL: https://issues.apache.org/jira/browse/MATH-891 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Thomas Neidhart > Attachments: MATH-891.patch > > > As reported by Martin Rosellen on the users mailinglist: > Using a NaturalRanking with a REMOVED NaNStrategy can result in an exception > when NaN are contained in the input arrays. > The current implementation just removes the NaN values where they occur, > without taken care to remove the corresponding values in the other array. -- 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] (CSV-96) CSVRecord does not verify that the length of the header mapping matches the number of values
[
https://issues.apache.org/jira/browse/CSV-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615468#comment-13615468
]
Gary Gregory commented on CSV-96:
-
So is this a matter of which exception to throw?
> CSVRecord does not verify that the length of the header mapping matches the
> number of values
>
>
> Key: CSV-96
> URL: https://issues.apache.org/jira/browse/CSV-96
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.0
>Reporter: Benedikt Ritter
> Fix For: 1.0
>
>
> CSVRecord does not verify that the size of the header mapping matches the
> number of values. The following test will produce a ArrayOutOfBoundsException:
> {code}
> @Test
> public void testInvalidHeaderTooLong() throws Exception {
>final CSVParser parser = new CSVParser("a,b",
> CSVFormat.newBuilder().withHeader("A", "B", "C").build());
>final CSVRecord record = parser.iterator().next();
>record.get("C");
> }
> {code}
--
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-881) NumberUtils.createNumber() Javadoc says it does not work for octal numbers
[
https://issues.apache.org/jira/browse/LANG-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615464#comment-13615464
]
Sebb commented on LANG-881:
---
Applied fixes:
URL: http://svn.apache.org/r1461671
Log:
LANG-881 NumberUtils.createNumber() Javadoc says it does not work for octal
numbers
Modified:
commons/proper/lang/trunk/src/changes/changes.xml
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/math/NumberUtils.java
URL: http://svn.apache.org/r1461654
Log:
LANG-881 Enhance test so it also checks the exact values
Modified:
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/math/NumberUtilsTest.java
> NumberUtils.createNumber() Javadoc says it does not work for octal numbers
> ---
>
> Key: LANG-881
> URL: https://issues.apache.org/jira/browse/LANG-881
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.1
>Reporter: Michiel Kalkman
>Priority: Minor
>
> The javadoc for NumberUtils.createNumber() states:
> "Values with leading 0's will not be interpreted as octal."
> However,
> assertEquals(25, NumberUtils.createNumber("0025"));
> fails, because NumberUtils.createNumber("0025") returns 21.
--
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-881) NumberUtils.createNumber() Javadoc says it does not work for octal numbers
[
https://issues.apache.org/jira/browse/LANG-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved LANG-881.
---
Resolution: Fixed
Fix Version/s: 3.2
> NumberUtils.createNumber() Javadoc says it does not work for octal numbers
> ---
>
> Key: LANG-881
> URL: https://issues.apache.org/jira/browse/LANG-881
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.1
>Reporter: Michiel Kalkman
>Priority: Minor
> Fix For: 3.2
>
>
> The javadoc for NumberUtils.createNumber() states:
> "Values with leading 0's will not be interpreted as octal."
> However,
> assertEquals(25, NumberUtils.createNumber("0025"));
> fails, because NumberUtils.createNumber("0025") returns 21.
--
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-881) NumberUtils.createNumber() Javadoc says it does not work for octal numbers
[
https://issues.apache.org/jira/browse/LANG-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated LANG-881:
--
Summary: NumberUtils.createNumber() Javadoc says it does not work for
octal numbers (was: NumberUtils.createNumber() does not work for octal
numbers)
> NumberUtils.createNumber() Javadoc says it does not work for octal numbers
> ---
>
> Key: LANG-881
> URL: https://issues.apache.org/jira/browse/LANG-881
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.1
>Reporter: Michiel Kalkman
>Priority: Minor
>
> The javadoc for NumberUtils.createNumber() states:
> "Values with leading 0's will not be interpreted as octal."
> However,
> assertEquals(25, NumberUtils.createNumber("0025"));
> fails, because NumberUtils.createNumber("0025") returns 21.
--
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-881) NumberUtils.createNumber() does not work for octal numbers
[
https://issues.apache.org/jira/browse/LANG-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615351#comment-13615351
]
Sebb commented on LANG-881:
---
I suspect that is because it uses createLong() and createBigInteger() which
used not to handle octal prefixes.
This was fixed in 3.1 and 3.2 (not yet released) respectively.
So createNumber() should now handle octal numbers for all integral sizes, i.e.
I think the Javadoc is wrong.
There are already tests which show the behaviour implicitly, for example:
{code}
assertEquals(Integer.class,
NumberUtils.createNumber("0177").getClass()); // 31 bits
assertEquals(Long.class,
NumberUtils.createNumber("0377").getClass()); // 32 bits
{code}
These should be extended/amended to check the value as well.
> NumberUtils.createNumber() does not work for octal numbers
> ---
>
> Key: LANG-881
> URL: https://issues.apache.org/jira/browse/LANG-881
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.1
>Reporter: Michiel Kalkman
>Priority: Minor
>
> The javadoc for NumberUtils.createNumber() states:
> "Values with leading 0's will not be interpreted as octal."
> However,
> assertEquals(25, NumberUtils.createNumber("0025"));
> fails, because NumberUtils.createNumber("0025") returns 21.
--
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-437) Kolmogorov Smirnov Distribution
[ https://issues.apache.org/jira/browse/MATH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-437: - Fix Version/s: (was: 3.2) 4.0 > Kolmogorov Smirnov Distribution > --- > > Key: MATH-437 > URL: https://issues.apache.org/jira/browse/MATH-437 > Project: Commons Math > Issue Type: New Feature >Reporter: Mikkel Meyer Andersen >Assignee: Phil Steitz >Priority: Minor > Fix For: 4.0 > > Attachments: ks-distribution.patch, MATH437-with-test-take-1 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Kolmogorov-Smirnov test (see [1]) is used to test if one sample against a > known probability density functions or if two samples are from the same > distribution. To evaluate the test statistic, the Kolmogorov-Smirnov > distribution is used. Quite good asymptotics exist for the one-sided test, > but it's more difficult for the two-sided test. > [1]: http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test -- This message is automatically generated by JIRA. 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] (CHAIN-80) NPE when submitting null commands map to CatalogBase
[ https://issues.apache.org/jira/browse/CHAIN-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved CHAIN-80. - Resolution: Fixed Assignee: Simone Tripodi patch applied at r1461601, thanks Steve for contributing! > NPE when submitting null commands map to CatalogBase > > > Key: CHAIN-80 > URL: https://issues.apache.org/jira/browse/CHAIN-80 > Project: Commons Chain > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Steve Westwood >Assignee: Simone Tripodi >Priority: Minor > Labels: catalog > Fix For: 2.0 > > Attachments: CHAIN-80-patch.txt > > > The command relies on _Map.putAll()_ to populate *CatalogBase* when passed > into the constructor, but as the javadocs specify at > http://docs.oracle.com/javase/6/docs/api/java/util/Map.html#putAll(java.util.Map), > this throws an NPE. The constructor requires a guard inside to protect it > from null objects being passed as an argument -- 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] (CHAIN-80) NPE when submitting null commands map to CatalogBase
[ https://issues.apache.org/jira/browse/CHAIN-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Westwood updated CHAIN-80: Attachment: CHAIN-80-patch.txt Patch for this issue, replacing old one > NPE when submitting null commands map to CatalogBase > > > Key: CHAIN-80 > URL: https://issues.apache.org/jira/browse/CHAIN-80 > Project: Commons Chain > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Steve Westwood >Priority: Minor > Labels: catalog > Fix For: 2.0 > > Attachments: CHAIN-80-patch.txt > > > The command relies on _Map.putAll()_ to populate *CatalogBase* when passed > into the constructor, but as the javadocs specify at > http://docs.oracle.com/javase/6/docs/api/java/util/Map.html#putAll(java.util.Map), > this throws an NPE. The constructor requires a guard inside to protect it > from null objects being passed as an argument -- 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] (CHAIN-80) NPE when submitting null commands map to CatalogBase
[ https://issues.apache.org/jira/browse/CHAIN-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Westwood updated CHAIN-80: Attachment: (was: CHAIN-80-patch.txt.txt) > NPE when submitting null commands map to CatalogBase > > > Key: CHAIN-80 > URL: https://issues.apache.org/jira/browse/CHAIN-80 > Project: Commons Chain > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Steve Westwood >Priority: Minor > Labels: catalog > Fix For: 2.0 > > Attachments: CHAIN-80-patch.txt > > > The command relies on _Map.putAll()_ to populate *CatalogBase* when passed > into the constructor, but as the javadocs specify at > http://docs.oracle.com/javase/6/docs/api/java/util/Map.html#putAll(java.util.Map), > this throws an NPE. The constructor requires a guard inside to protect it > from null objects being passed as an argument -- 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] [Comment Edited] (CHAIN-80) NPE when submitting null commands map to CatalogBase
[ https://issues.apache.org/jira/browse/CHAIN-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615255#comment-13615255 ] Steve Westwood edited comment on CHAIN-80 at 3/27/13 1:31 PM: -- Supplied a new patch for this issue, replacing old one was (Author: hexsaw): Patch for this issue, replacing old one > NPE when submitting null commands map to CatalogBase > > > Key: CHAIN-80 > URL: https://issues.apache.org/jira/browse/CHAIN-80 > Project: Commons Chain > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Steve Westwood >Priority: Minor > Labels: catalog > Fix For: 2.0 > > Attachments: CHAIN-80-patch.txt > > > The command relies on _Map.putAll()_ to populate *CatalogBase* when passed > into the constructor, but as the javadocs specify at > http://docs.oracle.com/javase/6/docs/api/java/util/Map.html#putAll(java.util.Map), > this throws an NPE. The constructor requires a guard inside to protect it > from null objects being passed as an argument -- 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] (OGNL-234) Remove deprecated methods
[
https://issues.apache.org/jira/browse/OGNL-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615186#comment-13615186
]
Hudson commented on OGNL-234:
-
Integrated in ognl #218 (See [https://builds.apache.org/job/ognl/218/])
OGNL-234 Removes methods marked as @Deprecated (Revision 1461509)
Result = ABORTED
lukaszlenart : http://svn.apache.org/viewvc/?view=rev&rev=1461509
Files :
*
/commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/OgnlRuntime.java
> Remove deprecated methods
> -
>
> Key: OGNL-234
> URL: https://issues.apache.org/jira/browse/OGNL-234
> Project: Commons OGNL
> Issue Type: Improvement
> Components: Core Runtime
>Affects Versions: 2.7.2
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Minor
> Fix For: 4.0
>
>
> Remove methods marked as {{@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-917) More distance measurements are needed in o.a.c.m.stat.clustering.
[ https://issues.apache.org/jira/browse/MATH-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615180#comment-13615180 ] Gilles commented on MATH-917: - * "Clusterer" should be an "abstract" class (if we are to be consistent with the changes that have been done for a few years). * It seems that accessing each component of a "Clusterable" separately is not efficient, the more so that usually _all_ components are needed. I don't see the advantage over simply requiring to return a "double[]"; any practical use case for the proposed API? * I would not include "IntegerPoint" and "DoublePoint" in the "main" repository. They should go in the "test" part (if unit tests need them). > More distance measurements are needed in o.a.c.m.stat.clustering. > - > > Key: MATH-917 > URL: https://issues.apache.org/jira/browse/MATH-917 > Project: Commons Math > Issue Type: Improvement >Reporter: Reid Hochstedler > Fix For: 4.0 > > Attachments: clustering_v2.zip, clustering.zip > > > Currently only Euclidean distance is used for distance measurement, it would > be easy to quickly add Manhattan and Chebyshev distance among others. -- 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] (OGNL-234) Remove deprecated methods
[
https://issues.apache.org/jira/browse/OGNL-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart resolved OGNL-234.
Resolution: Fixed
Done
> Remove deprecated methods
> -
>
> Key: OGNL-234
> URL: https://issues.apache.org/jira/browse/OGNL-234
> Project: Commons OGNL
> Issue Type: Improvement
> Components: Core Runtime
>Affects Versions: 2.7.2
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Minor
> Fix For: 4.0
>
>
> Remove methods marked as {{@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] [Updated] (OGNL-234) Remove deprecated methods
[
https://issues.apache.org/jira/browse/OGNL-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated OGNL-234:
---
Summary: Remove deprecated methods (was: Removed deprecated methods)
> Remove deprecated methods
> -
>
> Key: OGNL-234
> URL: https://issues.apache.org/jira/browse/OGNL-234
> Project: Commons OGNL
> Issue Type: Improvement
> Components: Core Runtime
>Affects Versions: 2.7.2
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Minor
> Fix For: 4.0
>
>
> Remove methods marked as {{@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] [Created] (OGNL-234) Removed deprecated methods
Lukasz Lenart created OGNL-234:
--
Summary: Removed deprecated methods
Key: OGNL-234
URL: https://issues.apache.org/jira/browse/OGNL-234
Project: Commons OGNL
Issue Type: Improvement
Components: Core Runtime
Affects Versions: 2.7.2
Reporter: Lukasz Lenart
Assignee: Lukasz Lenart
Priority: Minor
Fix For: 4.0
Remove methods marked as {{@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-917) More distance measurements are needed in o.a.c.m.stat.clustering.
[ https://issues.apache.org/jira/browse/MATH-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615111#comment-13615111 ] Luc Maisonobe commented on MATH-917: This seems good to me. +1 to commit. > More distance measurements are needed in o.a.c.m.stat.clustering. > - > > Key: MATH-917 > URL: https://issues.apache.org/jira/browse/MATH-917 > Project: Commons Math > Issue Type: Improvement >Reporter: Reid Hochstedler > Fix For: 4.0 > > Attachments: clustering_v2.zip, clustering.zip > > > Currently only Euclidean distance is used for distance measurement, it would > be easy to quickly add Manhattan and Chebyshev distance among others. -- 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-437) Kolmogorov Smirnov Distribution
[ https://issues.apache.org/jira/browse/MATH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13615110#comment-13615110 ] Luc Maisonobe commented on MATH-437: +1 to postpone to 4.0. I have no opinion about the usefulness of the distribution itself, so if you think it would be worth removing this part and having only the test, this would be fine with me. > Kolmogorov Smirnov Distribution > --- > > Key: MATH-437 > URL: https://issues.apache.org/jira/browse/MATH-437 > Project: Commons Math > Issue Type: New Feature >Reporter: Mikkel Meyer Andersen >Assignee: Phil Steitz >Priority: Minor > Fix For: 3.2 > > Attachments: ks-distribution.patch, MATH437-with-test-take-1 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > Kolmogorov-Smirnov test (see [1]) is used to test if one sample against a > known probability density functions or if two samples are from the same > distribution. To evaluate the test statistic, the Kolmogorov-Smirnov > distribution is used. Quite good asymptotics exist for the one-sided test, > but it's more difficult for the two-sided test. > [1]: http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test -- This message is automatically generated by JIRA. 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] (VFS-472) WebDav runs out of memory when dealing with large files
[ https://issues.apache.org/jira/browse/VFS-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Kordes updated VFS-472: -- Attachment: patch_WebdavFileObject_v2_revision-1459279.diff We came across a bug in our own solution. Since a buffered output stream is used, not all data is on the piped output stream when closing the piped streams. We added a latch to wait until all streams are closed. > WebDav runs out of memory when dealing with large files > --- > > Key: VFS-472 > URL: https://issues.apache.org/jira/browse/VFS-472 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.0 > Environment: Any >Reporter: Stefan Kordes > Labels: bytearrayoutputstream, outofmemory, webdav > Attachments: patch_WebdavFileObject_revision-1459279.txt, > patch_WebdavFileObject_v2_revision-1459279.diff > > > When copying or moving large files from any protocol to webdav, an > OutOfMemoryException is thrown. > This is because the WebDavOutputStream uses a ByteArrayOutputStream to store > the data before sending. > We have created a patch for the latest version that uses a PipedOutputStream > and a InputStreamRequestEntity to prevent that. > This issues has been reported before as VFS-47 -- 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] (LANG-881) NumberUtils.createNumber() does not work for octal numbers
Michiel Kalkman created LANG-881:
Summary: NumberUtils.createNumber() does not work for octal
numbers
Key: LANG-881
URL: https://issues.apache.org/jira/browse/LANG-881
Project: Commons Lang
Issue Type: Bug
Components: lang.math.*
Affects Versions: 3.1
Reporter: Michiel Kalkman
Priority: Minor
The javadoc for NumberUtils.createNumber() states:
"Values with leading 0's will not be interpreted as octal."
However,
assertEquals(25, NumberUtils.createNumber("0025"));
fails, because NumberUtils.createNumber("0025") returns 21.
--
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] (OGNL-233) ClassCacheHandler should return a handler with a key that is the nearest class (interface) to the forClass in the hierarchy tree
Azuo Lee created OGNL-233: - Summary: ClassCacheHandler should return a handler with a key that is the nearest class (interface) to the forClass in the hierarchy tree Key: OGNL-233 URL: https://issues.apache.org/jira/browse/OGNL-233 Project: Commons OGNL Issue Type: Bug Components: Core Runtime Reporter: Azuo Lee ClassCacheHandler enumerates over the forClass's interfaces and superclasses to find a match key class. But consider the following senario: interface A implements java.util.Collection class B extends java.util.AbstractList implements A Now if ClassCacheHandler.getHandler(B, handlers) is invoked, and assuming handlers is an empty ClassCache, according to the current enumeration logic used by ClassCacheHandler, classes (interfaces) will be enumerated in the following order: class B interface A interface java.util.Collection interface java.lang.Iterable interface java.io.Serializable class java.util.AbstractList interface java.util.List interface java.util.Collection interface java.lang.Iterable class java.util.AbstractCollection interface java.util.Collection interface java.lang.Iterable if both java.util.Collection and java.util.List are present as keys in the handlers, since java.util.Collection is enumerated first, then it will be matched, instead of java.util.List. The expected behaviour should be java.util.List is matched, because it is nearer to class B in the hierarchy tree. -- 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] (DAEMON-289) Integrate Debian patches
[ https://issues.apache.org/jira/browse/DAEMON-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614997#comment-13614997 ] Mladen Turk commented on DAEMON-289: I have further tweak the hpux/hppa/ia64 bits. So far tested on HP-UX with both gcc and aCC and it works (now defaults to 64-bit) For compiling 32-bit binaries one has to: 'configure --host=ia64n-hp-hpux11' If Debian folks still have the hppa/linux infrastructure we can later reopen the case if something pops up. > Integrate Debian patches > > > Key: DAEMON-289 > URL: https://issues.apache.org/jira/browse/DAEMON-289 > Project: Commons Daemon > Issue Type: Improvement >Affects Versions: 1.0.14 >Reporter: Emmanuel Bourg > Fix For: 1.0.15 > > > Debian maintains several patches to support more architectures. That would be > great to merge them. > http://anonscm.debian.org/viewvc/pkg-java/trunk/commons-daemon/debian/patches/ -- 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-917) More distance measurements are needed in o.a.c.m.stat.clustering.
[ https://issues.apache.org/jira/browse/MATH-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614988#comment-13614988 ] Thomas Neidhart commented on MATH-917: -- In the latest patch, I forgot to provide constructors with a DistanceMeasure, so this would need to be added. > More distance measurements are needed in o.a.c.m.stat.clustering. > - > > Key: MATH-917 > URL: https://issues.apache.org/jira/browse/MATH-917 > Project: Commons Math > Issue Type: Improvement >Reporter: Reid Hochstedler > Fix For: 4.0 > > Attachments: clustering_v2.zip, clustering.zip > > > Currently only Euclidean distance is used for distance measurement, it would > be easy to quickly add Manhattan and Chebyshev distance among others. -- 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
