You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Roaring bitmaps are not necessarily "bitmaps" but are optimized to not be too big for some cases. What you seem to want is to know the number of missing values in a certain range. You can probably use the range_cardinality(&self, range: impl Range) -> u64 function and substract this number from the range size itself.
Thanks, but unfortunately range_cardinality doesn't cover my use case.
That's because range_cardinality returns the count of ones or zeros even if they aren't consecutive.
The function Roaring::consecutive(&self, bit, range) would stop counting after finding the first bitflip.
I know roaring bitmaps may be stored compressed with run length encoding. In fact, consecutive could take advantage of this compression to execute faster.
If the roaring bitmap contains RLE compressed ones as (start, count), and the user asks for consecutive(1, start..) the query can return instantly with value count.
I think this should be implemented inside the library, because as a user I don't have access to the internal representation of the bitmap, so I cannot optimize the query.
That's because range_cardinality returns the count of ones or zeros even if they aren't consecutive.
Ho! I see. That's indeed not the same.
I think this should be implemented inside the library, because as a user I don't have access to the internal representation of the bitmap, so I cannot optimize the query.
For now you could try implementing this outside of the library by using the iterator. But happy to review a PR if you think performances matter.
roaring.consecutive(bit: 0, range: 13..)
could return the number of consecutive zeroes from bit 13.The text was updated successfully, but these errors were encountered: