[jira] [Commented] (NUMBERS-99) Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
[
https://issues.apache.org/jira/browse/NUMBERS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955328#comment-16955328
]
Gilles Sadowski commented on NUMBERS-99:
Any objection to applying the patch?
> Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
>
>
> Key: NUMBERS-99
> URL: https://issues.apache.org/jira/browse/NUMBERS-99
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Reporter: Heinrich Bohne
>Priority: Minor
> Attachments: NUMBERS-99.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The methods {{add(int)}} and {{subtract(int)}} in the class
> {{org.apache.commons.numbers.fraction.Fraction}} do not take into account the
> risk of an integer overflow. For example, (2^31^ - 1)/2 + 1 = (2^31^ +
> 1)/2, so the numerator overflows an {{int}}, but when calculated with
> {{Fraction.add(int)}}, the method still returns normally.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-beanutils] melloware opened a new pull request #8: BeanPredicate switched from Collections4 to java.util.function.Predicate.
melloware opened a new pull request #8: BeanPredicate switched from Collections4 to java.util.function.Predicate. URL: https://github.com/apache/commons-beanutils/pull/8 @garydgregory I think this is what you were thinking for Predicate? Feel free to let me know if have the generics wrong or anything else you want changed. I kept the evaluate() method as is even though it just delegates to test() method. Wasn't sure if that was what you wanted either? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (COLLECTIONS-728) BloomFilter contribution
[
https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955217#comment-16955217
]
Gilles Sadowski edited comment on COLLECTIONS-728 at 10/19/19 5:22 PM:
---
Assuming {{BloomFilterI2}}, what would be the next step if we want (?) a class
where the state is provided by a {{BitSet}}? The following I suppose:
{code:java}
public BitsetBloomFilter implements BloomFilterI2 {
private final BitSet state;
// Constructor(s), builder, and so on.
// Define methods for which an implementation is required, but
// nothing else, assuming that reuse is good.
}
{code}
Now, making a wild ;) guess, I'd have a hard time to convince myself that this
implementation will be efficient given the generic passing around of data, with
all the boxing and unboxing, insead of operating directly on the {{state}}.
And, if obviously (?), we'd override the {{default}} methods, why the bloat?
Moreover, as said in the previous comment, the interface forces all
implementations to provide a method {{stream()}} with a semantic that might not
fit its underlying structure, or even that they would not need at all (say, in
order to provide the {{hammingDistance}} property).
This is not to say that the code in {{BloomFilterI2}} is never useful (I don't
know) but its place would seem to be in an abstract class, that would e.g. ease
prototyping of alternative implementations and test their correctness. In any
case, even if it were actually heading in the right direction (and I fail to
see it for some reason), it would still be a refinement that could be left for
once we agree on the "bare-bone" functionality.
was (Author: erans):
Assuming {{BloomFilterI2}}, what would be the next step if we want (?) a class
where the state is provided by a {{BitSet}}? The following I suppose:
{code:java}
public BitsetBloomFilter implements BloomFilterI2 {
private final BitSet state;
// Constructor(s), builder, and so on.
// Define methods for which an implementation is required, but
// nothing else, assuming that reuse is good.
}
{code}
Now, making a wild ;) guess, I'd have a hard time to convince myself that this
implementation will be efficient given the generic passing around of data, with
all the boxing and unboxing, insead of operating directly on the {{state}}.
And, if obviously (?), we'd override the {{default}} methods, why the bloat?
Moreover, as said in the previous comment, the interface forces all
implementations to provide a method {{stream()}} with a semantic that might not
fit its underlying structure, or even that they would not need at all (say, in
order to provide the {{hammingDistance}} property).
This is not to say that the code in {{BloomFilterI2}} is never useful (I don't
know) but its place would seem to be in an abstract class, that would e.g. ease
prototyping of alternative implementations and test their correctness. In any
case, even if it were actually heading in the right and I fail to see it for
some reason, it would still be a refinement that could be left for once we
agree on the "bare-bone" functionality.
> BloomFilter contribution
>
>
> Key: COLLECTIONS-728
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-728
> Project: Commons Collections
> Issue Type: Task
>Reporter: Claude Warren
>Priority: Minor
> Attachments: BF_Func.md, BloomFilter.java, BloomFilterI2.java,
> Usage.md
>
>
> Contribution of BloomFilter library comprising base implementation and gated
> collections.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-728) BloomFilter contribution
[
https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955217#comment-16955217
]
Gilles Sadowski edited comment on COLLECTIONS-728 at 10/19/19 4:51 PM:
---
Assuming {{BloomFilterI2}}, what would be the next step if we want (?) a class
where the state is provided by a {{BitSet}}? The following I suppose:
{code:java}
public BitsetBloomFilter implements BloomFilterI2 {
private final BitSet state;
// Constructor(s), builder, and so on.
// Define methods for which an implementation is required, but
// nothing else, assuming that reuse is good.
}
{code}
Now, making a wild ;) guess, I'd have a hard time to convince myself that this
implementation will be efficient given the generic passing around of data, with
all the boxing and unboxing, insead of operating directly on the {{state}}.
And, if obviously (?), we'd override the {{default}} methods, why the bloat?
Moreover, as said in the previous comment, the interface forces all
implementations to provide a method {{stream()}} with a semantic that might not
fit its underlying structure, or even that they would not need at all (say, in
order to provide the {{hammingDistance}} property).
This is not to say that the code in {{BloomFilterI2}} is never useful (I don't
know) but its place would seem to be in an abstract class, that would e.g. ease
prototyping of alternative implementations and test their correctness. In any
case, even if it were actually heading in the right and I fail to see it for
some reason, it would still be a refinement that could be left for once we
agree on the "bare-bone" functionality.
was (Author: erans):
Assuming {{BloomFilterI2}}, what would be the next step if we want (?) a class
where the state is provided by a {{BitSet}}? The following I suppose:
{code:java}
public BitsetBloomFilter implements BloomFilterI2 {
private final BitSet state;
// Constructor(s), builder, and so on.
// Define methods for which an implementation is required, but
// nothing else, assuming that reuse is good.
}
{code}
Now, making a wild ;) guess, I'd have a hard time to convince myself that this
implementation will be efficient given the generic passing around of data, with
all the boxing and unboxing, insead of operating directly on the {{state}}.
And, if obviously (?), we'd override the {{default}} methods, why the bloat?
Moreover, as said in the previous comment, the interface forces all
implementations to provide a method ({{stream()}} with a semantic that might
not fit its underlying structure, or even that they would not need at all (say,
in order to provide the {{hammingDistance}} property).
This is not to say that the code in {{BloomFilterI2}} is never useful (I don't
know) but its place would seem to be in an abstract class, that would e.g. ease
prototyping of alternative implementations and test their correctness. In any
case, even if it were actually heading in the right and I fail to see it for
some reason, it would still be a refinement that could be left for once we
agree on the "bare-bone" functionality.
> BloomFilter contribution
>
>
> Key: COLLECTIONS-728
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-728
> Project: Commons Collections
> Issue Type: Task
>Reporter: Claude Warren
>Priority: Minor
> Attachments: BF_Func.md, BloomFilter.java, BloomFilterI2.java,
> Usage.md
>
>
> Contribution of BloomFilter library comprising base implementation and gated
> collections.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-728) BloomFilter contribution
[
https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955217#comment-16955217
]
Gilles Sadowski commented on COLLECTIONS-728:
-
Assuming {{BloomFilterI2}}, what would be the next step if we want (?) a class
where the state is provided by a {{BitSet}}? The following I suppose:
{code:java}
public BitsetBloomFilter implements BloomFilterI2 {
private final BitSet state;
// Constructor(s), builder, and so on.
// Define methods for which an implementation is required, but
// nothing else, assuming that reuse is good.
}
{code}
Now, making a wild ;) guess, I'd have a hard time to convince myself that this
implementation will be efficient given the generic passing around of data, with
all the boxing and unboxing, insead of operating directly on the {{state}}.
And, if obviously (?), we'd override the {{default}} methods, why the bloat?
Moreover, as said in the previous comment, the interface forces all
implementations to provide a method ({{stream()}} with a semantic that might
not fit its underlying structure, or even that they would not need at all (say,
in order to provide the {{hammingDistance}} property).
This is not to say that the code in {{BloomFilterI2}} is never useful (I don't
know) but its place would seem to be in an abstract class, that would e.g. ease
prototyping of alternative implementations and test their correctness. In any
case, even if it were actually heading in the right and I fail to see it for
some reason, it would still be a refinement that could be left for once we
agree on the "bare-bone" functionality.
> BloomFilter contribution
>
>
> Key: COLLECTIONS-728
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-728
> Project: Commons Collections
> Issue Type: Task
>Reporter: Claude Warren
>Priority: Minor
> Attachments: BF_Func.md, BloomFilter.java, BloomFilterI2.java,
> Usage.md
>
>
> Contribution of BloomFilter library comprising base implementation and gated
> collections.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-728) BloomFilter contribution
[
https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955205#comment-16955205
]
Gilles Sadowski commented on COLLECTIONS-728:
-
{quote}IntStream stream(); // a stream of integers that are the indexes of the
enabled bits.
{quote}
As already noted, I don't have the practical knowledge to know whether this is
required for _all_ use-cases of the Bloom filter functionality. However, from a
design POV, this is a kludge (IMHO) because, as I've tried to convey on the ML,
it conflates the concept ("determines, with some probability of false positive,
whether something exists") with how it is implemented (a specific, and
potentially inefficient, representation of the underlying structure that
provides one way to obtain the requested result).
{quote}I have added BloomFilterI2
{quote}
A particular example strikes me as the very illustration of what I think is the
confusion between "BloomFilter" and "set of bits":
{quote}
{code:java}
default int hammingValue() {
return cardinality();
}
default int hammingDistance( BloomFilterI2 other ) {
return xorCardinality( other );
}
{code}
{quote}
IIUC, {{hammingDistance}} is a core property of the Bloom filters; whereas
{{xorCardinality}} is how it can be provided, given some assumption (i.e.
"BitSetI") of the underlying representation. The latter is, in OO terminology,
an implementation detail that should not percolate to the public API. Moreover,
in this case, the methods {{hammingValue}} and {{hammingDistance}} are clearly
redundant, and one would readily ask: Why don't we just drop them?
> BloomFilter contribution
>
>
> Key: COLLECTIONS-728
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-728
> Project: Commons Collections
> Issue Type: Task
>Reporter: Claude Warren
>Priority: Minor
> Attachments: BF_Func.md, BloomFilter.java, BloomFilterI2.java,
> Usage.md
>
>
> Contribution of BloomFilter library comprising base implementation and gated
> collections.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-728) BloomFilter contribution
[ https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955201#comment-16955201 ] Claude Warren commented on COLLECTIONS-728: --- BF_Func.md is a list of bloom filter functions that should be supported and what calculations they require. I have added BloomFilterI2 (to distinguish it from BloomFilter) that is an interface that implements the methods via default implementations but leaves 2 methods to be implemented. IntStream stream(); // a stream of integers that are the indexes of the enabled bits. BloomFilterI2 merge (BloomFilterI2 other ); // a Bloom filter constructed by ORing the other bloom filter with this. > BloomFilter contribution > > > Key: COLLECTIONS-728 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-728 > Project: Commons Collections > Issue Type: Task >Reporter: Claude Warren >Priority: Minor > Attachments: BF_Func.md, BloomFilter.java, BloomFilterI2.java, > Usage.md > > > Contribution of BloomFilter library comprising base implementation and gated > collections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-728) BloomFilter contribution
[ https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-728: -- Attachment: (was: BloomFilterI2.java) > BloomFilter contribution > > > Key: COLLECTIONS-728 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-728 > Project: Commons Collections > Issue Type: Task >Reporter: Claude Warren >Priority: Minor > Attachments: BF_Func.md, BloomFilter.java, BloomFilterI2.java, > Usage.md > > > Contribution of BloomFilter library comprising base implementation and gated > collections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-728) BloomFilter contribution
[ https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-728: -- Attachment: BloomFilterI2.java > BloomFilter contribution > > > Key: COLLECTIONS-728 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-728 > Project: Commons Collections > Issue Type: Task >Reporter: Claude Warren >Priority: Minor > Attachments: BF_Func.md, BloomFilter.java, BloomFilterI2.java, > Usage.md > > > Contribution of BloomFilter library comprising base implementation and gated > collections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-728) BloomFilter contribution
[ https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-728: -- Attachment: BloomFilterI2.java > BloomFilter contribution > > > Key: COLLECTIONS-728 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-728 > Project: Commons Collections > Issue Type: Task >Reporter: Claude Warren >Priority: Minor > Attachments: BF_Func.md, BloomFilter.java, BloomFilterI2.java, > Usage.md > > > Contribution of BloomFilter library comprising base implementation and gated > collections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-728) BloomFilter contribution
[ https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-728: -- Attachment: (was: BloomFilter.java) > BloomFilter contribution > > > Key: COLLECTIONS-728 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-728 > Project: Commons Collections > Issue Type: Task >Reporter: Claude Warren >Priority: Minor > Attachments: BF_Func.md, BloomFilter.java, Usage.md > > > Contribution of BloomFilter library comprising base implementation and gated > collections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-728) BloomFilter contribution
[ https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-728: -- Attachment: BloomFilter.java > BloomFilter contribution > > > Key: COLLECTIONS-728 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-728 > Project: Commons Collections > Issue Type: Task >Reporter: Claude Warren >Priority: Minor > Attachments: BF_Func.md, BloomFilter.java, Usage.md > > > Contribution of BloomFilter library comprising base implementation and gated > collections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-728) BloomFilter contribution
[ https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-728: -- Attachment: BF_Func.md > BloomFilter contribution > > > Key: COLLECTIONS-728 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-728 > Project: Commons Collections > Issue Type: Task >Reporter: Claude Warren >Priority: Minor > Attachments: BF_Func.md, BloomFilter.java, Usage.md > > > Contribution of BloomFilter library comprising base implementation and gated > collections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-728) BloomFilter contribution
[ https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated COLLECTIONS-728: -- Attachment: Usage.md > BloomFilter contribution > > > Key: COLLECTIONS-728 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-728 > Project: Commons Collections > Issue Type: Task >Reporter: Claude Warren >Priority: Minor > Attachments: BloomFilter.java, Usage.md > > > Contribution of BloomFilter library comprising base implementation and gated > collections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LANG-1177) Improve indexOf performance when called multiple times
[ https://issues.apache.org/jira/browse/LANG-1177?focusedWorklogId=330929&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-330929 ] ASF GitHub Bot logged work on LANG-1177: Author: ASF GitHub Bot Created on: 19/Oct/19 12:15 Start Date: 19/Oct/19 12:15 Worklog Time Spent: 10m Work Description: coveralls commented on issue #471: [LANG-1177] Added indexesOf methods and simplified removeAllOccurences URL: https://github.com/apache/commons-lang/pull/471#issuecomment-543509688 [](https://coveralls.io/builds/26414874) Coverage increased (+0.02%) to 95.378% when pulling **3a4b02e589ce4d6a7a81618dae21e9f596678efc on lielfr:lang-1177** into **9489d55d5c6a33e8ce5cc64b00a3282e84d2a81f on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 330929) Time Spent: 1h 10m (was: 1h) > Improve indexOf performance when called multiple times > -- > > Key: LANG-1177 > URL: https://issues.apache.org/jira/browse/LANG-1177 > Project: Commons Lang > Issue Type: Improvement >Reporter: Sebb >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > The indexOf methods search for a single entry in an array. > This works fine when only the first matching entry is needed, however it is > not so efficient when all matches are needed (because of the setup/teardown > overheads). > It might be useful to introduce an indexesOf method that returns a BitSet > containing all the matches. > This can then be used in the removeAllOccurrences methods. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on issue #471: [LANG-1177] Added indexesOf methods and simplified removeAllOccurences
coveralls edited a comment on issue #471: [LANG-1177] Added indexesOf methods and simplified removeAllOccurences URL: https://github.com/apache/commons-lang/pull/471#issuecomment-543509688 [](https://coveralls.io/builds/26414874) Coverage increased (+0.02%) to 95.378% when pulling **3a4b02e589ce4d6a7a81618dae21e9f596678efc on lielfr:lang-1177** into **9489d55d5c6a33e8ce5cc64b00a3282e84d2a81f on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (LANG-1177) Improve indexOf performance when called multiple times
[
https://issues.apache.org/jira/browse/LANG-1177?focusedWorklogId=330927&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-330927
]
ASF GitHub Bot logged work on LANG-1177:
Author: ASF GitHub Bot
Created on: 19/Oct/19 12:01
Start Date: 19/Oct/19 12:01
Worklog Time Spent: 10m
Work Description: lielfr commented on pull request #471: [LANG-1177]
Added indexesOf methods and simplified removeAllOccurences
URL: https://github.com/apache/commons-lang/pull/471#discussion_r336734563
##
File path: src/main/java/org/apache/commons/lang3/ArrayUtils.java
##
@@ -3254,6 +3254,57 @@ public static int indexOf(final Object[] array, final
Object objectToFind, int s
return INDEX_NOT_FOUND;
}
+/**
+ * Finds the indices of the given object in the array.
+ *
+ * This method returns an empty BitSet for a {@code null} input array.
+ *
+ * @param array the array to search through for the object, may be {@code
null}
+ * @param objectToFind the object to find, may be {@code null}
+ * @return a BitSet of all the indices of the object within the array,
+ * an empty BitSet if not found or {@code null} array input
Review comment:
Done
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 330927)
Time Spent: 1h (was: 50m)
> Improve indexOf performance when called multiple times
> --
>
> Key: LANG-1177
> URL: https://issues.apache.org/jira/browse/LANG-1177
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Sebb
>Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The indexOf methods search for a single entry in an array.
> This works fine when only the first matching entry is needed, however it is
> not so efficient when all matches are needed (because of the setup/teardown
> overheads).
> It might be useful to introduce an indexesOf method that returns a BitSet
> containing all the matches.
> This can then be used in the removeAllOccurrences methods.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] lielfr commented on a change in pull request #471: [LANG-1177] Added indexesOf methods and simplified removeAllOccurences
lielfr commented on a change in pull request #471: [LANG-1177] Added indexesOf
methods and simplified removeAllOccurences
URL: https://github.com/apache/commons-lang/pull/471#discussion_r336734563
##
File path: src/main/java/org/apache/commons/lang3/ArrayUtils.java
##
@@ -3254,6 +3254,57 @@ public static int indexOf(final Object[] array, final
Object objectToFind, int s
return INDEX_NOT_FOUND;
}
+/**
+ * Finds the indices of the given object in the array.
+ *
+ * This method returns an empty BitSet for a {@code null} input array.
+ *
+ * @param array the array to search through for the object, may be {@code
null}
+ * @param objectToFind the object to find, may be {@code null}
+ * @return a BitSet of all the indices of the object within the array,
+ * an empty BitSet if not found or {@code null} array input
Review comment:
Done
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Work logged] (LANG-1177) Improve indexOf performance when called multiple times
[
https://issues.apache.org/jira/browse/LANG-1177?focusedWorklogId=330925&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-330925
]
ASF GitHub Bot logged work on LANG-1177:
Author: ASF GitHub Bot
Created on: 19/Oct/19 11:43
Start Date: 19/Oct/19 11:43
Worklog Time Spent: 10m
Work Description: Stzx commented on pull request #471: [LANG-1177] Added
indexesOf methods and simplified removeAllOccurences
URL: https://github.com/apache/commons-lang/pull/471#discussion_r336734013
##
File path: src/main/java/org/apache/commons/lang3/ArrayUtils.java
##
@@ -3254,6 +3254,57 @@ public static int indexOf(final Object[] array, final
Object objectToFind, int s
return INDEX_NOT_FOUND;
}
+/**
+ * Finds the indices of the given object in the array.
+ *
+ * This method returns an empty BitSet for a {@code null} input array.
+ *
+ * @param array the array to search through for the object, may be {@code
null}
+ * @param objectToFind the object to find, may be {@code null}
+ * @return a BitSet of all the indices of the object within the array,
+ * an empty BitSet if not found or {@code null} array input
Review comment:
The next version is `3.10`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 330925)
Time Spent: 50m (was: 40m)
> Improve indexOf performance when called multiple times
> --
>
> Key: LANG-1177
> URL: https://issues.apache.org/jira/browse/LANG-1177
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Sebb
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The indexOf methods search for a single entry in an array.
> This works fine when only the first matching entry is needed, however it is
> not so efficient when all matches are needed (because of the setup/teardown
> overheads).
> It might be useful to introduce an indexesOf method that returns a BitSet
> containing all the matches.
> This can then be used in the removeAllOccurrences methods.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] Stzx commented on a change in pull request #471: [LANG-1177] Added indexesOf methods and simplified removeAllOccurences
Stzx commented on a change in pull request #471: [LANG-1177] Added indexesOf
methods and simplified removeAllOccurences
URL: https://github.com/apache/commons-lang/pull/471#discussion_r336734013
##
File path: src/main/java/org/apache/commons/lang3/ArrayUtils.java
##
@@ -3254,6 +3254,57 @@ public static int indexOf(final Object[] array, final
Object objectToFind, int s
return INDEX_NOT_FOUND;
}
+/**
+ * Finds the indices of the given object in the array.
+ *
+ * This method returns an empty BitSet for a {@code null} input array.
+ *
+ * @param array the array to search through for the object, may be {@code
null}
+ * @param objectToFind the object to find, may be {@code null}
+ * @return a BitSet of all the indices of the object within the array,
+ * an empty BitSet if not found or {@code null} array input
Review comment:
The next version is `3.10`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Work logged] (LANG-1177) Improve indexOf performance when called multiple times
[
https://issues.apache.org/jira/browse/LANG-1177?focusedWorklogId=330913&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-330913
]
ASF GitHub Bot logged work on LANG-1177:
Author: ASF GitHub Bot
Created on: 19/Oct/19 09:29
Start Date: 19/Oct/19 09:29
Worklog Time Spent: 10m
Work Description: lielfr commented on pull request #471: [LANG-1177]
Added indexesOf methods and simplified removeAllOccurences
URL: https://github.com/apache/commons-lang/pull/471#discussion_r336729711
##
File path: src/main/java/org/apache/commons/lang3/ArrayUtils.java
##
@@ -3254,6 +3254,57 @@ public static int indexOf(final Object[] array, final
Object objectToFind, int s
return INDEX_NOT_FOUND;
}
+/**
+ * Finds the indices of the given object in the array.
+ *
+ * This method returns an empty BitSet for a {@code null} input array.
+ *
+ * @param array the array to search through for the object, may be {@code
null}
+ * @param objectToFind the object to find, may be {@code null}
+ * @return a BitSet of all the indices of the object within the array,
+ * an empty BitSet if not found or {@code null} array input
Review comment:
Okay, which version? 4.0?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 330913)
Time Spent: 40m (was: 0.5h)
> Improve indexOf performance when called multiple times
> --
>
> Key: LANG-1177
> URL: https://issues.apache.org/jira/browse/LANG-1177
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Sebb
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The indexOf methods search for a single entry in an array.
> This works fine when only the first matching entry is needed, however it is
> not so efficient when all matches are needed (because of the setup/teardown
> overheads).
> It might be useful to introduce an indexesOf method that returns a BitSet
> containing all the matches.
> This can then be used in the removeAllOccurrences methods.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] lielfr commented on a change in pull request #471: [LANG-1177] Added indexesOf methods and simplified removeAllOccurences
lielfr commented on a change in pull request #471: [LANG-1177] Added indexesOf
methods and simplified removeAllOccurences
URL: https://github.com/apache/commons-lang/pull/471#discussion_r336729711
##
File path: src/main/java/org/apache/commons/lang3/ArrayUtils.java
##
@@ -3254,6 +3254,57 @@ public static int indexOf(final Object[] array, final
Object objectToFind, int s
return INDEX_NOT_FOUND;
}
+/**
+ * Finds the indices of the given object in the array.
+ *
+ * This method returns an empty BitSet for a {@code null} input array.
+ *
+ * @param array the array to search through for the object, may be {@code
null}
+ * @param objectToFind the object to find, may be {@code null}
+ * @return a BitSet of all the indices of the object within the array,
+ * an empty BitSet if not found or {@code null} array input
Review comment:
Okay, which version? 4.0?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
