difficult ergonomics of the API

[KonradHoeffner]

I appreciate that this library is as optimized and fast as it is and I'm currently testing out swapping sucds for it because I want 32 Bit support anyways, but the refactoring has been very painful so far.

Conversion between the different types like &[u64] -> BitVectorMut -> BitVector -> RSNarrow takes multiple steps and the API of each of those types is different even for very similar or the same functionality (see for example #7), sometimes you even lose functionality by going "up the ladder".
After you finally convert everything, it is near impossible to get the original data back out without going through some absurd hoops like iterating over each bit individually.

As I didn't see contribution guidelines, I would like to ask here if help getting this improved is welcome.
If yes, I would be open to create a few pull requests to improve this situation.

[rossanoventurini]

Hi @KonradHoeffner,
Any help in improving this is very welcome. Please note that I began implementing this library approximately three years ago as part of a research project, with the goal of experimenting with ideas to accelerate the Wavelet Tree and eventually publishing a research paper.

We didn’t spend much time on the API design and, since I am currently not using QWT in any of my projects, I haven’t felt enough pressure (and not enough frustration) to significantly improve it 🙂

Additionally, binary and quad vectors were implemented for internal use in the QWT implementation. The intent was not to provide a fully featured or easy-to-use library for succinct data structures.

Any improvement introduced is greatly appreciated.

[KonradHoeffner]

Fair enough! Then I will try to add a few PRs improving the ergonomics in the next few weeks.
I've used several implementations of succinct data structures in the past and I always prefer to use a single library because that makes development and maintenance easier, improves interoperability (and thus potentially performance when converting to and from different structures) and reduces binary size, which is why a library like yours that has state of the art algorithms and performance would be my top choice if it also handles the "boring" stuff like regular bit vectors and so on.
Also some of them only support 64 Bit architectures and as we try to add 32 Bit support for web assembly that would be a further incentive to fully switch to this one.

[KonradHoeffner]

To be more constructive, I will try to organize and track these ergonomic issues a bit.
Since the original post, three issues have already been resolved:

• count_ones vs n_ones #7
• convert RSNarrow back to BitVector #8
• Construct BitVector from already-packed data #9

There is also issue #15 about renaming RSNarrow to Rank9 and RSWide to FlatRank but I will not track that here because I don't know what the widely accepted naming conventions are for those.

[KonradHoeffner]

As there has been lots of progress with the API ergonomics, I wonder what everyone's thoughts are of the current state, are there still open problems? I'm currently on vacation but will try to look at it as well at the end of July.