Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: intersection, union, and difference with the tail of another bitmap #591

Open
tudor opened this issue Feb 9, 2024 · 4 comments

Comments

@tudor
Copy link
Contributor

tudor commented Feb 9, 2024

I have two bitmaps a and b, I find one point inside b (say using an iterator), and then I want to intersect / union / compute the set difference of a with the tail of b after that point.

That is, I'd like the equivalent of

b.removeRange(0, x);
a &= b;

without the overhead of mutating b (the memmove from array containers shows up meaningfully in my CPU profile).

Roaring iterators already have all the information needed to implement this efficiently, and I sometimes need to walk through a to find the right spot (it's not as easy as rank(x)) so I'd prefer this:

auto it = b.begin();
it.move(x);
a.intersectTail(it);
// intersectRange(it, b.end()) would be nice too, but that means you have to be able to 
// deal with partial containers at both ends instead of just at the beginning so it's a bit
// harder to implement

Do you think this is worth implementing?

Thanks,
-Tudor.

@tudor tudor changed the title Feature request: intersect and difference with the tail of another bitmap Feature request: intersect, union, and difference with the tail of another bitmap Feb 9, 2024
@tudor tudor changed the title Feature request: intersect, union, and difference with the tail of another bitmap Feature request: intersection, union, and difference with the tail of another bitmap Feb 9, 2024
@lemire
Copy link
Member

lemire commented Feb 9, 2024

I think we could support functions such as...

  • roaring_bitmap_and_inplace_range(a, b, start, end)
  • roaring_bitmap_andnot_inplace_range(a, b, start, end)
  • roaring_bitmap_or_inplace_range(a, b, start, end)
  • roaring_bitmap_xor_inplace_range(a, b, start, end)

would be nice too, but that means you have to be able to deal with partial containers at both ends instead of just at the beginning so it's a bit harder to implement

Is it? I suspect that there is a non-trivial fixed cost involved in starting to code this functionality, but the added complexity of handling both ends is probably not nearly 2x. It may take 15% longer, I would estimate. Of course, the result would be far neater.

@tudor
Copy link
Contributor Author

tudor commented Feb 9, 2024

rages in off-by-one errors

@tudor
Copy link
Contributor Author

tudor commented Feb 9, 2024

Also note that we'd have to implement out-of-place versions as well (at least at the container level), as in-place isn't really in-place for COW bitmaps.

@lemire
Copy link
Member

lemire commented Feb 9, 2024

Right. So it is a non-trivial amount of work, for sure!!! My argument is that once you get started, it is not much more effort to do a symmetrical work.

It can't be done in a minutes, no matter what.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants