On Sun, Nov 3, 2024 at 4:05 AM Claude Warren wrote:
> I believe I answered this elsewhere but just for clarity in the archive.
>
> I believe the MultidimensionalBloomFilters add a new level of complexity
> that we do not want to address at this time. I also believe that
> MultidimensionalBloomFi
I believe I answered this elsewhere but just for clarity in the archive.
I believe the MultidimensionalBloomFilters add a new level of complexity
that we do not want to address at this time. I also believe that
MultidimensionalBloomFilters will not break binary compatibility. They
should extend
search is a matching operation against contained filters ... I don't think
we want to call it match as that is then confused with the standard Bloom
filter match.
locate is an exact match -- byte for byte the same. Technically search
results can be filtered for locate but in some implementations l
Thank you for explaining multidimensional filters here. It's not clear to
me yet if we need to introduce the new interface. I'll have to reread the
great docs you wrote 😀
The search() vs. locate() names are a bit confusing. Are these BF naming
conventions? If not, and if the difference is the exac
I read in the MD:
"...he data in transit and at rest is encrypted or at least strongly hashed"
What does "strongly hashed" mean here? Is this part of the Bloom Filter
vernacular? Shouldn't we define this somewhere?
TY,
Gary
On Sat, Oct 12, 2024, 5:07 AM Claude Warren wrote:
> > ...
> > We can
Hi,
The MD refers several time to "10K filters". Where does this limit come
from? If there is a baseline CPU and RAM combination this is based on, the
document should state it IMO. Or, is it based on the width of a Java int or
a Java long?
TY,
Gary
On Sat, Oct 12, 2024, 5:07 AM Claude Warren wr
In the MD:
" This index arises from the observation that no target can match a filter
with a lower hamming value."
Shouldn't "hamming" be capitalized?
Gary
On Sat, Oct 12, 2024, 5:07 AM Claude Warren wrote:
> > ...
> > We can delay MultidimensionalBloomFilter unless introducing it later
> wou
Hi Claude,
The MD file was likely added after M2 was released and would explain why it
didn't make it to the site (yet).
In the MD, you write:
"Bloom filter comparisons are extremely fast taking on approximately five
(5) machine instructions for the simple comparison."
I think this needs clarif
Thank you Claude, the git master code now throws instead of returning null.
We can delay MultidimensionalBloomFilter unless introducing it later would
break binary compatibility. How beneficial would introducing this interface
for users?
Gary
On Sun, Oct 6, 2024, 10:58 AM Claude Warren wrote:
This is starting tondelve into the realm of multidimensional bloom filters.
I think throwing an exception on a null or zero length array is acceptable.
We could define an interface MultidimensionalBloomFilter that could be
implemented by any Bloom filter that comprises multiple filters and givr i
Minor difference in what the time is. In the Kip it is an expires time and
the filter is created with a TTL value. The copy is also slightly
different as the expires time is reset.
On Sat, Oct 5, 2024 at 8:53 PM Gary Gregory wrote:
> On Sat, Oct 5, 2024 at 11:26 AM Claude Warren wrote:
>
> >
On Sat, Oct 5, 2024 at 11:26 AM Claude Warren wrote:
> >
> > WrappedBloomFilter is not a WrappedBloomFilter,
>
>
> This is true in most useful cases for the test `
> assertEquals(bf1.getClass(), copy.getClass());
>
> In a proposed KIP (Kafka Improvement Proposal) there is a Bloom filter that
> i
On Sat, Oct 5, 2024 at 11:46 AM Claude Warren wrote:
> Your Fixture solution is close to correct.
>
> @Override
> > public WrappedBloomFilter copy() {
> > return new Fixture(getWrapped());
> > }
>
>
> should return new Fixture(getWrapped().copy());
>
Thank you for you
On Fri, Oct 4, 2024 at 1:30 PM Alex Herbert
wrote:
> You cannot return an empty BloomFilter when there is no array of
> BloomFilters to flatten. The BloomFilter is tied to a Shape. Without a
> shape you cannot know what size filter to create. So we have to return
> null or throw an exception. Wha
Your Fixture solution is close to correct.
@Override
> public WrappedBloomFilter copy() {
> return new Fixture(getWrapped());
> }
should return new Fixture(getWrapped().copy());
On Sat, Oct 5, 2024 at 4:42 PM Claude Warren wrote:
> Ignore my previous message. I do
Ignore my previous message. I don't know where my mind was.
On Sat, Oct 5, 2024 at 4:26 PM Claude Warren wrote:
> WrappedBloomFilter is not a WrappedBloomFilter,
>
>
> This is true in most useful cases for the test `
> assertEquals(bf1.getClass(), copy.getClass());
>
> In a proposed KIP (Kafka
>
> WrappedBloomFilter is not a WrappedBloomFilter,
This is true in most useful cases for the test `
assertEquals(bf1.getClass(), copy.getClass());
In a proposed KIP (Kafka Improvement Proposal) there is a Bloom filter that
is decorated with additional data (The timestamp for when it was create
The problem with returning null is that all call sites must now check for
null or end up throwing an NPE. I'd prefer to fail sooner rather than
later, so I'd go with throwing an exception and updating the Javadoc.
WDYT?
Gary
On Fri, Oct 4, 2024, 1:30 PM Alex Herbert wrote:
> You cannot return
You cannot return an empty BloomFilter when there is no array of
BloomFilters to flatten. The BloomFilter is tied to a Shape. Without a
shape you cannot know what size filter to create. So we have to return
null or throw an exception. Whatever choice must be documented.
Note we do not currently ch
OK, but how do you create an empty filter?
Gary
On Fri, Oct 4, 2024, 12:54 PM Claude Warren wrote:
> I think that it should return an empty filter as the javadoc says
>
>
> On Fri 4 Oct 2024, 15:53 Gary D. Gregory, wrote:
>
> > See the new disabled test BloomFilterExtractorTest.
> >
> > Gary
>
I think that it should return an empty filter as the javadoc says
On Fri 4 Oct 2024, 15:53 Gary D. Gregory, wrote:
> See the new disabled test BloomFilterExtractorTest.
>
> Gary
>
> On 2024/10/04 14:51:55 "Gary D. Gregory" wrote:
> > Hi Claude and all,
> >
> > The method:
> >
> >
> org.apache.c
See the new disabled test BloomFilterExtractorTest.
Gary
On 2024/10/04 14:51:55 "Gary D. Gregory" wrote:
> Hi Claude and all,
>
> The method:
>
> org.apache.commons.collections4.bloomfilter.BloomFilterExtractor.flatten()
>
> is documented as always returning a BloomFilter:
>
> /**
>
Hi Cpm,
The next site update will only offer the 4.5.x version for download. Please
use 4.5.x.
Gary
On Fri, Sep 13, 2024, 9:04 AM Christian P. MOMON
wrote:
>
>Hi,
>
>In the web page "Download Apache Commons Collections"
> (https://commons.apache.org/collections/download_collections.cgi
I do not think we should open up 3.x for more releases.
Gary
On Tue, Jul 30, 2024, 10:49 AM Julian Reschke
wrote:
> Hi there,
>
> I'm working on a project which unfortunately is stuck with
> commons-collections3 for the time being (if you wonder why: somebody
> exposed the cc3 Predicate class i
Hello Juilan,
I think this should be a driver for Collections 5 because:
- we don't want to break BC
- what would start with copy pasta for one class could degenerate into a
ton of it
WDYT?
Gary
On Mon, Jul 8, 2024, 6:21 AM Julian Reschke
wrote:
> On 08.07.2024 11:18, Julian Reschke wrote:
>
On 08.07.2024 11:18, Julian Reschke wrote:
On 07.07.2024 17:12, Gary Gregory wrote:
We don't want to break binary compatibility within the 4.x release line.
Gary
...
Would we have to?
OK, so this is about the return values.
It's still unfortunate, because it makes it harder to convert exis
On 07.07.2024 17:12, Gary Gregory wrote:
We don't want to break binary compatibility within the 4.x release line.
Gary
...
Would we have to?
Best regards, Julian
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
F
you are correct. it was using some older transitive deps.. resolved. thank you
for your patience .
Sent: Sunday, July 07, 2024 at 11:12 AM
From: "Gary Gregory"
To: julian.resc...@gmx.de.invalid
Cc: "Commons Developers List"
Subject: Re: [collections] Predicate vs Pre
We don't want to break binary compatibility within the 4.x release line.
Gary
On Mon, Jul 1, 2024, 12:26 PM Julian Reschke
wrote:
> Hi there!
>
> We are (finally) in the process of converting a project to
> commons-collections4. Unfortunately, we have a few APIs that return
> commons-collection
Absolutely true that same functionality can be achieved with a nested for-loop
or a flatMap,
however for a 10+ nesting levels - or dynamic number/order of nesting levels -
it becomes hardly manageable.
On 2024/06/26 21:02:53 Peter Burka wrote:
> I don't know if it's been proposed before, but I t
I don't know if it's been proposed before, but I think any implementation
would necessarily be inefficient.
I imagine such an iterator would need to produce objects of type Pair.
This would lead to a lot of allocation and could create garbage collection
pressure. The same functionality can be achie
The RC is available :)
On 2024/06/13 14:04:47 Gary Gregory wrote:
> That all sounds good to me. I'll cut a release over the next few days.
>
> Gary
>
> On Thu, Jun 13, 2024, 9:48 AM Claude Warren wrote:
>
> > Given the hectic nature of my life at the moment, I would say longer than a
> > week.
Feel free to write the docs in whatever format you want :-) It just
needs to build with Maven (prefereably)
Gary
On Sat, Jun 15, 2024 at 12:07 PM Phil Steitz wrote:
>
> On Sat, Jun 15, 2024 at 8:19 AM Claude Warren wrote:
>
> > Greetings,
> >
> > I see that we support xml documents for document
We (well, not me) are revamping the Log4j site documentation using
AsciiDoc. Take a look there if you're curious.
Gary
On Sat, Jun 15, 2024 at 12:07 PM Phil Steitz wrote:
>
> On Sat, Jun 15, 2024 at 8:19 AM Claude Warren wrote:
>
> > Greetings,
> >
> > I see that we support xml documents for do
On Sat, Jun 15, 2024 at 8:19 AM Claude Warren wrote:
> Greetings,
>
> I see that we support xml documents for documentation but does anyone know
> if markdown is supported? I have a number of markdown based documents that
> would work well for the Bloom filter documentation, but translating to X
That all sounds good to me. I'll cut a release over the next few days.
Gary
On Thu, Jun 13, 2024, 9:48 AM Claude Warren wrote:
> Given the hectic nature of my life at the moment, I would say longer than a
> week.
> Would it make sense to do an M2 to verify the APIs and then lock down and
> comb
Given the hectic nature of my life at the moment, I would say longer than a
week.
Would it make sense to do an M2 to verify the APIs and then lock down and
comb through documentation with a fine tooth comb, looking for errors and
missing explanations before an M3 that has no code, just documentatio
It would be better IMO to have the updated documentation for M2 but not
critical, let me know if you think you can do it "soon" (say within a week)
or if it's just on a longer term to-do list.
TY,
Gary
On Thu, Jun 13, 2024, 3:39 AM Claude Warren wrote:
> The only changes I am considering are to
The only changes I am considering are to remove any stream usage within the
code, no external changes. Additionally, there may be some new
documentation coming but that can wait until after M2.
Thanks for all your hard work on this.
Claude
On Wed, Jun 12, 2024 at 7:30 PM Gary D. Gregory wrote:
You need to test it with some realistic data for a benchmark.
In Commons Statistics we have a case where all elements of an array are
passed to a consumer. So you have either:
int[] a = ...
IntConsumer c = ...
Arrays.stream(a).forEach(c::accept)
vs
for (final int i : a) {
c.accept(i);
}
W
Pull request https://github.com/apache/commons-collections/pull/501 addresses
this issue
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Tracking this with:
https://issues.apache.org/jira/browse/COLLECTIONS-855
On Sat, 18 May 2024 at 08:26, Alex Herbert wrote:
> Thanks for highlighting this. I did not use the original paper and based
> the implementation on Wikipedia.
>
> I think the issue is that we use i in [0, k); we can corr
Thanks for highlighting this. I did not use the original paper and based
the implementation on Wikipedia.
I think the issue is that we use i in [0, k); we can correct this by using
i in [1, k]. The order inside the loop would not change but we would have
to decrement i to use in the assignment giv
I have updated Collections-854 [1] to reflect the naming that we have been
talking about and will start on the refactoring soon. Please start
watching that ticket.
Claude
[1] https://issues.apache.org/jira/browse/COLLECTIONS-854
On Mon, May 13, 2024 at 12:33 PM Claude Warren wrote:
> A coup
A couple of messages back, I proposed a some documentation updates and a
few names changes:
In thinking about the term Producer, other terms could be used Interrogator
> (sounds like you can add a query), Extractor might work. But it has also
> come to mind that there is a "compute" series of met
I usually update changes.xml right after I merge a PR.
Gary
On Sun, May 12, 2024, 6:12 AM Claude Warren wrote:
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
No. Just add it as a second commit after merge.
On Sun, 12 May 2024, 11:12 Claude Warren, wrote:
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
LGTM. Maybe the current PR (LGTM) should be merged first, Alex, how does
that PR look to you?
Gary
On Fri, May 3, 2024, 11:44 AM Claude Warren wrote:
> Gary and Alex,
>
> Any thoughts on this?
>
> Claude
>
> On Wed, May 1, 2024 at 7:55 AM Claude Warren wrote:
>
>> Good suggestions.
>>
>> short
Gary and Alex,
Any thoughts on this?
Claude
On Wed, May 1, 2024 at 7:55 AM Claude Warren wrote:
> Good suggestions.
>
> short-circuit. We could make this distinction by including it in the name:
>> forEachUntil(Predicate ...), forEachUnless, ...
>
>
> We need the unit name in the method name.
Good suggestions.
short-circuit. We could make this distinction by including it in the name:
> forEachUntil(Predicate ...), forEachUnless, ...
We need the unit name in the method name. All Bloom filters implement
IndexProducer and BitmapProducer and since they use Predicate method
parameters th
On 2024/04/30 14:33:47 Alex Herbert wrote:
> On Tue, 30 Apr 2024 at 14:45, Gary D. Gregory wrote:
>
> > Hi Claude,
> >
> > Thank you for the detailed reply :-) A few comments below.
> >
> > On 2024/04/30 06:29:38 Claude Warren wrote:
> > > I will see if I can clarify the javadocs and make thin
On Tue, 30 Apr 2024 at 14:45, Gary D. Gregory wrote:
> Hi Claude,
>
> Thank you for the detailed reply :-) A few comments below.
>
> On 2024/04/30 06:29:38 Claude Warren wrote:
> > I will see if I can clarify the javadocs and make things clearer.
> >
> > What I think I specifically heard is:
> >
Hi Claude,
Thank you for the detailed reply :-) A few comments below.
On 2024/04/30 06:29:38 Claude Warren wrote:
> I will see if I can clarify the javadocs and make things clearer.
>
> What I think I specifically heard is:
>
>- Be clear that producers are fast fail iterators with predicate
I will see if I can clarify the javadocs and make things clearer.
What I think I specifically heard is:
- Be clear that producers are fast fail iterators with predicate tests.
- Rename CellConsumer to CellPredicate (?)
- The semantic nomenclature:
- Bitmaps are arrays of bits not a
Thank you for your thoughtful reply. See my comments below.
On Sun, Apr 28, 2024 at 11:10 AM Alex Herbert wrote:
>
> Hi Gary,
>
> I am in favour of using nomenclature and patterns that will be familiar to
> a Java developer. But only if they match the familiar JDK use patterns. The
> Bloom filter
> There is no primitive specialisation
of Iterator for long
https://docs.oracle.com/javase/8/docs/api/java/util/PrimitiveIterator.OfLong.html
On Sun, Apr 28, 2024 at 10:00 AM Alex Herbert
wrote:
> Hi Gary,
>
> I am in favour of using nomenclature and patterns that will be familiar to
> a Java
Hi Gary,
I am in favour of using nomenclature and patterns that will be familiar to
a Java developer. But only if they match the familiar JDK use patterns. The
Bloom filter package has some atypical use patterns that have driven the
current API to where it is. I'll try and describe these below.
O
Thank you for the explanation. It sounds like leaving it as is better.
Gary
On Fri, Apr 26, 2024, 2:25 AM Alex Herbert wrote:
> On Thu, 25 Apr 2024 at 21:47, Gary D. Gregory wrote:
>
> > Hi Clause, Albert, and all,
> >
> > Why not make Hasher more functional like so:
> >
> > public interface H
On Thu, 25 Apr 2024 at 21:47, Gary D. Gregory wrote:
> Hi Clause, Albert, and all,
>
> Why not make Hasher more functional like so:
>
> public interface Hasher extends Function
>
> It would implement the standard `apply` instead of `indices`.
>
> WDYT?
>
> Gary
>
I do not see any problems with t
After looking at the LayeredBloomFilter and the LayerManager and the way it
is intended to be used I found a couple of changes that we might want to
consider.
1) WrappedBloomFilter should not implement copy(), that should be left to
the wrapping implementation.
2) We change LayerManager to be a t
On Sat, 20 Apr 2024 at 11:36, Claude Warren wrote:
> The LayerdBloomFilter has a method find() that returns an array of ints
> that are the indices into the layer array. This is easily reproducible
> using an iterator.
> There is also get() method that takes an integer argument (an index of the
The LayerdBloomFilter has a method find() that returns an array of ints
that are the indices into the layer array. This is easily reproducible
using an iterator.
There is also get() method that takes an integer argument (an index of the
bloom filter) and returns the Bloom filter from the layer.
On Fri, 19 Apr 2024 at 08:26, Claude Warren wrote:
> While the Deque makes clear the idea of enqueueing and dequeueing the
> layers it does not have the method to natively traverse and extract entries
> from the middle of the queue. Nor would I expect it to. So I think the
> Deque does not acc
While the Deque makes clear the idea of enqueueing and dequeueing the
layers it does not have the method to natively traverse and extract entries
from the middle of the queue. Nor would I expect it to. So I think the
Deque does not accurately reflect how the collection of Bloom filters is
utiliz
Looks good to me.
Any opinions on changing the LayerManager to keep the layers in a Deque
rather than a LinkedList. I think it would only require a change to the
following method:
public final BloomFilter get(int depth)
Performance will be the same as the Deque can be a LinkedList. This is more
I have an open pull request to fix this problem. I could use another
review: https://github.com/apache/commons-collections/pull/476
On Tue, Apr 9, 2024 at 11:29 AM Claude Warren wrote:
> Alex,
>
> I like your solution. To answer your question. We create a BloomFilter
> that has a timestamp as
On Tue, Apr 9, 2024 at 11:09 PM Rodion Efremov wrote:
>
> Hello,
>
> Fair enough. However, why we have CursorableLinkedList and
> NodeCachingLinkedList around when my previous benchmarking showed that they
> are inferior compated to both TreeList and IndexedLinkedList?
We have a lot of things we
Hello,
Fair enough. However, why we have CursorableLinkedList and
NodeCachingLinkedList around when my previous benchmarking showed that they
are inferior compated to both TreeList and IndexedLinkedList?
Also, note that TreeList requires 3 references, 2 ints and 2 booleans per
node. IndexedLinked
Hm... how about all the existing "Linked" classes in the JRE:
java.util.LinkedList and so on.
Gary
On Tue, Apr 9, 2024 at 2:50 PM Elliotte Rusty Harold wrote:
>
> How does it compare to a simple array or ArrayList? Given modern CPU
> architecture and caching, I rarely encounter real world use ca
How does it compare to a simple array or ArrayList? Given modern CPU
architecture and caching, I rarely encounter real world use cases
where a linked list outperforms an array list, no matter what the data
structures textbooks say. Maybe on very large lists with a lot of
mutations, though last I ch
Alex,
I like your solution. To answer your question. We create a BloomFilter
that has a timestamp associated with it. When the timestamp is greater
than System.currentTimeMillis() the filter is removed. The custom cleanup
calls Cleanup.removeEmptyTarget().andThen()
I think that creating a clea
Hi Claude,
Q. What is your current clean-up filter, i.e.
the Consumer>? I assume you are using a custom one.
The current collections code only has 2 functional implementations. One
will remove the newest filter if it is empty, one will remove the oldest
filters until the size is below a limit. Si
+1 for M1 or beta1, thanks!
On Mon, 25 Mar 2024 at 14:12, Gary Gregory wrote:
> Hi All,
>
> 4.5.0 will contain a new package for Bloom Filters.
>
> Since this is a new package and is non-trivial, I propose we release a
> version called 4.5.0-M1 or 4.5.0-beta1 to let users try this out while
> gi
+1 on the M1 or beta1 release.
On Mon, Mar 25, 2024 at 2:12 PM Gary Gregory wrote:
> Hi All,
>
> 4.5.0 will contain a new package for Bloom Filters.
>
> Since this is a new package and is non-trivial, I propose we release a
> version called 4.5.0-M1 or 4.5.0-beta1 to let users try this out while
On Mon, 25 Mar 2024 at 13:12, Gary Gregory wrote:
> Hi All,
>
> 4.5.0 will contain a new package for Bloom Filters.
>
> Since this is a new package and is non-trivial, I propose we release a
> version called 4.5.0-M1 or 4.5.0-beta1 to let users try this out while
> giving us the change to make br
On Fri, 8 Sept 2023 at 13:46, Alex Herbert wrote:
> The problem then becomes how to support AbstractLinkedList and
> CursorableLinkedList. Currently collections4 will not be source
> compatible with JDK 21. Any downstream project that extends these
> classes will not be source compatible with J
On second thought, maybe it was too early and some consideration should be
given to whether and how Java 9+ modules (with which I do not profess
expertise) could address this issue without the baby/bathwater situation of
migrating the package of the whole library.
Matt
On Fri, Sep 8, 2023, 8:46 A
IMO the version bump is warranted/I'd select option 2 (although if it's not
too early for me I don't see these options as being mutually exclusive).
Matt
On Fri, Sep 8, 2023, 7:46 AM Alex Herbert wrote:
> JDK 21 has added these methods to java.util.List:
>
> default public void addFirst(E o)
>
Oh, BTW, please don't take this as a strong position against making the
code thread-safe. I am trying to understand the source of the desire for
change, and playing a bit of devil's advocate.
Gary
On Sun, Jul 2, 2023, 07:46 Gary Gregory wrote:
> The question I have is whether thread safety is
The question I have is whether thread safety is something you require here
or think is a feature people will be surprised is absent.
Sometimes extra bells and whistles make the code harder to maintain. Once
advertised as such, it may become quite hard to fix bugs or add new
features. I would consi
I do not think concurrent write usage is a general use case for the
filter. So this seems like a specialisation. If implementing it would
harm performance then I would be against it for the base
implementation.
For specialisation I would prefer the JDK pattern used for
Synchronized collections whi
Java 8.
Gary
On Wed, Jun 14, 2023, 12:42 Maxim Solodovnik wrote:
> On Wed, 14 Jun 2023 at 23:32, Efremov, Rodion
> wrote:
> >
> > Hello,
> >
> > What Java version Collections 4.5 is being built for?
> >
> > Best regards,
>
>
>
> --
> Best regards,
> Maxim
>
> --
Hello,
On Wed, 14 Jun 2023 at 23:32, Efremov, Rodion
wrote:
>
> Hello,
>
> What Java version Collections 4.5 is being built for?
the answer is here:
https://github.com/apache/commons-collections/blob/master/pom.xml#L532
:)
ps I believe this question is for user@ list :)
>
> Best regards,
--
On Wed, 14 Jun 2023 at 23:32, Efremov, Rodion
wrote:
>
> Hello,
>
> What Java version Collections 4.5 is being built for?
>
> Best regards,
--
Best regards,
Maxim
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
F
I have a work around but not having to convert from binary representation
to string would be handy. But it is not critical. I am also not sure that
the API is documented all that well. Perhaps I should open a low level
ticket that we can work on after 4.5 is released.
On Sun, Apr 23, 2023 at 9:
Claude,
Do you need the API to be made public?
Gary
On Mon, Apr 17, 2023 at 2:53 PM Gary Gregory wrote:
>
> I am guessing that only what is required to be public is as to both maximize
> our flexibility in maintenance and minimize the public API surface to support.
>
> We could make it public
I am guessing that only what is required to be public is as to both
maximize our flexibility in maintenance and minimize the public API surface
to support.
We could make it public if we are sure the API is documented and the code
isbas good as we can reasonably make it.
Gary
On Mon, Apr 17, 202
Thank you for the update Claude.
Gary
On Thu, Mar 23, 2023, 03:57 Claude Warren, Jr
wrote:
> Gary,
>
> The Bloom filter package is functionally complete and ready for prime
> time. As to beta, I have used it in several research projects and am
> proposing using it in an in-house project at wor
Gary,
The Bloom filter package is functionally complete and ready for prime
time. As to beta, I have used it in several research projects and am
proposing using it in an in-house project at work. I don't know what the
standard process is for commons, so I leave it to your discretion.
Claude
On
rodde,
We are volunteers here, each with limited time and various interests, as
such, it is not unusual for requests to take some time to percolate
through. You'll also have noticed that Collections is already quite large
and complex, so that IMO adding more classes must be done carefully, and
tha
Hello community,
I hereby decided to mail the list since my last message did not produce any
response.
Question: should I give up on the process of inclusion of my
IndexedLinkedList to the [collections]?
Best regards,
rodde
la 16.7.2022 klo 6.17 Rodion Efremov kirjoitti:
> Hello,
>
> I have b
Hi Gary,
I can’t follow the source code of the 2 DS you mentioned. Could you,
please, explain how, say, TreeSet can be used for O(log N) select/rank?
I, however, noticed that JDK Sets rely internally on corresponding Maps
thus wasting a reference per element in a Set.
Best regards,
rodde
ke 13
Hi Rodde,
Why would a user use this implementation instead of a
ConcurrentSkipListSet or a TreeSet?
IMO, we need to consider users first, IOW, what is the use case?
Gary
On Wed, Jul 13, 2022 at 1:48 AM Rodion Efremov wrote:
>
> Hello,
>
> I have an order statistic tree implemented [1]. I am aw
Hi community,
I have created a PR: https://github.com/apache/commons-collections/pull/321
Also, I signed the ASF ICLA and sent it to secret...@apache.org
Best regards,
rodde
On Wed, Jul 13, 2022 at 6:18 AM Rodion Efremov wrote:
> Hi Matt and community,
>
> Answering the first question: yes, it
Hi Matt and community,
Answering the first question: yes, it’s entirely my work and I don’t expect
it to appear in CS literature since the idea behind it and the
implementation are rather simple and straightforward, albeit with many
corner cases.
About OCA: is Postal Address and Country mandatory
Is this algorithm and its implementation entirely your own work? If
so, first of all, that's awesome! Thanks for the contribution! Second,
go ahead and update the license. You'll also need to have a
Contributor License Agreement [1] on file with the ASF. I think that
covers it. If I'm forgetting so
Hello,
Should I change the license from MIT to Apache License 2.0 before PRing it?
Best regards,
rodde
ti 12.7.2022 klo 22.49 Matt Juntunen kirjoitti:
> Thanks! We should be ready for you to put together a PR for this. Have
> we cleared any licensing or copyright issues on this algorithm? I
>
Thanks! We should be ready for you to put together a PR for this. Have
we cleared any licensing or copyright issues on this algorithm? I
can't recall.
Regards,
Matt J
On Tue, Jul 12, 2022 at 2:06 AM Rodion Efremov wrote:
>
> Hello,
>
> I have added the benchmark data (both my and Matt's) to the
Hello,
I have added the benchmark data (both my and Matt's) to the JIRA issue.
Please see the https://issues.apache.org/jira/browse/COLLECTIONS-797
Best regards,
rodde
On Tue, Jul 12, 2022 at 2:34 AM Alex Herbert
wrote:
> On Mon, 11 Jul 2022 at 17:16, Gilles Sadowski
> wrote:
>
> > Le lun. 1
On Mon, 11 Jul 2022 at 17:16, Gilles Sadowski wrote:
> Le lun. 11 juil. 2022 à 09:51, Rodion Efremov a
> écrit :
> >
> > Hi Gilles,
> >
> > Would it be sufficient to include .txt files for the tables and the .ods
> > file provided by Matt?
>
> It would be more handy for readers that tables are i
1 - 100 of 761 matches
Mail list logo
