[jira] [Updated] (FUNCTOR-26) functors filtering on bean properties using(== ,!=, >,>=.>.>=. isNull, Like,..... )
[
https://issues.apache.org/jira/browse/FUNCTOR-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent Worden updated FUNCTOR-26:
Assignee: (was: Brent Worden)
> functors filtering on bean properties using(== ,!=, >,>=.>.>=. isNull,
> Like,. )
> -
>
> Key: FUNCTOR-26
> URL: https://issues.apache.org/jira/browse/FUNCTOR-26
> Project: Commons Functor
> Issue Type: Improvement
>Reporter: Anil K.Kinge
>Priority: Major
> Attachments: functors.propertypredicates.new.diff
>
>
> In my current project I created a set of new Predicates that I call as
> Property Predicates. These predicates can used to filter a collection based
> on property values.
> For example we have :
> Class Foo{
> String name;
> Int age;
> Address address;
> }
> Address{
> String street;
> String zip;
> }
> Collection myFoos ;
> And we want to find all the Foo in myFoos with name that starts with A, and
> age > 40 and who are living at Zip 07095 we can create a Predicate like
> follows:
> Predicate p = new PropertyLikePredicate("name","A*")
> .andGreaterThan("age",40)
> .andEquals(address.zip,"07095");
> Note: Like supports wildcards '*' and '?'
> What is even better is that these predicates work with collections too. What
> I mean is if we have :
> FooBar{
> String name;
> Collection addresses;
> }
> And you want to locate someone with a zip 07095 as part of anyof its'
> addresses all we need is to create a predicate :
> Predicate p = new PropertyEqualsPredicate("addresses[].zip","07095");
> My Predicate chain currently supports the following features:
> 1.andEquals
> 2.orEquals
> 3.andNotEquals
> 4.orNotEquals
> 5.andLike
> 6.orLike
> 7.andGreatorThan
> 8.orGreatorThan
> 9.andGreatorThanOrEquals
> 10. orGreatorThanOrEquals
> 11. andLessThan
> 12. orLessThan
> 13. andLessThanOrEquals
> 14. orLessThanOrEquals
> 15. isNull
> 16. isNotNull
> 17. orNull
> 18. orNotNull
> 19. orNullOrEmpty
> 20. orNotNullOrEmpty
> 21. andNullOrEmpty
> 22. andNotNullOrEmpty
> All features have accompanying testcases. In my opinion this is a powerful
> addition to the functors and I would like to contribute this work to the
> commons-collection.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (RNG-15) Bad grammer in RandomSource.State type javadoc comment
Brent Worden created RNG-15:
---
Summary: Bad grammer in RandomSource.State type javadoc comment
Key: RNG-15
URL: https://issues.apache.org/jira/browse/RNG-15
Project: Commons RNG
Issue Type: Bug
Affects Versions: 1.0
Reporter: Brent Worden
Priority: Trivial
The following sentence needs to be corrected:
{quote}
External code *should not to modify* the data contained in instances of this
class.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1373) In LogNormalDistribution.java, it appears shape & scale are reversed/mis-labelled.
[
https://issues.apache.org/jira/browse/MATH-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15338359#comment-15338359
]
Brent Worden commented on MATH-1373:
I am not completely convinced this change is correct.
Referencing on of the citations,
http://mathworld.wolfram.com/LogNormalDistribution.html, the density function
is parameterized the same way LogNormalDistribution is parameterized with
* MathWorld's M being equivalent to Commons Math's scale
* MathWorld's S being equivalent to Commons Math's shape
The distribution mean according to MathWorld is Exp(M + S^2 / 2) which
corresponds to Exp(scale + shape^2 / 2) and is how it is coded in
LogNormalDistribution.
Likewise, MathWorld states the distribution variance Exp(S^2 + 2 M) * (Exp(S^2
- 1) which is Exp(shape^2 + 2 scale) * (Exp(shape^2 - 1). Again, this matches
the implementation.
Furthermore, generating a large sample from the distribution results in sample
means and variances that are pretty close to the expected values returned from
the getNumericalMean and getNumericalVariance methods. Here is the code I am
using to make that claim:
{code}
@Test
public void testMeanAndVariance() {
LogNormalDistribution dist = new LogNormalDistribution(5.375, 1.125);
double[] x = new double[10];
for (int i = 0; i < x.length; ++i) {
x[i] = dist.inverseCumulativeProbability(Math.random());
}
double actualMean = new Mean().evaluate(x);
double actualVariance = new Variance().evaluate(x);
double expectedMean = dist.getNumericalMean();
double expectedVariance = dist.getNumericalVariance();
System.out.println(String.format("Mean: %f vs %f (actual vs expected)",
actualMean, expectedMean));
System.out.println(String.format("Variance: %f vs %f (actual vs
expected)", actualVariance, expectedVariance));
}
{code}
> In LogNormalDistribution.java, it appears shape & scale are
> reversed/mis-labelled.
> --
>
> Key: MATH-1373
> URL: https://issues.apache.org/jira/browse/MATH-1373
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Karl D. Gierach
>Priority: Minor
> Attachments: MATH-1373.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When I compute the logshape and log scale based on the formulas on
> wikipedia's lognormal distribution page that use empirical mean and variance,
> I found that the getNumericalMean() method was not returning the empirical
> mean.
> However, upon just trying to reverse the shape and scale parameters in the
> constructor proved to fix the problem, and the object then returns the
> correct empirical mean.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MATH-1373) In LogNormalDistribution.java, it appears shape & scale are reversed/mis-labelled.
[
https://issues.apache.org/jira/browse/MATH-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15338359#comment-15338359
]
Brent Worden edited comment on MATH-1373 at 6/19/16 4:22 AM:
-
I am not completely convinced this change is correct.
Referencing on of the citations,
http://mathworld.wolfram.com/LogNormalDistribution.html, the density function
is parameterized the same way LogNormalDistribution is parameterized with
* MathWorld's M being equivalent to Commons Math's scale
* MathWorld's S being equivalent to Commons Math's shape
The distribution mean according to MathWorld is Exp(M + S^2 / 2) which
corresponds to Exp(scale + shape^2 / 2) and is how it is coded in
LogNormalDistribution.
Likewise, MathWorld states the distribution variance Exp(S^2 + 2 M) * (Exp(S^2
- 1) which is Exp(shape^2 + 2 scale) * (Exp(shape^2 - 1). Again, this matches
the implementation.
Furthermore, generating a large sample from the distribution results in sample
means and variances that are pretty close to the population values returned
from the getNumericalMean and getNumericalVariance methods. Here is the code I
am using to make that claim:
{code}
@Test
public void testMeanAndVariance() {
LogNormalDistribution dist = new LogNormalDistribution(5.375, 1.125);
double[] x = new double[10];
for (int i = 0; i < x.length; ++i) {
x[i] = dist.inverseCumulativeProbability(Math.random());
}
double actualMean = new Mean().evaluate(x);
double actualVariance = new Variance().evaluate(x);
double expectedMean = dist.getNumericalMean();
double expectedVariance = dist.getNumericalVariance();
System.out.println(String.format("Mean: %f vs %f (actual vs expected)",
actualMean, expectedMean));
System.out.println(String.format("Variance: %f vs %f (actual vs
expected)", actualVariance, expectedVariance));
}
{code}
was (Author: brentworden):
I am not completely convinced this change is correct.
Referencing on of the citations,
http://mathworld.wolfram.com/LogNormalDistribution.html, the density function
is parameterized the same way LogNormalDistribution is parameterized with
* MathWorld's M being equivalent to Commons Math's scale
* MathWorld's S being equivalent to Commons Math's shape
The distribution mean according to MathWorld is Exp(M + S^2 / 2) which
corresponds to Exp(scale + shape^2 / 2) and is how it is coded in
LogNormalDistribution.
Likewise, MathWorld states the distribution variance Exp(S^2 + 2 M) * (Exp(S^2
- 1) which is Exp(shape^2 + 2 scale) * (Exp(shape^2 - 1). Again, this matches
the implementation.
Furthermore, generating a large sample from the distribution results in sample
means and variances that are pretty close to the expected values returned from
the getNumericalMean and getNumericalVariance methods. Here is the code I am
using to make that claim:
{code}
@Test
public void testMeanAndVariance() {
LogNormalDistribution dist = new LogNormalDistribution(5.375, 1.125);
double[] x = new double[10];
for (int i = 0; i < x.length; ++i) {
x[i] = dist.inverseCumulativeProbability(Math.random());
}
double actualMean = new Mean().evaluate(x);
double actualVariance = new Variance().evaluate(x);
double expectedMean = dist.getNumericalMean();
double expectedVariance = dist.getNumericalVariance();
System.out.println(String.format("Mean: %f vs %f (actual vs expected)",
actualMean, expectedMean));
System.out.println(String.format("Variance: %f vs %f (actual vs
expected)", actualVariance, expectedVariance));
}
{code}
> In LogNormalDistribution.java, it appears shape & scale are
> reversed/mis-labelled.
> --
>
> Key: MATH-1373
> URL: https://issues.apache.org/jira/browse/MATH-1373
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Karl D. Gierach
>Priority: Minor
> Attachments: MATH-1373.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When I compute the logshape and log scale based on the formulas on
> wikipedia's lognormal distribution page that use empirical mean and variance,
> I found that the getNumericalMean() method was not returning the empirical
> mean.
> However, upon just trying to reverse the shape and scale parameters in the
> constructor proved to fix the problem, and the object then returns the
> correct empirical mean.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1191) Incorrect javadoc
[
https://issues.apache.org/jira/browse/LANG-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15116657#comment-15116657
]
Brent Worden commented on LANG-1191:
There does appear to be an inconsistency with:
StringUtils.containsAny("abcd", "ab", null) = false
This does assert to true when added as a test case.
> Incorrect javadoc
> -
>
> Key: LANG-1191
> URL: https://issues.apache.org/jira/browse/LANG-1191
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.4
>Reporter: qed
>Priority: Minor
>
> Javadoc for boolean
> org.apache.commons.lang3.StringUtils.containsAny(CharSequence cs,
> CharSequence... searchCharSequences) says:
> StringUtils.containsAny("abcd", "ab", "cd") = false
> which is not true. It should be:
> StringUtils.containsAny("abcd", "ab", "cd") = true
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1191) Incorrect javadoc
[
https://issues.apache.org/jira/browse/LANG-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent Worden updated LANG-1191:
---
Attachment: LANG-1191.diff
> Incorrect javadoc
> -
>
> Key: LANG-1191
> URL: https://issues.apache.org/jira/browse/LANG-1191
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.4
>Reporter: qed
>Priority: Minor
> Attachments: LANG-1191.diff
>
>
> Javadoc for boolean
> org.apache.commons.lang3.StringUtils.containsAny(CharSequence cs,
> CharSequence... searchCharSequences) says:
> StringUtils.containsAny("abcd", "ab", "cd") = false
> which is not true. It should be:
> StringUtils.containsAny("abcd", "ab", "cd") = true
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CSV-149) Line number is not proper at EOF
[ https://issues.apache.org/jira/browse/CSV-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated CSV-149: - Attachment: csv-145-unit-test.diff unit test > Line number is not proper at EOF > > > Key: CSV-149 > URL: https://issues.apache.org/jira/browse/CSV-149 > Project: Commons CSV > Issue Type: Bug > Components: Parser >Affects Versions: 1.1 > Environment: CSV 1.1, Java 1.6, Windows OS >Reporter: Kranthi > Fix For: Patch Needed > > Attachments: csv-145-unit-test.diff > > > CSVParser.getCurrentLineNumber() is returning wrong line number (actual line > number - 1) when EOF file is reached without record delimiter (\r\n). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CHAIN-106) JavaDoc report contains JavaDocs of cookbook examples
[ https://issues.apache.org/jira/browse/CHAIN-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15114018#comment-15114018 ] Brent Worden commented on CHAIN-106: This appears to have been addressed. The latest JavaDocs report do not contain the the cookbook packages. http://commons.apache.org/proper/commons-chain/apidocs/index.html > JavaDoc report contains JavaDocs of cookbook examples > - > > Key: CHAIN-106 > URL: https://issues.apache.org/jira/browse/CHAIN-106 > Project: Commons Chain > Issue Type: Sub-task > Components: Build >Affects Versions: 2.0 >Reporter: Benedikt Ritter > Labels: site > Fix For: 2.0 > > > The cookbook examples are not really part of the API, there is no reason to > include the JavaDoc of the cookbook in the JavaDoc report of the main site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CSV-124) Improve toString() implementation of CSVRecord
[ https://issues.apache.org/jira/browse/CSV-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated CSV-124: - Fix Version/s: (was: Patch Needed) Improve toString() implementation of CSVRecord -- Key: CSV-124 URL: https://issues.apache.org/jira/browse/CSV-124 Project: Commons CSV Issue Type: Improvement Reporter: Benedikt Ritter Assignee: Brent Worden Fix For: 1.x Attachments: patch_CSV-124.diff Currently we only print out the values using Arrays.toString(). The comment, record number and header are missing from the output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CSV-124) Improve toString() implementation of CSVRecord
[ https://issues.apache.org/jira/browse/CSV-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved CSV-124. -- Resolution: Fixed Fix Version/s: (was: 1.x) 1.1 Improve toString() implementation of CSVRecord -- Key: CSV-124 URL: https://issues.apache.org/jira/browse/CSV-124 Project: Commons CSV Issue Type: Improvement Reporter: Benedikt Ritter Assignee: Brent Worden Fix For: 1.1 Attachments: patch_CSV-124.diff Currently we only print out the values using Arrays.toString(). The comment, record number and header are missing from the output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-512) equals/hashCode mismatch
[ https://issues.apache.org/jira/browse/COLLECTIONS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14044595#comment-14044595 ] Brent Worden commented on COLLECTIONS-512: -- [~tn] Can this be marked as resolved? equals/hashCode mismatch Key: COLLECTIONS-512 URL: https://issues.apache.org/jira/browse/COLLECTIONS-512 Project: Commons Collections Issue Type: Bug Components: Collection, Comparator Affects Versions: 4.0 Environment: Mac OS 10.9, Java 6 and Java 7 Reporter: Cyrille Artho Attachments: BugReport1.java, BugReport1_1.java We used Randoop on the collection classes, which found several test cases where two objects are equal but their hash code differs. I will attach a file containing two test cases that are different; the other tests seem to be longer versions showing the same issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COLLECTIONS-511) CollectionUtils.bisect(...), this would be a combination of Select and SelectRejected
[
https://issues.apache.org/jira/browse/COLLECTIONS-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent Worden updated COLLECTIONS-511:
-
Attachment: collections-511-proposal.diff
collections-511-proposal.diff contains a proposed API for partitioning a
collection using one or more predicates.
Thoughts?
CollectionUtils.bisect(...), this would be a combination of Select and
SelectRejected
-
Key: COLLECTIONS-511
URL: https://issues.apache.org/jira/browse/COLLECTIONS-511
Project: Commons Collections
Issue Type: New Feature
Components: Collection
Reporter: Nathan Blomquist
Priority: Trivial
Attachments: collections-511-proposal.diff
I recently needed a way to use a Predicate to select things from a list, but
I also wanted to know which ones failed the predicate test.
I wanted the following, but with one iteration instead of two:
{code}
List originalList = (...)
Predicate p = (...)
Collection selected = CollectionUtils.select(originalList, p);
Collection rejected = CollectionUtils.selectRejected(originalList, p);
// handle the selected cases (save them or whatnot)
// now throw an error message or handle the rejected cases
{code}
This is what I came up with based on the CollectionUtils.select(...) method:
{code:java}
public static O, R extends Collection? super O void bisect(
final Iterable? extends O inputCollection,
final Predicate? super O predicate,
final R selectedCollection,
final R rejectedCollection) {
if (inputCollection != null predicate != null) {
for (final O item : inputCollection) {
if (predicate.evaluate(item)) {
selectedCollection.add(item);
}else{
rejectedCollection.add(item);
}
}
}
}
public static void main(String[] args){
// this will test the bisection code
ListString original = Arrays.asList(
testString1,
testString2,
testString3,
String1,
String2,
String3,
testString4,
String4,
testString5
);
ListString selected = new ArrayListString();
ListString rejected = new ArrayListString();
PredicateString beginsWithTestPredicate =
new PredicateString() {
public boolean evaluate(String object) {
return object.startsWith(test);
}
};
bisect(original, beginsWithTestPredicate, selected, rejected);
System.out.println(Size of selected (should be 5):
+ selected.size());
System.out.println(Size of rejected (should be 4):
+ rejected.size());
}
{code}
This will of course throw a NullPointerException if either output collection
is null. This seems appropriate since we need to return two outputs anyway.
Not sure if *bisect* is the best name, but this method will split the
original into two pieces. https://www.google.com/#q=define+bisect
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (COLLECTIONS-532) MapUtils.predicatedMap(map, keypredicate,valuepredicate) is not working as expected
[
https://issues.apache.org/jira/browse/COLLECTIONS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent Worden updated COLLECTIONS-532:
-
Description:
I expected that MapUtils.predicatedMap() includes those entries of the
specified map that match the specified key-predicate and specified
value-predicate.I expected that entries that do not match either of the
predicates not included i the returned map.
But in as per the code of org.apache.commons.collections4.map. {code}
PredicatedMap.validate()
protected void validate(final K key, final V value) {
if (keyPredicate != null keyPredicate.evaluate(key) == false) {
throw new IllegalArgumentException(Cannot add key - Predicate
rejected it);
}
if (valuePredicate != null valuePredicate.evaluate(value) == false) {
throw new IllegalArgumentException(Cannot add value - Predicate
rejected it);
}
}
{code}
if evaluation of key or value predicate fails an IllegalArgumentException is
thrown.
Predicates are passed to input map to test if an entry is to be included or
not. If the evaluation of this predicate itself throws an exception based on
result of predicate, then this method is useless and cannot be used to filter
entries of a map(using predicates)
was:
I expected that MapUtils.predicatedMap() includes those entries of the
specified map that match the specified key-predicate and specified
value-predicate.I expected that entries that do not match either of the
predicates not included i the returned map.
But in as per the code of org.apache.commons.collections4.map.
PredicatedMap.validate()
protected void validate(final K key, final V value) {
if (keyPredicate != null keyPredicate.evaluate(key) == false) {
throw new IllegalArgumentException(Cannot add key - Predicate
rejected it);
}
if (valuePredicate != null valuePredicate.evaluate(value) == false) {
throw new IllegalArgumentException(Cannot add value - Predicate
rejected it);
}
}
if evaluation of key or value predicate fails an IllegalArgumentException is
thrown.
Predicates are passed to input map to test if an entry is to be included or
not. If the evaluation of this predicate itself throws an exception based on
result of predicate, then this method is useless and cannot be used to filter
entries of a map(using predicates)
MapUtils.predicatedMap(map, keypredicate,valuepredicate) is not working as
expected
---
Key: COLLECTIONS-532
URL: https://issues.apache.org/jira/browse/COLLECTIONS-532
Project: Commons Collections
Issue Type: New Feature
Components: Collection, Map
Affects Versions: 4.0
Environment: ubuntu/java8
Reporter: Bhanupavansingh
I expected that MapUtils.predicatedMap() includes those entries of the
specified map that match the specified key-predicate and specified
value-predicate.I expected that entries that do not match either of the
predicates not included i the returned map.
But in as per the code of org.apache.commons.collections4.map. {code}
PredicatedMap.validate()
protected void validate(final K key, final V value) {
if (keyPredicate != null keyPredicate.evaluate(key) == false) {
throw new IllegalArgumentException(Cannot add key - Predicate
rejected it);
}
if (valuePredicate != null valuePredicate.evaluate(value) ==
false) {
throw new IllegalArgumentException(Cannot add value - Predicate
rejected it);
}
}
{code}
if evaluation of key or value predicate fails an IllegalArgumentException is
thrown.
Predicates are passed to input map to test if an entry is to be included or
not. If the evaluation of this predicate itself throws an exception based on
result of predicate, then this method is useless and cannot be used to filter
entries of a map(using predicates)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (COLLECTIONS-532) MapUtils.predicatedMap(map, keypredicate,valuepredicate) is not working as expected
[
https://issues.apache.org/jira/browse/COLLECTIONS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent Worden resolved COLLECTIONS-532.
--
Resolution: Won't Fix
Throwing exceptions has been the behavior of all predicated collections since
the beginning.
MapUtils.predicatedMap(map, keypredicate,valuepredicate) is not working as
expected
---
Key: COLLECTIONS-532
URL: https://issues.apache.org/jira/browse/COLLECTIONS-532
Project: Commons Collections
Issue Type: New Feature
Components: Collection, Map
Affects Versions: 4.0
Environment: ubuntu/java8
Reporter: Bhanupavansingh
I expected that MapUtils.predicatedMap() includes those entries of the
specified map that match the specified key-predicate and specified
value-predicate.I expected that entries that do not match either of the
predicates not included i the returned map.
But in as per the code of org.apache.commons.collections4.map. {code}
PredicatedMap.validate()
protected void validate(final K key, final V value) {
if (keyPredicate != null keyPredicate.evaluate(key) == false) {
throw new IllegalArgumentException(Cannot add key - Predicate
rejected it);
}
if (valuePredicate != null valuePredicate.evaluate(value) ==
false) {
throw new IllegalArgumentException(Cannot add value - Predicate
rejected it);
}
}
{code}
if evaluation of key or value predicate fails an IllegalArgumentException is
thrown.
Predicates are passed to input map to test if an entry is to be included or
not. If the evaluation of this predicate itself throws an exception based on
result of predicate, then this method is useless and cannot be used to filter
entries of a map(using predicates)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IO-395) [IO] Configurable Buffered Size
[ https://issues.apache.org/jira/browse/IO-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated IO-395: Attachment: IO-395-patch.txt Overloaded all IOUtils buffer and toBuffered* methods with a size parameter to specify the desired buffer size. [IO] Configurable Buffered Size --- Key: IO-395 URL: https://issues.apache.org/jira/browse/IO-395 Project: Commons IO Issue Type: Bug Components: Streams/Writers, Utilities Reporter: BELUGA BEHR Assignee: Brent Worden Priority: Trivial Attachments: IO-395-patch.txt Would be great if there was an environmental variable that could be set that would set the size of the IO Utils toBufferedInputStream/Writer for all invocations. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (IO-395) [IO] Configurable Buffered Size
[ https://issues.apache.org/jira/browse/IO-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved IO-395. - Resolution: Implemented Fix Version/s: 2.5 [IO] Configurable Buffered Size --- Key: IO-395 URL: https://issues.apache.org/jira/browse/IO-395 Project: Commons IO Issue Type: Bug Components: Streams/Writers, Utilities Reporter: BELUGA BEHR Assignee: Brent Worden Priority: Trivial Fix For: 2.5 Attachments: IO-395-patch.txt Would be great if there was an environmental variable that could be set that would set the size of the IO Utils toBufferedInputStream/Writer for all invocations. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Moved] (COLLECTIONS-476) Collection wrappers to for unmodifiable / nonnull-safe collections
[
https://issues.apache.org/jira/browse/COLLECTIONS-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent Worden moved LANG-864 to COLLECTIONS-476:
---
Component/s: (was: General)
List
Key: COLLECTIONS-476 (was: LANG-864)
Project: Commons Collections (was: Commons Lang)
Collection wrappers to for unmodifiable / nonnull-safe collections
--
Key: COLLECTIONS-476
URL: https://issues.apache.org/jira/browse/COLLECTIONS-476
Project: Commons Collections
Issue Type: New Feature
Components: List
Reporter: offbynull
Priority: Minor
Would it be possible to add something like this to commons lang? Commons
collection looks like it's pretty much dead, and the only alternative for
this kind of stuff is Google's horribly designed and massively confusing
Guava library.
Below are a couple of quick and dirty (untested) examples of the kind of
wrappers I'm talking about. Note the isLocked/locked methods and the
viewBlacklist method. Using these methods, it's easy for a component
receiving a list/set to identify that it's currently unmodifiable and that
the collection restricts certain values (e.g. null? maybe others?).
{code}
public final class LockableBlacklistableListT implements ListT {
private boolean locked;
private ListT list;
private SetT blacklist;
public LockableBlacklistableList(ListT backingList, T... blacklist) {
if (backingList == null) {
throw new NullPointerException();
}
if (!backingList.isEmpty()) {
throw new IllegalArgumentException();
}
this.blacklist = new HashSet(Arrays.asList(blacklist));
this.list = backingList;
}
public void lock() {
locked = true;
}
public boolean isLocked() {
return locked;
}
public SetT viewBlacklist() {
return Collections.unmodifiableSet(blacklist);
}
@Override
public int size() {
return list.size();
}
@Override
public boolean isEmpty() {
return list.isEmpty();
}
@Override
public boolean contains(Object o) {
return list.contains(o);
}
@Override
public IteratorT iterator() {
final IteratorT it = list.iterator();
return new IteratorT() {
@Override
public boolean hasNext() {
return it.hasNext();
}
@Override
public T next() {
return it.next();
}
@Override
public void remove() {
if (locked) {
throw new IllegalStateException();
}
it.remove();
}
};
}
@Override
public Object[] toArray() {
return list.toArray();
}
@Override
public T T[] toArray(T[] a) {
return list.toArray(a);
}
@Override
public boolean add(T e) {
if (locked) {
throw new IllegalStateException();
}
return list.add(e);
}
@Override
public boolean remove(Object o) {
if (locked) {
throw new IllegalStateException();
}
return list.remove(o);
}
@Override
public boolean containsAll(Collection? c) {
return list.containsAll(c);
}
@Override
public boolean addAll(Collection? extends T c) {
if (locked) {
throw new IllegalStateException();
}
for (T item : c) {
if (blacklist.contains(item)) {
throw new IllegalArgumentException();
}
}
return list.addAll(c);
}
@Override
public boolean addAll(int index, Collection? extends T c) {
if (locked) {
throw new IllegalStateException();
}
for (T item : c) {
if (blacklist.contains(item)) {
throw new IllegalArgumentException();
}
}
return list.addAll(index, c);
}
@Override
public boolean removeAll(Collection? c) {
if (locked) {
throw new IllegalStateException();
}
return list.removeAll(c);
}
@Override
public boolean retainAll(Collection? c) {
if (locked) {
throw new IllegalStateException();
}
return list.retainAll(c);
}
@Override
public void clear() {
if (locked) {
throw new IllegalStateException();
}
list.clear();
}
@Override
public boolean equals(Object o) {
return list.equals(o);
}
@Override
public int
[jira] [Resolved] (LANG-837) ObjectUtils.identityToString does not support StringBuilder or StrBuilder or Appendable
[ https://issues.apache.org/jira/browse/LANG-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved LANG-837. --- Resolution: Implemented Fix Version/s: 3.2 ObjectUtils.identityToString does not support StringBuilder or StrBuilder or Appendable --- Key: LANG-837 URL: https://issues.apache.org/jira/browse/LANG-837 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Sebb Fix For: 3.2 Attachments: LANG-837.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] (LANG-900) New RandomUtils class
[
https://issues.apache.org/jira/browse/LANG-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13684199#comment-13684199
]
Brent Worden commented on LANG-900:
---
How about the ability to supply a user defined Random instance?
{code}
public static byte[] nextBytes(int count) {
return nextBytes(count, RANDOM);
}
public static byte[] nextBytes(int count, Random rng) {
Validate.isTrue(count = 0, Count cannot be negative.);
byte[] result = new byte[count];
rng.nextBytes(result);
return result;
}
{code}
New RandomUtils class
-
Key: LANG-900
URL: https://issues.apache.org/jira/browse/LANG-900
Project: Commons Lang
Issue Type: New Feature
Reporter: Duncan Jones
Priority: Minor
Attachments: RandomUtils.java, RandomUtilsTest.java
Attached is a new {{RandomUtils}} class and associated test, which offers
some methods not available in the standard {{Random}} class:
- a {{nextBytes(int count)}} method that returns a byte array
- versions of {{nextInt}}, {{nextLong}}, {{nextFloat}} and {{nextDouble}}
that return a value within a range.
Comments very welcome!
--
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-851) StringUtils.stripEnd(commons-digester.jar, .jar) returns commons-digeste instead of commons-digester
[ https://issues.apache.org/jira/browse/LANG-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved LANG-851. --- Resolution: Won't Fix Fix Version/s: 3.1 Assignee: Brent Worden This is the documented behavior of the method. The original reporter wants to use the [StringUtils.removeEnd|http://commons.apache.org/lang/api-release/org/apache/commons/lang3/StringUtils.html#removeEnd(java.lang.String, java.lang.String)] method instead. StringUtils.stripEnd(commons-digester.jar, .jar) returns commons-digeste instead of commons-digester Key: LANG-851 URL: https://issues.apache.org/jira/browse/LANG-851 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 3.1 Environment: Windows 7, jdk 1.5_0_22, jdk 1.6.0_32 Reporter: Santh Balak Assignee: Brent Worden Fix For: 3.1 StringUtils.stripEnd(commons-digester.jar, .jar) returns commons-digeste instead of commons-digester. I tried with all the commons lang versions from 2.1 - 3.1 -- 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-815) DurationFormatUtils.formatPeriod() miss-calculation
[ https://issues.apache.org/jira/browse/LANG-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated LANG-815: -- Summary: DurationFormatUtils.formatPeriod() miss-calculation (was: DurationFormatUtils.formatPeriod() miss-calcuration) 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
[jira] [Commented] (COLLECTIONS-165) Filtered Maps, Lists, and Sets
[ https://issues.apache.org/jira/browse/COLLECTIONS-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13442202#comment-13442202 ] Brent Worden commented on COLLECTIONS-165: -- There might be some licensing concerns regarding the patches attached to this issue. The original source seems to have been taken from an academic friendly license that is incompatible with the Apache license. Filtered Maps, Lists, and Sets -- Key: COLLECTIONS-165 URL: https://issues.apache.org/jira/browse/COLLECTIONS-165 Project: Commons Collections Issue Type: New Feature Components: List, Map, Set Affects Versions: 3.1 Environment: Operating System: other Platform: Other Reporter: Venkatesh Prasad Ranganath Priority: Minor Fix For: 4.x Attachments: ASF.LICENSE.NOT.GRANTED--FilteredCollection.java, ASF.LICENSE.NOT.GRANTED--FilteredListIterator.java, ASF.LICENSE.NOT.GRANTED--FilteredList.java, ASF.LICENSE.NOT.GRANTED--FilteredMap.java, ASF.LICENSE.NOT.GRANTED--FilteredSet.java In the project I work I have found that it would be efficient (at a small cost of memory) to use filtered maps, lists, and sets instead of creating a new copy of the decorated entities that contains only the filtered elements. To begin with I have implemented a FilteredMap and plan to implement FilteredList and FilteredSet. I will post the code for these in a couple of days and it would be great if Collections library could accept these contributions. -- 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] (COLLECTIONS-241) [contribution] PassiveTimeOutMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-241. -- Resolution: Implemented Fix Version/s: 4.0 r1376827 [contribution] PassiveTimeOutMap Key: COLLECTIONS-241 URL: https://issues.apache.org/jira/browse/COLLECTIONS-241 Project: Commons Collections Issue Type: New Feature Components: Map Reporter: Elifarley Callado Coelho Assignee: Brent Worden Priority: Minor Fix For: 4.0 Attachments: PassiveTimeOutMap.zip This is a Map decorator which passively evicts expired keys once their expiry time has been reached. When putting a key-value pair in the map, this decorator calls expiryTime(key, value), passing the key and the value as parameters, and uses the returned value as the expiry time for that key. When getting the value for a key, its expiry time is checked, and if it's greater than the current time, the value is returned. Otherwise, the key is removed from the decorated map, and null is returned. Doing so, there's no need to have a separate, active thread (hence the name 'passive') to check expiry times - the check is performed on demand. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-585) Very slow generation of gamma random variates
[ https://issues.apache.org/jira/browse/MATH-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13047223#comment-13047223 ] Brent Worden commented on MATH-585: --- Here is a performance improvement suggestion to the implementation in the patch: Since the loop in calculateQ is always a fixed number of iterations, eliminate it and compute the polynomial directly. Also, instead of computing is as a1*v + a2*v^2 + a3*v^3 + ... a9*v^9 use the equivalent form v*(a1 + v*(a2 + v*(a3 + ... + v*(a8 + a9*v. This method eliminates about half of the multiplications needed to compute the polynomial. Apply the same technique to the loops found in Step 4 (lines 244-250 of MATH585-1.patch) and in Step 11 (lines 307-318). Very slow generation of gamma random variates - Key: MATH-585 URL: https://issues.apache.org/jira/browse/MATH-585 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2, 3.0 Environment: All Reporter: Darren Wilkinson Assignee: Mikkel Meyer Andersen Labels: Gamma, Random Attachments: MATH585-1.patch Original Estimate: 6h Remaining Estimate: 6h The current implementation of gamma random variate generation works, but uses an inversion method. This is well-known to be a bad idea. Usually a carefully constructed rejection procedure is used. To give an idea of the magnitude of the problem, the Gamma variate generation in Parallel COLT is roughly 50 times faster than in Commons Math. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-585) Very slow generation of gamma random variates
[ https://issues.apache.org/jira/browse/MATH-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13047223#comment-13047223 ] Brent Worden edited comment on MATH-585 at 6/10/11 2:43 PM: Here is a performance improvement suggestion to the implementation in the patch. Since the loop in calculateQ is always a fixed number of iterations, eliminate it and compute the polynomial directly. Also, instead of computing is as a1*v + a2*v^2 + a3*v^3 + ... a9*v^9 use the equivalent form v*(a1 + v*(a2 + v*(a3 + ... + v*(a8 + a9*v. This method eliminates about half of the multiplications needed to compute the polynomial. Apply the same technique to the loops found in Step 4 (lines 244-250 of MATH585-1.patch) and in Step 11 (lines 307-318). was (Author: brentworden): Here is a performance improvement suggestion to the implementation in the patch: Since the loop in calculateQ is always a fixed number of iterations, eliminate it and compute the polynomial directly. Also, instead of computing is as a1*v + a2*v^2 + a3*v^3 + ... a9*v^9 use the equivalent form v*(a1 + v*(a2 + v*(a3 + ... + v*(a8 + a9*v. This method eliminates about half of the multiplications needed to compute the polynomial. Apply the same technique to the loops found in Step 4 (lines 244-250 of MATH585-1.patch) and in Step 11 (lines 307-318). Very slow generation of gamma random variates - Key: MATH-585 URL: https://issues.apache.org/jira/browse/MATH-585 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2, 3.0 Environment: All Reporter: Darren Wilkinson Assignee: Mikkel Meyer Andersen Labels: Gamma, Random Attachments: MATH585-1.patch Original Estimate: 6h Remaining Estimate: 6h The current implementation of gamma random variate generation works, but uses an inversion method. This is well-known to be a bad idea. Usually a carefully constructed rejection procedure is used. To give an idea of the magnitude of the problem, the Gamma variate generation in Parallel COLT is roughly 50 times faster than in Commons Math. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COLLECTIONS-213) CollectionUtils API extension: algorithm methods accept an Iterator argument
[ https://issues.apache.org/jira/browse/COLLECTIONS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-213. -- Resolution: Fixed r1127604. Added multiple use support to IteratorIterable. CollectionUtils API extension: algorithm methods accept an Iterator argument Key: COLLECTIONS-213 URL: https://issues.apache.org/jira/browse/COLLECTIONS-213 Project: Commons Collections Issue Type: Improvement Components: Core Reporter: Dusan Chromy Assignee: Brent Worden Fix For: 4.x Attachments: COLLECTIONS-213.patch, CollectionUtils.java, TestCollectionUtils.java, collections-4.0-213.diff I just finished the Iterator additions to CollectionUtils, including test cases and I am going to attach them to this issue very shortly (basically as soon as I figure out how attaching in JIRA works :) At first I was thinking for a while whether CollectionUtils is a good place to accomodate the methods with the new signature, until I noticed the collect method already accepts an Iterator argument. Following methods now accept an Iterator argument (besides collect): cardinality find forAllDo countMatches exists I also noticed cardinality used to throw a NPE if the collection argument was null. I see no reason why it should not return zero. The Iterator flavour does return zero and I also modified the Collection version to return zero (including Javadoc modification) for the sake of consistence. I stopped to think for a while before touching the method, but the fact that the Javadoc does not mention may not be null made me think the NPE is not thrown intentionally. And after all, cardinality(..) is nothing else than specialized countMatches(..), which returns 0 for null collection. However, feel free to reject the change to the cardinality(Object,Collection) method if you think otherwise. I worked on a fresh checkout from subversion and I just updated few minutes ago to make sure I have modified the latest version. Anyway, please double-check before commiting the changes. Cheers, Dusan I think that these methods would make useful additions to the API. I don't have the time to do much collections work these days, but if you want to code the methods with test cases and attach them to JIRA then that would be great. Stephen dusan.chr...@freenet.de wrote: I've been using some algorithm methods from the CollectionUtils, for example find(Collection, Predicate) exists(Collection, Predicate) countMatches(Collection, Predicate) forAllDo(Collection, Closure) However, I would also like to be able to use these algorithms with an Iterator: find(Iterator, Predicate) exists(Iterator, Predicate) countMatches(Iterator, Predicate) forAllDo(Iterator, Closure) The obvious workaround is to use IteratorUtils.toList(Iterator), however this comes at the cost of constructing a list object (an ArrayList presumably) which could be avoided, as the Iterator itself is sufficient for the above algorithms to work. What do you think? Is there any reason not to provide the algorithms for an Iterator? I personally think that the algorithms should have been there for Iterators in the first place, because every collection is Iterable (or has an Iterator, prior to JDK 5.0). If noone is interested or has time to implement these changes, I can also contribute to the project - but at the moment I just wanted to discuss the idea / check if this has been already considered or planned. Best Regards, Dusan Chromy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-213) CollectionUtils API extension: algorithm methods accept an Iterator argument
[ https://issues.apache.org/jira/browse/COLLECTIONS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13039254#comment-13039254 ] Brent Worden commented on COLLECTIONS-213: -- IteratorIterable now supports multiple use implicitly through ResettableIterator instances as well as by wrapping non-resettable iterators in ListIteratorWrapper. CollectionUtils API extension: algorithm methods accept an Iterator argument Key: COLLECTIONS-213 URL: https://issues.apache.org/jira/browse/COLLECTIONS-213 Project: Commons Collections Issue Type: Improvement Components: Core Reporter: Dusan Chromy Assignee: Brent Worden Fix For: 4.x Attachments: COLLECTIONS-213.patch, CollectionUtils.java, TestCollectionUtils.java, collections-4.0-213.diff I just finished the Iterator additions to CollectionUtils, including test cases and I am going to attach them to this issue very shortly (basically as soon as I figure out how attaching in JIRA works :) At first I was thinking for a while whether CollectionUtils is a good place to accomodate the methods with the new signature, until I noticed the collect method already accepts an Iterator argument. Following methods now accept an Iterator argument (besides collect): cardinality find forAllDo countMatches exists I also noticed cardinality used to throw a NPE if the collection argument was null. I see no reason why it should not return zero. The Iterator flavour does return zero and I also modified the Collection version to return zero (including Javadoc modification) for the sake of consistence. I stopped to think for a while before touching the method, but the fact that the Javadoc does not mention may not be null made me think the NPE is not thrown intentionally. And after all, cardinality(..) is nothing else than specialized countMatches(..), which returns 0 for null collection. However, feel free to reject the change to the cardinality(Object,Collection) method if you think otherwise. I worked on a fresh checkout from subversion and I just updated few minutes ago to make sure I have modified the latest version. Anyway, please double-check before commiting the changes. Cheers, Dusan I think that these methods would make useful additions to the API. I don't have the time to do much collections work these days, but if you want to code the methods with test cases and attach them to JIRA then that would be great. Stephen dusan.chr...@freenet.de wrote: I've been using some algorithm methods from the CollectionUtils, for example find(Collection, Predicate) exists(Collection, Predicate) countMatches(Collection, Predicate) forAllDo(Collection, Closure) However, I would also like to be able to use these algorithms with an Iterator: find(Iterator, Predicate) exists(Iterator, Predicate) countMatches(Iterator, Predicate) forAllDo(Iterator, Closure) The obvious workaround is to use IteratorUtils.toList(Iterator), however this comes at the cost of constructing a list object (an ArrayList presumably) which could be avoided, as the Iterator itself is sufficient for the above algorithms to work. What do you think? Is there any reason not to provide the algorithms for an Iterator? I personally think that the algorithms should have been there for Iterators in the first place, because every collection is Iterable (or has an Iterator, prior to JDK 5.0). If noone is interested or has time to implement these changes, I can also contribute to the project - but at the moment I just wanted to discuss the idea / check if this has been already considered or planned. Best Regards, Dusan Chromy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-213) CollectionUtils API extension: algorithm methods accept an Iterator argument
[ https://issues.apache.org/jira/browse/COLLECTIONS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated COLLECTIONS-213: - Fix Version/s: (was: 4.x) 4.0 CollectionUtils API extension: algorithm methods accept an Iterator argument Key: COLLECTIONS-213 URL: https://issues.apache.org/jira/browse/COLLECTIONS-213 Project: Commons Collections Issue Type: Improvement Components: Core Reporter: Dusan Chromy Assignee: Brent Worden Fix For: 4.0 Attachments: COLLECTIONS-213.patch, CollectionUtils.java, TestCollectionUtils.java, collections-4.0-213.diff I just finished the Iterator additions to CollectionUtils, including test cases and I am going to attach them to this issue very shortly (basically as soon as I figure out how attaching in JIRA works :) At first I was thinking for a while whether CollectionUtils is a good place to accomodate the methods with the new signature, until I noticed the collect method already accepts an Iterator argument. Following methods now accept an Iterator argument (besides collect): cardinality find forAllDo countMatches exists I also noticed cardinality used to throw a NPE if the collection argument was null. I see no reason why it should not return zero. The Iterator flavour does return zero and I also modified the Collection version to return zero (including Javadoc modification) for the sake of consistence. I stopped to think for a while before touching the method, but the fact that the Javadoc does not mention may not be null made me think the NPE is not thrown intentionally. And after all, cardinality(..) is nothing else than specialized countMatches(..), which returns 0 for null collection. However, feel free to reject the change to the cardinality(Object,Collection) method if you think otherwise. I worked on a fresh checkout from subversion and I just updated few minutes ago to make sure I have modified the latest version. Anyway, please double-check before commiting the changes. Cheers, Dusan I think that these methods would make useful additions to the API. I don't have the time to do much collections work these days, but if you want to code the methods with test cases and attach them to JIRA then that would be great. Stephen dusan.chr...@freenet.de wrote: I've been using some algorithm methods from the CollectionUtils, for example find(Collection, Predicate) exists(Collection, Predicate) countMatches(Collection, Predicate) forAllDo(Collection, Closure) However, I would also like to be able to use these algorithms with an Iterator: find(Iterator, Predicate) exists(Iterator, Predicate) countMatches(Iterator, Predicate) forAllDo(Iterator, Closure) The obvious workaround is to use IteratorUtils.toList(Iterator), however this comes at the cost of constructing a list object (an ArrayList presumably) which could be avoided, as the Iterator itself is sufficient for the above algorithms to work. What do you think? Is there any reason not to provide the algorithms for an Iterator? I personally think that the algorithms should have been there for Iterators in the first place, because every collection is Iterable (or has an Iterator, prior to JDK 5.0). If noone is interested or has time to implement these changes, I can also contribute to the project - but at the moment I just wanted to discuss the idea / check if this has been already considered or planned. Best Regards, Dusan Chromy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COLLECTIONS-306) Use Predicate in subtract
[ https://issues.apache.org/jira/browse/COLLECTIONS-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-306. -- Resolution: Fixed Fix Version/s: 4.0 r1127124 and r1127125. Added predicated subtract method to CollectionUtils. Use Predicate in subtract - Key: COLLECTIONS-306 URL: https://issues.apache.org/jira/browse/COLLECTIONS-306 Project: Commons Collections Issue Type: New Feature Components: Collection Environment: all OSs Reporter: Chris Shayan Fix For: 4.0 Original Estimate: 0.75h Remaining Estimate: 0.75h It is good idea to use Predicate in subtract method, I've developed myself the mentioned method and now I am testing it. I mean we should have following methods: The one already exist is: public static Collection subtract(Collection a, Collection b) I offer to have one more which is: public static Collection subtract(Collection a, Collection b, Predicate predicate) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COLLECTIONS-313) Allow Closure and CollectionUtils.forAllDo to throw Exception
[ https://issues.apache.org/jira/browse/COLLECTIONS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-313. -- Resolution: Fixed Fix Version/s: 4.0 r1127199. Added abstract closure that is capable of handling thrown exceptions from closure execution. Allow Closure and CollectionUtils.forAllDo to throw Exception - Key: COLLECTIONS-313 URL: https://issues.apache.org/jira/browse/COLLECTIONS-313 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: 3.2 Reporter: David J. M. Karlsen Assignee: Brent Worden Fix For: 4.0 Attachments: collections-313.txt Original Estimate: 0h Remaining Estimate: 0h It would be nice if Closure.execute and CollectionUtils.forAllDo would be allowed to throw Exceptions as the work inside of the Closure might very well throw exceptions -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-213) CollectionUtils API extension: algorithm methods accept an Iterator argument
[ https://issues.apache.org/jira/browse/COLLECTIONS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038361#comment-13038361 ] Brent Worden commented on COLLECTIONS-213: -- r1126836. Added IteratorIterable adaptor type. CollectionUtils API extension: algorithm methods accept an Iterator argument Key: COLLECTIONS-213 URL: https://issues.apache.org/jira/browse/COLLECTIONS-213 Project: Commons Collections Issue Type: Improvement Components: Core Reporter: Dusan Chromy Assignee: Brent Worden Fix For: 4.x Attachments: COLLECTIONS-213.patch, CollectionUtils.java, TestCollectionUtils.java, collections-4.0-213.diff I just finished the Iterator additions to CollectionUtils, including test cases and I am going to attach them to this issue very shortly (basically as soon as I figure out how attaching in JIRA works :) At first I was thinking for a while whether CollectionUtils is a good place to accomodate the methods with the new signature, until I noticed the collect method already accepts an Iterator argument. Following methods now accept an Iterator argument (besides collect): cardinality find forAllDo countMatches exists I also noticed cardinality used to throw a NPE if the collection argument was null. I see no reason why it should not return zero. The Iterator flavour does return zero and I also modified the Collection version to return zero (including Javadoc modification) for the sake of consistence. I stopped to think for a while before touching the method, but the fact that the Javadoc does not mention may not be null made me think the NPE is not thrown intentionally. And after all, cardinality(..) is nothing else than specialized countMatches(..), which returns 0 for null collection. However, feel free to reject the change to the cardinality(Object,Collection) method if you think otherwise. I worked on a fresh checkout from subversion and I just updated few minutes ago to make sure I have modified the latest version. Anyway, please double-check before commiting the changes. Cheers, Dusan I think that these methods would make useful additions to the API. I don't have the time to do much collections work these days, but if you want to code the methods with test cases and attach them to JIRA then that would be great. Stephen dusan.chr...@freenet.de wrote: I've been using some algorithm methods from the CollectionUtils, for example find(Collection, Predicate) exists(Collection, Predicate) countMatches(Collection, Predicate) forAllDo(Collection, Closure) However, I would also like to be able to use these algorithms with an Iterator: find(Iterator, Predicate) exists(Iterator, Predicate) countMatches(Iterator, Predicate) forAllDo(Iterator, Closure) The obvious workaround is to use IteratorUtils.toList(Iterator), however this comes at the cost of constructing a list object (an ArrayList presumably) which could be avoided, as the Iterator itself is sufficient for the above algorithms to work. What do you think? Is there any reason not to provide the algorithms for an Iterator? I personally think that the algorithms should have been there for Iterators in the first place, because every collection is Iterable (or has an Iterator, prior to JDK 5.0). If noone is interested or has time to implement these changes, I can also contribute to the project - but at the moment I just wanted to discuss the idea / check if this has been already considered or planned. Best Regards, Dusan Chromy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-213) CollectionUtils API extension: algorithm methods accept an Iterator argument
[ https://issues.apache.org/jira/browse/COLLECTIONS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038362#comment-13038362 ] Brent Worden commented on COLLECTIONS-213: -- To address Matt Benson's concern, should the IteratorIterable class be modified to work with resettable iterators or should a separate iterable adaptor class be created? CollectionUtils API extension: algorithm methods accept an Iterator argument Key: COLLECTIONS-213 URL: https://issues.apache.org/jira/browse/COLLECTIONS-213 Project: Commons Collections Issue Type: Improvement Components: Core Reporter: Dusan Chromy Assignee: Brent Worden Fix For: 4.x Attachments: COLLECTIONS-213.patch, CollectionUtils.java, TestCollectionUtils.java, collections-4.0-213.diff I just finished the Iterator additions to CollectionUtils, including test cases and I am going to attach them to this issue very shortly (basically as soon as I figure out how attaching in JIRA works :) At first I was thinking for a while whether CollectionUtils is a good place to accomodate the methods with the new signature, until I noticed the collect method already accepts an Iterator argument. Following methods now accept an Iterator argument (besides collect): cardinality find forAllDo countMatches exists I also noticed cardinality used to throw a NPE if the collection argument was null. I see no reason why it should not return zero. The Iterator flavour does return zero and I also modified the Collection version to return zero (including Javadoc modification) for the sake of consistence. I stopped to think for a while before touching the method, but the fact that the Javadoc does not mention may not be null made me think the NPE is not thrown intentionally. And after all, cardinality(..) is nothing else than specialized countMatches(..), which returns 0 for null collection. However, feel free to reject the change to the cardinality(Object,Collection) method if you think otherwise. I worked on a fresh checkout from subversion and I just updated few minutes ago to make sure I have modified the latest version. Anyway, please double-check before commiting the changes. Cheers, Dusan I think that these methods would make useful additions to the API. I don't have the time to do much collections work these days, but if you want to code the methods with test cases and attach them to JIRA then that would be great. Stephen dusan.chr...@freenet.de wrote: I've been using some algorithm methods from the CollectionUtils, for example find(Collection, Predicate) exists(Collection, Predicate) countMatches(Collection, Predicate) forAllDo(Collection, Closure) However, I would also like to be able to use these algorithms with an Iterator: find(Iterator, Predicate) exists(Iterator, Predicate) countMatches(Iterator, Predicate) forAllDo(Iterator, Closure) The obvious workaround is to use IteratorUtils.toList(Iterator), however this comes at the cost of constructing a list object (an ArrayList presumably) which could be avoided, as the Iterator itself is sufficient for the above algorithms to work. What do you think? Is there any reason not to provide the algorithms for an Iterator? I personally think that the algorithms should have been there for Iterators in the first place, because every collection is Iterable (or has an Iterator, prior to JDK 5.0). If noone is interested or has time to implement these changes, I can also contribute to the project - but at the moment I just wanted to discuss the idea / check if this has been already considered or planned. Best Regards, Dusan Chromy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-313) Allow Closure and CollectionUtils.forAllDo to throw Exception
[ https://issues.apache.org/jira/browse/COLLECTIONS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13038363#comment-13038363 ] Brent Worden commented on COLLECTIONS-313: -- If no one objects, I will commit the patch plus test cases. Allow Closure and CollectionUtils.forAllDo to throw Exception - Key: COLLECTIONS-313 URL: https://issues.apache.org/jira/browse/COLLECTIONS-313 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: 3.2 Reporter: David J. M. Karlsen Assignee: Brent Worden Attachments: collections-313.txt Original Estimate: 0h Remaining Estimate: 0h It would be nice if Closure.execute and CollectionUtils.forAllDo would be allowed to throw Exceptions as the work inside of the Closure might very well throw exceptions -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COLLECTIONS-229) Remove deprecated classes from generics version
[ https://issues.apache.org/jira/browse/COLLECTIONS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-229. -- Resolution: Fixed Fix Version/s: (was: 4.0-beta-1) 4.0 r1125367. patch applied to remove remaining deprecated methods. Remove deprecated classes from generics version --- Key: COLLECTIONS-229 URL: https://issues.apache.org/jira/browse/COLLECTIONS-229 Project: Commons Collections Issue Type: Task Components: Core, Iterator Reporter: Stephen Colebourne Assignee: Brent Worden Fix For: 4.0 Attachments: AbstractBidiMapDecorator.java, AbstractDualBidiMap.java, AbstractOrderedBidiMapDecorator.java, AbstractSortedBidiMapDecorator.java, TestAbstractOrderedBidiMapDecorator.java, UnmodifiableBidiMap.java, UnmodifiableOrderedBidiMap.java, UnmodifiableSortedBidiMap.java, collections-229.diff The generics version should have no deprecations -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COLLECTIONS-344) Delete MapUtils.getXxx
[ https://issues.apache.org/jira/browse/COLLECTIONS-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-344. -- Resolution: Won't Fix Type conversion logic in methods prohibits use of generics to eliminate methods. Delete MapUtils.getXxx -- Key: COLLECTIONS-344 URL: https://issues.apache.org/jira/browse/COLLECTIONS-344 Project: Commons Collections Issue Type: Task Components: Map Reporter: Henri Yandell Assignee: Brent Worden Fix For: 4.0 Seems pointless in a generics based world to have getDouble, getMap and their ilk. Delete em all. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-231) Not return the base interface on decorate
[ https://issues.apache.org/jira/browse/COLLECTIONS-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13036818#comment-13036818 ] Brent Worden commented on COLLECTIONS-231: -- Should the other static decorate methods return the decorator type, as well? Not return the base interface on decorate - Key: COLLECTIONS-231 URL: https://issues.apache.org/jira/browse/COLLECTIONS-231 Project: Commons Collections Issue Type: Improvement Components: Map Affects Versions: 3.2 Reporter: Torsten Curdt Fix For: 4.0-beta-1 At the moment I don't see a reason why the static decorate method does not return ListOrderedMap but just the base interface OrderedMap. I want to decorate a Map to be a ListOrderedMap but due to the fact that the constructor is not visible and decorate only returns the base interface OrderedMap an unnecessary cast is required. ListOrderedMap map = (ListOrderedMap)ListOrderedMap.decorate(new MyMap()); As the decorate method is static and not part of any interface it should be fine to return the real type instead of the base. Otherwise I'd suggest to make the constructor visible. From the API POV It is not really understandable why this ListOrderedMap map = new ListOrderedMap(); is fine and creates a HashMap under the hood while this ListOrderedMap map = new ListOrderedMap(new MyMap())); is not ok. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-305) functors filtering on bean properties using(== ,!=, ,=..=. isNull, Like,..... )
[
https://issues.apache.org/jira/browse/COLLECTIONS-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13036829#comment-13036829
]
Brent Worden commented on COLLECTIONS-305:
--
Is this better suited for commons-beanutils and its collections classes?
functors filtering on bean properties using(== ,!=, ,=..=. isNull,
Like,. )
-
Key: COLLECTIONS-305
URL: https://issues.apache.org/jira/browse/COLLECTIONS-305
Project: Commons Collections
Issue Type: Improvement
Components: Functor
Affects Versions: 3.2
Reporter: Anil K.Kinge
Attachments: functors.propertypredicates.new.diff
In my current project I created a set of new Predicates that I call as
Property Predicates. These predicates can used to filter a collection based
on property values.
For example we have :
Class Foo{
String name;
Int age;
Address address;
}
Address{
String street;
String zip;
}
CollectionFoo myFoos ;
And we want to find all the Foo in myFoos with name that starts with A, and
age 40 and who are living at Zip 07095 we can create a Predicate like
follows:
Predicate p = new PropertyLikePredicate(name,A*)
.andGreaterThan(age,40)
.andEquals(address.zip,07095);
Note: Like supports wildcards '*' and '?'
What is even better is that these predicates work with collections too. What
I mean is if we have :
FooBar{
String name;
CollectionAddress addresses;
}
And you want to locate someone with a zip 07095 as part of anyof its'
addresses all we need is to create a predicate :
Predicate p = new PropertyEqualsPredicate(addresses[].zip,07095);
My Predicate chain currently supports the following features:
1.andEquals
2.orEquals
3.andNotEquals
4.orNotEquals
5.andLike
6.orLike
7.andGreatorThan
8.orGreatorThan
9.andGreatorThanOrEquals
10. orGreatorThanOrEquals
11. andLessThan
12. orLessThan
13. andLessThanOrEquals
14. orLessThanOrEquals
15. isNull
16. isNotNull
17. orNull
18. orNotNull
19. orNullOrEmpty
20. orNotNullOrEmpty
21. andNullOrEmpty
22. andNotNullOrEmpty
All features have accompanying testcases. In my opinion this is a powerful
addition to the functors and I would like to contribute this work to the
commons-collection.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-213) CollectionUtils API extension: algorithm methods accept an Iterator argument
[ https://issues.apache.org/jira/browse/COLLECTIONS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13036857#comment-13036857 ] Brent Worden commented on COLLECTIONS-213: -- +1 on the iterator based method additions. With the rise of big data frameworks, having to operate on iterators directly is becoming more common. For instance Hadoop's reducers work with iterators and not collections or iterables. CollectionUtils API extension: algorithm methods accept an Iterator argument Key: COLLECTIONS-213 URL: https://issues.apache.org/jira/browse/COLLECTIONS-213 Project: Commons Collections Issue Type: Improvement Components: Core Reporter: Dusan Chromy Fix For: 4.x Attachments: COLLECTIONS-213.patch, CollectionUtils.java, TestCollectionUtils.java I just finished the Iterator additions to CollectionUtils, including test cases and I am going to attach them to this issue very shortly (basically as soon as I figure out how attaching in JIRA works :) At first I was thinking for a while whether CollectionUtils is a good place to accomodate the methods with the new signature, until I noticed the collect method already accepts an Iterator argument. Following methods now accept an Iterator argument (besides collect): cardinality find forAllDo countMatches exists I also noticed cardinality used to throw a NPE if the collection argument was null. I see no reason why it should not return zero. The Iterator flavour does return zero and I also modified the Collection version to return zero (including Javadoc modification) for the sake of consistence. I stopped to think for a while before touching the method, but the fact that the Javadoc does not mention may not be null made me think the NPE is not thrown intentionally. And after all, cardinality(..) is nothing else than specialized countMatches(..), which returns 0 for null collection. However, feel free to reject the change to the cardinality(Object,Collection) method if you think otherwise. I worked on a fresh checkout from subversion and I just updated few minutes ago to make sure I have modified the latest version. Anyway, please double-check before commiting the changes. Cheers, Dusan I think that these methods would make useful additions to the API. I don't have the time to do much collections work these days, but if you want to code the methods with test cases and attach them to JIRA then that would be great. Stephen dusan.chr...@freenet.de wrote: I've been using some algorithm methods from the CollectionUtils, for example find(Collection, Predicate) exists(Collection, Predicate) countMatches(Collection, Predicate) forAllDo(Collection, Closure) However, I would also like to be able to use these algorithms with an Iterator: find(Iterator, Predicate) exists(Iterator, Predicate) countMatches(Iterator, Predicate) forAllDo(Iterator, Closure) The obvious workaround is to use IteratorUtils.toList(Iterator), however this comes at the cost of constructing a list object (an ArrayList presumably) which could be avoided, as the Iterator itself is sufficient for the above algorithms to work. What do you think? Is there any reason not to provide the algorithms for an Iterator? I personally think that the algorithms should have been there for Iterators in the first place, because every collection is Iterable (or has an Iterator, prior to JDK 5.0). If noone is interested or has time to implement these changes, I can also contribute to the project - but at the moment I just wanted to discuss the idea / check if this has been already considered or planned. Best Regards, Dusan Chromy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-213) CollectionUtils API extension: algorithm methods accept an Iterator argument
[ https://issues.apache.org/jira/browse/COLLECTIONS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13036909#comment-13036909 ] Brent Worden commented on COLLECTIONS-213: -- Would it make more sense to create an Iterable type that simply wraps an Iterator? That would eliminate the need to maintain additional versions of these methods. CollectionUtils API extension: algorithm methods accept an Iterator argument Key: COLLECTIONS-213 URL: https://issues.apache.org/jira/browse/COLLECTIONS-213 Project: Commons Collections Issue Type: Improvement Components: Core Reporter: Dusan Chromy Assignee: Brent Worden Fix For: 4.x Attachments: COLLECTIONS-213.patch, CollectionUtils.java, TestCollectionUtils.java, collections-4.0-213.diff I just finished the Iterator additions to CollectionUtils, including test cases and I am going to attach them to this issue very shortly (basically as soon as I figure out how attaching in JIRA works :) At first I was thinking for a while whether CollectionUtils is a good place to accomodate the methods with the new signature, until I noticed the collect method already accepts an Iterator argument. Following methods now accept an Iterator argument (besides collect): cardinality find forAllDo countMatches exists I also noticed cardinality used to throw a NPE if the collection argument was null. I see no reason why it should not return zero. The Iterator flavour does return zero and I also modified the Collection version to return zero (including Javadoc modification) for the sake of consistence. I stopped to think for a while before touching the method, but the fact that the Javadoc does not mention may not be null made me think the NPE is not thrown intentionally. And after all, cardinality(..) is nothing else than specialized countMatches(..), which returns 0 for null collection. However, feel free to reject the change to the cardinality(Object,Collection) method if you think otherwise. I worked on a fresh checkout from subversion and I just updated few minutes ago to make sure I have modified the latest version. Anyway, please double-check before commiting the changes. Cheers, Dusan I think that these methods would make useful additions to the API. I don't have the time to do much collections work these days, but if you want to code the methods with test cases and attach them to JIRA then that would be great. Stephen dusan.chr...@freenet.de wrote: I've been using some algorithm methods from the CollectionUtils, for example find(Collection, Predicate) exists(Collection, Predicate) countMatches(Collection, Predicate) forAllDo(Collection, Closure) However, I would also like to be able to use these algorithms with an Iterator: find(Iterator, Predicate) exists(Iterator, Predicate) countMatches(Iterator, Predicate) forAllDo(Iterator, Closure) The obvious workaround is to use IteratorUtils.toList(Iterator), however this comes at the cost of constructing a list object (an ArrayList presumably) which could be avoided, as the Iterator itself is sufficient for the above algorithms to work. What do you think? Is there any reason not to provide the algorithms for an Iterator? I personally think that the algorithms should have been there for Iterators in the first place, because every collection is Iterable (or has an Iterator, prior to JDK 5.0). If noone is interested or has time to implement these changes, I can also contribute to the project - but at the moment I just wanted to discuss the idea / check if this has been already considered or planned. Best Regards, Dusan Chromy -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COLLECTIONS-362) CollectionUtils.filter() should return a boolean indicating whether the Collection was modified as a result of the call.
[ https://issues.apache.org/jira/browse/COLLECTIONS-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-362. -- Resolution: Fixed Fix Version/s: 4.0 r1125466. Changed filter return value to boolean. CollectionUtils.filter() should return a boolean indicating whether the Collection was modified as a result of the call. Key: COLLECTIONS-362 URL: https://issues.apache.org/jira/browse/COLLECTIONS-362 Project: Commons Collections Issue Type: Wish Components: Collection Affects Versions: 3.2 Reporter: Jean-Noel Rouvignac Assignee: Brent Worden Priority: Minor Fix For: 4.0 Attachments: COLLECTIONS-362.patch Here is what I mean: - test 1: List l = new ArrayList(); l.add(test); assertTrue( CollectionUtils.filter(l, FalsePredicate.getInstance()) ); assertTrue(l.isEmpty()); - test 2: List l = new ArrayList(); l.add(test); assertFalse( CollectionUtils.filter(l, TruePredicate.getInstance()) ); assertEquals(1, l.size()); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-342) Add ExpiringMap
[
https://issues.apache.org/jira/browse/COLLECTIONS-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13036934#comment-13036934
]
Brent Worden commented on COLLECTIONS-342:
--
PassiveTimeOutMap uses passive eviction where as ExpiryMap uses active
eviction. Should commons-collections use one or the other, both, or neither.
Add ExpiringMap
---
Key: COLLECTIONS-342
URL: https://issues.apache.org/jira/browse/COLLECTIONS-342
Project: Commons Collections
Issue Type: New Feature
Components: Map
Reporter: Marc Rohlfs
Priority: Minor
The project {{mina-core}} contains a very useful map implementation:
{{org.apache.mina.util.ExpiringMap}}. I'd suggest to adopt it for the
{{commons-collections}} project.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-229) Remove deprecated classes from generics version
[ https://issues.apache.org/jira/browse/COLLECTIONS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated COLLECTIONS-229: - Attachment: collections-229.diff Patch to remove remaining deprecations Remove deprecated classes from generics version --- Key: COLLECTIONS-229 URL: https://issues.apache.org/jira/browse/COLLECTIONS-229 Project: Commons Collections Issue Type: Task Components: Core, Iterator Reporter: Stephen Colebourne Assignee: Brent Worden Fix For: 4.0-beta-1 Attachments: AbstractBidiMapDecorator.java, AbstractDualBidiMap.java, AbstractOrderedBidiMapDecorator.java, AbstractSortedBidiMapDecorator.java, TestAbstractOrderedBidiMapDecorator.java, UnmodifiableBidiMap.java, UnmodifiableOrderedBidiMap.java, UnmodifiableSortedBidiMap.java, collections-229.diff The generics version should have no deprecations -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (COLLECTIONS-327) Serialisable classes without serialVersionUID
[ https://issues.apache.org/jira/browse/COLLECTIONS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-327. -- Resolution: Fixed SVN 1023281. all serialVersionUID fields added. Serialisable classes without serialVersionUID - Key: COLLECTIONS-327 URL: https://issues.apache.org/jira/browse/COLLECTIONS-327 Project: Commons Collections Issue Type: Improvement Affects Versions: 3.2 Reporter: Sebb Assignee: Brent Worden Fix For: 4.0 Attachments: collections.pat The following classes are serializable, but don't declare a serialVersionUID: ExtendedProperties TreeBidiMap -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COMMONSSITE-29) Link Javadocs to official Java API
[ https://issues.apache.org/jira/browse/COMMONSSITE-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COMMONSSITE-29. - Resolution: Fixed Fix Version/s: 18 SVN 1023356. Added a java api link POM property that is configured in the javadoc plugin. Components are free to override the property to link other Java versions. Link Javadocs to official Java API -- Key: COMMONSSITE-29 URL: https://issues.apache.org/jira/browse/COMMONSSITE-29 Project: Commons All Issue Type: Improvement Components: Commons Parent Pom Reporter: Benjamin Bentmann Assignee: Brent Worden Priority: Minor Fix For: 18 Attachments: COMMONSSITE-29.patch If some of your policies do not prohibit to link to Sun, enabling hyperlinks to the JRE API docs would be nice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COLLECTIONS-327) Serialisable classes without serialVersionUID
[ https://issues.apache.org/jira/browse/COLLECTIONS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921510#action_12921510 ] Brent Worden edited comment on COLLECTIONS-327 at 10/15/10 3:31 PM: TreeBidiMap is not serializable. Should it be? was (Author: brentworden): TreeBidiMap is not serializable. Shoud it be? Serialisable classes without serialVersionUID - Key: COLLECTIONS-327 URL: https://issues.apache.org/jira/browse/COLLECTIONS-327 Project: Commons Collections Issue Type: Improvement Affects Versions: 3.2 Reporter: Sebb Fix For: 4.0 Attachments: collections.pat The following classes are serializable, but don't declare a serialVersionUID: ExtendedProperties TreeBidiMap -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-327) Serialisable classes without serialVersionUID
[ https://issues.apache.org/jira/browse/COLLECTIONS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921510#action_12921510 ] Brent Worden commented on COLLECTIONS-327: -- TreeBidiMap is not serializable. Shoud it be? Serialisable classes without serialVersionUID - Key: COLLECTIONS-327 URL: https://issues.apache.org/jira/browse/COLLECTIONS-327 Project: Commons Collections Issue Type: Improvement Affects Versions: 3.2 Reporter: Sebb Fix For: 4.0 Attachments: collections.pat The following classes are serializable, but don't declare a serialVersionUID: ExtendedProperties TreeBidiMap -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COLLECTIONS-348) Javadoc: incorrect behavior explained for XXXUtils.transformedXXX
[ https://issues.apache.org/jira/browse/COLLECTIONS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-348. -- Resolution: Fixed all changes have been made. Javadoc: incorrect behavior explained for XXXUtils.transformedXXX - Key: COLLECTIONS-348 URL: https://issues.apache.org/jira/browse/COLLECTIONS-348 Project: Commons Collections Issue Type: Bug Components: Bag, Collection, List, Map, Set Affects Versions: 3.2, 4.0-beta-1 Reporter: Paul Benedict Fix For: 4.0 As a sequel to COLLECTIONS-288, any utility method that transformed needs to document that the incoming collection is not immediately transformed -- future additions are. Candidate methods: * BagUtils.transformedBag * BagUtils.transformedSortedBag * CollectionUtils.transform * CollectionUtils.transformedCollection * ListUtils.transformedList *done* * MapUtils.transformedMap * MapUtils.transformedSortedMap * SetUtils.transformedSet * SetUtils.transformedSortedSet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-344) Delete MapUtils.getXxx
[ https://issues.apache.org/jira/browse/COLLECTIONS-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921516#action_12921516 ] Brent Worden commented on COLLECTIONS-344: -- Those methods do a lot of type conversion that are not possible using just generics. Multiple methods are still needed to govern those conversions. Should the methods remain? Delete MapUtils.getXxx -- Key: COLLECTIONS-344 URL: https://issues.apache.org/jira/browse/COLLECTIONS-344 Project: Commons Collections Issue Type: Task Components: Map Reporter: Henri Yandell Fix For: 4.0 Seems pointless in a generics based world to have getDouble, getMap and their ilk. Delete em all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COLLECTIONS-8) Comparator Predicate
[ https://issues.apache.org/jira/browse/COLLECTIONS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved COLLECTIONS-8. Resolution: Fixed Fix Version/s: (was: 4.x) 4.0 SVN 1023105. Patch applied with minor changes: added generics and enumeration. Comparator Predicate Key: COLLECTIONS-8 URL: https://issues.apache.org/jira/browse/COLLECTIONS-8 Project: Commons Collections Issue Type: New Feature Components: Functor Affects Versions: 3.1 Environment: Operating System: other Platform: Other Reporter: Rune Peter Bjørnstad Assignee: Brent Worden Priority: Minor Fix For: 4.0 Attachments: ComparatorPredicate.diff, ComparatorPredicate.java A predicate that makes use of a Comparator object for evaluation is, in my opinion, missing in the functors package. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-249) Enhance closeQuietly to indicate success
[ https://issues.apache.org/jira/browse/IO-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12916509#action_12916509 ] Brent Worden commented on IO-249: - What about adding the concept of an exception handler similar to what java.lang.Thread provides? IOUtils could provide a new closeQuielty(T closeable, IOExceptionHandlerT handler) method whose implementation invokes a handler callback method upon receiving an IOException. With this, users are free to implement IOExceptionHandler as they desire to satisfy any diagnostic needs they have. Enhance closeQuietly to indicate success Key: IO-249 URL: https://issues.apache.org/jira/browse/IO-249 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 2.0 Reporter: Paul Benedict Assignee: Paul Benedict Priority: Minor Fix For: 2.x A convention of some programmers is to emit a log warning when a resource fails to close. Granted, such a condition is an error, but there's no reasonable recourse to the failure. Using IOUtils.closeQuietly() is very useful but all information about the success/failure is hidden. Returning Throwable will give insight into the error for diagnostic purposes. This change will be compatible with today's usage since the method currently returns void. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-362) Add serialVersionUID to Serializable classes
[ https://issues.apache.org/jira/browse/BEANUTILS-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated BEANUTILS-362: --- Attachment: beanutils-362.diff Patch adding default serialVersionUID's to the mentioned classes. Add serialVersionUID to Serializable classes Key: BEANUTILS-362 URL: https://issues.apache.org/jira/browse/BEANUTILS-362 Project: Commons BeanUtils Issue Type: Bug Reporter: Sebb Attachments: beanutils-362.diff The following classes are Serializable, but don't have serialVersionUID defined: BasicDynaBean BasicDynaClass DynaProperty LazyDynaBean LazyDynaList Performance (and JVM interoperability) would be improved by adding the UIDs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-313) Allow Closure and CollectionUtils.forAllDo to throw Exception
[ https://issues.apache.org/jira/browse/COLLECTIONS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12771583#action_12771583 ] Brent Worden commented on COLLECTIONS-313: -- In the past, I have created a closure implementation whose execute method delegates to an abstract method that allows throwing of exceptions. The attached patch contains the implementation. The benefit of using this closure extension is that it has no impact on the existing API and can be used in conjunction with all the existing functors. If others agree with this approach I can commit it along with some test cases. Allow Closure and CollectionUtils.forAllDo to throw Exception - Key: COLLECTIONS-313 URL: https://issues.apache.org/jira/browse/COLLECTIONS-313 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: 3.2 Reporter: David J. M. Karlsen Attachments: collections-313.txt Original Estimate: 0h Remaining Estimate: 0h It would be nice if Closure.execute and CollectionUtils.forAllDo would be allowed to throw Exceptions as the work inside of the Closure might very well throw exceptions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COLLECTIONS-313) Allow Closure and CollectionUtils.forAllDo to throw Exception
[ https://issues.apache.org/jira/browse/COLLECTIONS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated COLLECTIONS-313: - Attachment: collections-313.txt throwing closure Allow Closure and CollectionUtils.forAllDo to throw Exception - Key: COLLECTIONS-313 URL: https://issues.apache.org/jira/browse/COLLECTIONS-313 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: 3.2 Reporter: David J. M. Karlsen Attachments: collections-313.txt Original Estimate: 0h Remaining Estimate: 0h It would be nice if Closure.execute and CollectionUtils.forAllDo would be allowed to throw Exceptions as the work inside of the Closure might very well throw exceptions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COLLECTIONS-313) Allow Closure and CollectionUtils.forAllDo to throw Exception
[ https://issues.apache.org/jira/browse/COLLECTIONS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated COLLECTIONS-313: - Comment: was deleted (was: throwing closure) Allow Closure and CollectionUtils.forAllDo to throw Exception - Key: COLLECTIONS-313 URL: https://issues.apache.org/jira/browse/COLLECTIONS-313 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: 3.2 Reporter: David J. M. Karlsen Attachments: collections-313.txt Original Estimate: 0h Remaining Estimate: 0h It would be nice if Closure.execute and CollectionUtils.forAllDo would be allowed to throw Exceptions as the work inside of the Closure might very well throw exceptions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-311) Replaced the BinomialDistribution existing PDF with Catherine Loader's algorithm (as per wishlist on the wiki page)
[ https://issues.apache.org/jira/browse/MATH-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12770976#action_12770976 ] Brent Worden commented on MATH-311: --- Thanks for the contribution. This definitely improves the implementation. If I may be so bold, I would prefer the utility methods you have created, stirlerr and bd0, be placed in their own utility class. That way, those methods and this technique can more easily be leveraged by other distributions. What do other committers think? Replaced the BinomialDistribution existing PDF with Catherine Loader's algorithm (as per wishlist on the wiki page) --- Key: MATH-311 URL: https://issues.apache.org/jira/browse/MATH-311 Project: Commons Math Issue Type: Improvement Reporter: Nipun Jawalkar Priority: Minor Attachments: BinomialDistributionPatch.txt The existing PDF for Binomial distributions cannot handle n1029. This implementation of Catherine Loader's algorithm can handle n upto and larger than 100. The Commons-Math wiki page has a wishlist entry asking for this, with a link to the paper describing the new algorithm: http://projects.scipy.org/scipy/raw-attachment/ticket/620/loader2000Fast.pdf I've updated the probability() function in BInomialDistributionImpl.java, as well as the unit test for this method. The updated unit test has higher precision expected values, which were calculated with Mathematica 6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MATH-311) Replaced the BinomialDistribution existing PDF with Catherine Loader's algorithm (as per wishlist on the wiki page)
[ https://issues.apache.org/jira/browse/MATH-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12770976#action_12770976 ] Brent Worden edited comment on MATH-311 at 10/28/09 5:15 PM: - Thanks for the contribution. This definitely improves the implementation. If I may be so bold, I would prefer the utility methods you have created, stirlerr and bd0, be placed in their own utility class. That way, those methods and this technique can more easily be leveraged by other distributions. What do others think? was (Author: brentworden): Thanks for the contribution. This definitely improves the implementation. If I may be so bold, I would prefer the utility methods you have created, stirlerr and bd0, be placed in their own utility class. That way, those methods and this technique can more easily be leveraged by other distributions. What do other think? Replaced the BinomialDistribution existing PDF with Catherine Loader's algorithm (as per wishlist on the wiki page) --- Key: MATH-311 URL: https://issues.apache.org/jira/browse/MATH-311 Project: Commons Math Issue Type: Improvement Reporter: Nipun Jawalkar Priority: Minor Attachments: BinomialDistributionPatch.txt The existing PDF for Binomial distributions cannot handle n1029. This implementation of Catherine Loader's algorithm can handle n upto and larger than 100. The Commons-Math wiki page has a wishlist entry asking for this, with a link to the paper describing the new algorithm: http://projects.scipy.org/scipy/raw-attachment/ticket/620/loader2000Fast.pdf I've updated the probability() function in BInomialDistributionImpl.java, as well as the unit test for this method. The updated unit test has higher precision expected values, which were calculated with Mathematica 6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MATH-311) Replaced the BinomialDistribution existing PDF with Catherine Loader's algorithm (as per wishlist on the wiki page)
[ https://issues.apache.org/jira/browse/MATH-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12770976#action_12770976 ] Brent Worden edited comment on MATH-311 at 10/28/09 5:15 PM: - Thanks for the contribution. This definitely improves the implementation. If I may be so bold, I would prefer the utility methods you have created, stirlerr and bd0, be placed in their own utility class. That way, those methods and this technique can more easily be leveraged by other distributions. What do other think? was (Author: brentworden): Thanks for the contribution. This definitely improves the implementation. If I may be so bold, I would prefer the utility methods you have created, stirlerr and bd0, be placed in their own utility class. That way, those methods and this technique can more easily be leveraged by other distributions. What do other committers think? Replaced the BinomialDistribution existing PDF with Catherine Loader's algorithm (as per wishlist on the wiki page) --- Key: MATH-311 URL: https://issues.apache.org/jira/browse/MATH-311 Project: Commons Math Issue Type: Improvement Reporter: Nipun Jawalkar Priority: Minor Attachments: BinomialDistributionPatch.txt The existing PDF for Binomial distributions cannot handle n1029. This implementation of Catherine Loader's algorithm can handle n upto and larger than 100. The Commons-Math wiki page has a wishlist entry asking for this, with a link to the paper describing the new algorithm: http://projects.scipy.org/scipy/raw-attachment/ticket/620/loader2000Fast.pdf I've updated the probability() function in BInomialDistributionImpl.java, as well as the unit test for this method. The updated unit test has higher precision expected values, which were calculated with Mathematica 6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-311) Replaced the BinomialDistribution existing PDF with Catherine Loader's algorithm (as per wishlist on the wiki page)
[ https://issues.apache.org/jira/browse/MATH-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved MATH-311. --- Resolution: Fixed Fix Version/s: 2.1 - Made the SaddlePointExpansion (probably not the best name) utility class that implements Catheline Loader's saddle point expansion approximation. - Utilized this new class in the Binomial, Hypergeometric, and Poisson distributions. - Updated the Binomial test cases with the data provided by Nipun. Changes are all checked in and critiques are welcome. Replaced the BinomialDistribution existing PDF with Catherine Loader's algorithm (as per wishlist on the wiki page) --- Key: MATH-311 URL: https://issues.apache.org/jira/browse/MATH-311 Project: Commons Math Issue Type: Improvement Reporter: Nipun Jawalkar Priority: Minor Fix For: 2.1 Attachments: BinomialDistributionPatch.txt The existing PDF for Binomial distributions cannot handle n1029. This implementation of Catherine Loader's algorithm can handle n upto and larger than 100. The Commons-Math wiki page has a wishlist entry asking for this, with a link to the paper describing the new algorithm: http://projects.scipy.org/scipy/raw-attachment/ticket/620/loader2000Fast.pdf I've updated the probability() function in BInomialDistributionImpl.java, as well as the unit test for this method. The updated unit test has higher precision expected values, which were calculated with Mathematica 6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-227) denominatorDegreeOfFreedom in FDistribution leads to IllegalArgumentsException in UnivariateRealSolverUtils.bracket
[ https://issues.apache.org/jira/browse/MATH-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved MATH-227. --- Resolution: Fixed Assignee: Brent Worden SVN 699157. fixed in trunk. denominatorDegreeOfFreedom in FDistribution leads to IllegalArgumentsException in UnivariateRealSolverUtils.bracket --- Key: MATH-227 URL: https://issues.apache.org/jira/browse/MATH-227 Project: Commons Math Issue Type: Bug Affects Versions: 1.2 Environment: Java 1.5.0_15, Linux Reporter: Joerg Henning Assignee: Brent Worden Priority: Minor Fix For: Nightly Builds We are using the FDistributionImpl from the commons.math project to do some statistical calculations, namely receiving the upper and lower boundaries of a confidence interval. Everything is working fine and the results are matching our reference calculations. However, the FDistribution behaves strange if a denominatorDegreeOfFreedom of 2 is used, with an alpha-value of 0.95. This results in an IllegalArgumentsException, stating: Invalid endpoint parameters: lowerBound=0.0 initial=Infinity upperBound=1.7976931348623157E308 coming from org.apache.commons.math.analysis.UnivariateRealSolverUtils.bracket The problem is the 'initial' parameter to that function, wich is POSITIVE_INFINITY and therefore not within the boundaries. I already pinned down the problem to the FDistributions getInitialDomain()-method, wich goes like: return getDenominatorDegreesOfFreedom() / (getDenominatorDegreesOfFreedom() - 2.0); Obviously, in case of denominatorDegreesOfFreedom == 2, this must lead to a division-by-zero, resulting in POSTIVE_INFINITY. The result of this operation is then directly passed into the UnivariateRealSolverUtils.bracket() - method as second argument. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-204) BrentSolver throws IllegalArgumentException
[
https://issues.apache.org/jira/browse/MATH-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent Worden resolved MATH-204.
---
Resolution: Fixed
Fix Version/s: 1.3
SVN 654100. added root checks for the endpoints.
BrentSolver throws IllegalArgumentException
Key: MATH-204
URL: https://issues.apache.org/jira/browse/MATH-204
Project: Commons Math
Issue Type: Bug
Affects Versions: 1.2
Environment: Win XP
Reporter: Mick
Assignee: Brent Worden
Priority: Minor
Fix For: 1.3
I am getting this exception:
java.lang.IllegalArgumentException: Function values at endpoints do not have
different signs. Endpoints: [-10.0,1.7976931348623157E308] Values:
[0.0,-101945.04630982173]
at org.apache.commons.math.analysis.BrentSolver.solve(BrentSolver.java:99)
at org.apache.commons.math.analysis.BrentSolver.solve(BrentSolver.java:62)
The exception should not be thrown with values [0.0,-101945.04630982173]
because 0.0 is positive.
According to Brent Worden, the algorithm should stop and return 0 as the root
instead of throwing an exception.
The problem comes from this method:
public double solve(double min, double max) throws
MaxIterationsExceededException,
FunctionEvaluationException {
clearResult();
verifyInterval(min, max);
double yMin = f.value(min);
double yMax = f.value(max);
// Verify bracketing
if (yMin * yMax = 0) {
throw new IllegalArgumentException
(Function values at endpoints do not have different signs. +
Endpoints: [ + min + , + max + ] +
Values: [ + yMin + , + yMax + ]);
}
// solve using only the first endpoint as initial guess
return solve(min, yMin, max, yMax, min, yMin);
}
One way to fix it would be to add this code after the assignment of yMin and
yMax:
if (yMin ==0 || yMax == 0) {
return 0;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-203) Add general multiple linear regression
[ https://issues.apache.org/jira/browse/MATH-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12593048#action_12593048 ] Brent Worden commented on MATH-203: --- Support for 1.4 should continue for at least until J2SE 1.4 reaches its end of life which Sun has slated for October of this year. Even after that time, support for 1.4 should continue for a good deal longer. We've maintained 1.3 support and that reached its end of life in 2006. Add general multiple linear regression --- Key: MATH-203 URL: https://issues.apache.org/jira/browse/MATH-203 Project: Commons Math Issue Type: New Feature Reporter: Mauro Talevi Fix For: 2.0 Attachments: multiple-linear-regression-patch.txt Multiple regression is a fundamental element of several mathematical and statistical projects, among them econometrics one. A general linear multiple regression is contained in the JET Regression component at http://jet.codehaus.org/javadoc/jet-regression, but it could benefit a wider community if it was part of commons-math. The regression component has no external dependency outside of commons-math. Code for OLS and GLS multiple linear regression can be checked out from https://svn.codehaus.org/jet/trunk/jet-regression. If this is of interest, I'll re-package the code to live in org.apache.commons.math.stat.regression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-201) T-test p-value precision hampered by machine epsilon
[ https://issues.apache.org/jira/browse/MATH-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved MATH-201. --- Resolution: Fixed Fix Version/s: 1.3 SVN 645193. Changes applied. Thank you for reporting this issue. T-test p-value precision hampered by machine epsilon Key: MATH-201 URL: https://issues.apache.org/jira/browse/MATH-201 Project: Commons Math Issue Type: Bug Affects Versions: 1.2 Reporter: Peter Wyngaard Assignee: Brent Worden Priority: Minor Fix For: 1.3 The smallest p-value returned by TTestImpl.tTest() is the machine epsilon, which is 2.220446E-16 with IEEE754 64-bit double precision floats. We found this bug porting some analysis software from R to java, and noticed that the p-values did not match up. We believe we've identified why this is happening in commons-math-1.2, and a possible solution. Please be gentle, as I am not a statistics expert! The following method in org.apache.commons.math.stat.inference.TTestImpl currently implements the following method to calculate the p-value for a 2-sided, 2-sample t-test: protected double tTest(double m1, double m2, double v1, double v2, double n1, double n2) and it returns: 1.0 - distribution.cumulativeProbability(-t, t); at line 1034 in version 1.2. double cumulativeProbability(double x0, double x1) is implemented by org.apache.commons.math.distribution.AbstractDisstribution, and returns: return cumulativeProbability(x1) - cumulativeProbability(x0); So in essence, the p-value returned by TTestImpl.tTest() is: 1.0 - (cumulativeProbability(t) - cumulativeProbabily(-t)) For large-ish t-statistics, cumulativeProbabilty(-t) can get quite small, and cumulativeProbabilty(t) can get very close to 1.0. When cumulativeProbability(-t) is less than the machine epsilon, we get p-values equal to zero because: 1.0 - 1.0 + 0.0 = 0.0 An alternative calculation for the p-value of a 2-sided, 2-sample t-test is: p = 2.0 * cumulativeProbability(-t) This calculation does not suffer from the machine epsilon problem, and we are now getting p-values much smaller than the 2.2E-16 limit we were seeing previously. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-197) RandomDataImpl.nextPoisson() is extreme slow for large lambdas
[
https://issues.apache.org/jira/browse/MATH-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581576#action_12581576
]
Brent Worden commented on MATH-197:
---
I've been looking at Devroye's 'Non-Uniform Random Variate Generation' book.
The book is freely available at http://cg.scs.carleton.ca/~luc/rnbookindex.html.
Chapter 10 defines some rejection methods for Poisson generation which, the
author claims, are uniformily fast for all lambda.
I hope to soon implement one or more of the rejection methods and test its
performance.
RandomDataImpl.nextPoisson() is extreme slow for large lambdas
--
Key: MATH-197
URL: https://issues.apache.org/jira/browse/MATH-197
Project: Commons Math
Issue Type: Bug
Affects Versions: 1.2
Environment: jdk1.6.0_04, windows xp
Reporter: Tolja Zubow
The RandomDataImpl.nextPoisson() is extreme slow for large lambdas:
E.g. drawing 100 random numbers with lambda = 1000 takes around 10s on my
dual core with 2.2GHz.
With lambda smaller than 500 everything is fine. Any ideas?
RandomDataImpl r = new RandomDataImpl();
r.reSeed(101);
int d = 100;
long poissonLambda = 1000;
long st = System.currentTimeMillis();
for (int row = 0; row d; row++) {
long nxtRnd = r.nextPoisson(poissonLambda);
}
System.out.println(delta + (System.currentTimeMillis() - st));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-193) Minor javadoc and style fixes
[ https://issues.apache.org/jira/browse/MATH-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated MATH-193: -- Affects Version/s: (was: 1.2) 1.3 Minor javadoc and style fixes - Key: MATH-193 URL: https://issues.apache.org/jira/browse/MATH-193 Project: Commons Math Issue Type: Improvement Affects Versions: 1.3 Reporter: Michael Heuer Assignee: Brent Worden Priority: Minor Fix For: 2.0 Attachments: EmpiricalDistribution-patch.txt, EmpiricalDistributionTest-patch.txt, linear-package-javadoc-patch.txt, math.patch, ode-package-patch.txt Per discussion on the commons-dev mailing list in this thread http://tinyurl.com/326pym attached are minor javadoc and style fixes not addressed by Luc as described here http://tinyurl.com/3bp866 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-154) MathUtils addAndCheck and subAndCheck for long values
[
https://issues.apache.org/jira/browse/MATH-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brent Worden resolved MATH-154.
---
Resolution: Fixed
Added addAndCheck, mulAndCheck, and subAndCheck MathUtils methods for long
integer arguments.
MathUtils addAndCheck and subAndCheck for long values
-
Key: MATH-154
URL: https://issues.apache.org/jira/browse/MATH-154
Project: Commons Math
Issue Type: Improvement
Affects Versions: 1.1, Nightly Builds
Reporter: Remi Arntzen
Fix For: 1.2
Attachments: MathUtils.diff, MathUtils.diff
public static long addAndCheck(long x, long y) {
BigInteger s = BigInteger.valueOf(x).add(BigInteger.valueOf(y);
if (s.bitLength() + 1 Long.SIZE) {
throw new ArithmeticException(overflow: add);
}
return s.longValue();
}
public static long subAndCheck(long x, long y) {
BigInteger s = BigInteger.valueOf(x).subtract(BigInteger.valueOf(y));
if (s.bitLength() + 1 Long.SIZE) {
throw new ArithmeticException(overflow: add);
}
return s.longValue();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-170) Create threadsafe versions of DescriptiveStatisticsImpl and DescriptiveStatistics
[ https://issues.apache.org/jira/browse/MATH-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved MATH-170. --- Resolution: Fixed Fix Version/s: 1.2 Added the SynchronizedDescriptiveStatistics class. Create threadsafe versions of DescriptiveStatisticsImpl and DescriptiveStatistics - Key: MATH-170 URL: https://issues.apache.org/jira/browse/MATH-170 Project: Commons Math Issue Type: Improvement Affects Versions: 1.1 Environment: N/A Reporter: David J. M. Karlsen Fix For: 1.2 It would be very nice to have threadsafe versions (or make the current implementations) threadsafe for DescriptiveStatisticsImpl/DescriptiveStatistics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
