This library is undergoing some severe redesign. Once I stopped looking
at it as a 'set of small integers' and started looking at it as an 'array
of bits', the requirements of the library shifted in my mind. For
example, it should be possible to use the Bitvector library to implement
elliptic curve cryptography (maybe not in the most efficient manner, but
still). So routines like sub (returning a subsection of the array) and
rotates and shifts also need to be added. Also, to implement EC crypto,
you need a precise bitlength- no more rounding up to the next whole int.
I was hopping to have something to distribute today, but it didn't happen.
On Sun, 16 Mar 2003, Nicolas Cannasse wrote:
> - the functions and types are all started with bitset_ ( C like notation,
> without namespace )
> instead of doing :
> open BitSet;;
> let b = bitset_empty 10 in
> bitset_add b 1;
> it's better to use the module system :
> let b = BitSet.empty 10 in
> BitSet.add b 1;
> this is more like 'ocaml style'
OK. Your first example is why I named things the way I did (well, that
and old, bad, C habits).
> - the functions add_list and remove_list are useless, since :
> bitset_add_list b l == List.iter (bitset_add b) l
> ( perhaps it's convenient for you to have it available, but we
> can't add a "_list version of all functions for all the modules we're
> writting :)
Point. There isn't even a performance advantage :-)
> - about the design itself, it looks good, but perhaps it would be good to
> create an empty bitset with a default size (that's what you're doing), and
> then having it growing automaticly when needed ( right now you're relying on
> array bounds check, you need to do checks by hand - if the user turn them
> off - and raise a BitSet specific exception )
I'm actually moving in the other direction, towards have specific bit
sizes. Bitarray might be a better name. The reason for having specific
sizes (in bits) is to have defined behavior on shifts. Does doing a shift
left expand the bit array?
I'll add an expand function, tho.
> - I don't agree with your compare and equals implementations, since I would
> say the bitsets  and [0 ; 0; 0 ] are equals !
Comparing bit arrays with different lengths is a tricky thing to define.
> - wouldn't it better to replace bitset_first_member + bitset_next_member +
> bitset_to_list by two functions BitSet.map and BitSet.iter that are more in
> the functionnal way of doing things ?
Probably. Consider it done.
> - a new function toggle for bit toogle ( 0 -> 1 || 1 -> 0 )
Already done. Although I'm calling it negate. So the three fundemental
opertations are set, clear, and negate. I'm going to drop the lists, but
add set/clear/negate range functions (because these can be signifigantly
speed up over calling the fundamental functions).
I'll get a new .mli together and (hopefully) post it tomorrow.