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 <cla...@xenei.com> 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 it > the method flatten(). But this is a can of worms I would like to keep > sealed for a bit longer. > > Claude > > On Sat 5 Oct 2024, 20:44 Gary Gregory, <garydgreg...@gmail.com> wrote: > > > On Fri, Oct 4, 2024 at 1:30 PM Alex Herbert <alex.d.herb...@gmail.com> > > 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. Whatever choice must be documented. > > > > > > > The code now throws an exception instead of returning null. I also > updated > > the Javadoc. > > > > > > > > > > Note we do not currently check if the Shapes are all equal when > > > creating the BloomFilterExtractor. This is not essential but when > > > merging two Bloom filters in flatten an error will be thrown if the > > > filters are not compatible. I say it is not essential as the > > > functionality of the BloomFilterExtract in processBloomFilters does > > > not mandate any prerequisites on the Predicate for the filters. So for > > > example you could have many filters of different sizes and a predicate > > > that tests if they all contain a given IndexProducer. > > > > > > > I'll leave that deeper topic alone for now, and for you and Claude to > > further discuss if warranted. > > > > TY, > > Gary > > > > > > > > > > Alex > > > > > > On Fri, 4 Oct 2024 at 18:02, Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > > > > > OK, but how do you create an empty filter? > > > > > > > > Gary > > > > > > > > On Fri, Oct 4, 2024, 12:54 PM Claude Warren <cla...@xenei.com> > wrote: > > > > > > > > > I think that it should return an empty filter as the javadoc says > > > > > > > > > > > > > > > On Fri 4 Oct 2024, 15:53 Gary D. Gregory, <ggreg...@apache.org> > > 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.commons.collections4.bloomfilter.BloomFilterExtractor.flatten() > > > > > > > > > > > > > > is documented as always returning a BloomFilter: > > > > > > > > > > > > > > /** > > > > > > > * Create a standard (non-layered) Bloom filter by merging > > all > > > of > > > > > > the layers. If > > > > > > > * the filter is empty this method will return an empty > Bloom > > > > > filter. > > > > > > > * > > > > > > > * @return the merged bloom filter. > > > > > > > */ > > > > > > > > > > > > > > But that's not how it's coded, it can return null, the simplest > > > > > > reproducer is: > > > > > > > > > > > > > > BloomFilterExtractor.fromBloomFilterArray(new > > > BloomFilter[0]).flatten() > > > > > > -> null > > > > > > > > > > > > > > Should we: > > > > > > > > > > > > > > - Change the Javadoc > > > > > > > - Change the code > > > > > > > -- How should this code be changed? > > > > > > > -- Should the method be moved to BloomFilter and use "this" as > > the > > > > > > default filter? > > > > > > > > > > > > > > TY, > > > > > > > Gary > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > >
