Bitarrays in the age of 64bit

[9il]

On Friday, 3 April 2020 at 07:31:52 UTC, Dominikus Dittes Scherkl 
wrote:
> It was said that implementing bitarrays is complicated, because 
> of the indexing.
>
> Has anybody ever considered to use bit-pointers?
> Nobody really uses the full address range that 64bit pointers 
> have - in fact some hardware internally still uses 48bit or 
> 56bit address-registers, so instead adding three lower address 
> bits would not cost a lot (just forward bit 3..58 to the 
> register instead of bit 0..55).
> This would also allow for implementing 2bit-types (one that I 
> really would appreciate, because it can represent sign values, 
> providing -1, 0, 1 and NaN - which is necessary as a comparison 
> result for non-ordered values), and 4bit-types (so called 
> nibbles).
> And with bit-pointers of course implementing arrays of boolean, 
> sign, nibbles or even odd-length types would be straight 
> forward. All the strange side-effects of byte clustering would 
> vanish.
>
> Just an idea.

Sure.

1. GC allocated bitarrays.
http://mir-algorithm.libmir.org/mir_ndslice_allocation.html#.bitSlice

2. Ref-counted bitarrays
http://mir-algorithm.libmir.org/mir_ndslice_allocation.html#.bitRcslice

2. Bit array on top of a user-provided integer array.
http://mir-algorithm.libmir.org/mir_ndslice_topology.html#.bitwise

3. Packed integer (1-65 bits) arrays on top of a user-provided 
integer array.
http://mir-algorithm.libmir.org/mir_ndslice_topology.html#.bitpack

4. Packed bytes bytegroup arrays on top of a user-provided 
integer array.
http://mir-algorithm.libmir.org/mir_ndslice_topology.html#.bitpack

All of the provided API has random access range primitives, as 
well the types are ndslices. Thus mean you can have construct for 
example a bitmatrix.


Have a good day :)