Fixed sized (non resizable) bitvector. Upon instance construction a bitvector is told to hold a fixed number of bits - it's size. The size can be any number (need not be a power of 2 or so). The bits of a
BitVector are indexed by nonnegative integers. Any attempt to access a bit at an
index<0 || index>=size() will throw an
IndexOutOfBoundsException.
Individual indexed bits can be examined, set, or cleared. Subranges can quickly be extracted, copied and replaced. Quick iteration over subranges is provided by optimized internal iterators (forEach() methods). One BitVector
may be used to modify the contents of another BitVector
through logical AND, OR, XOR and other similar operations.
All operations consider the bits 0..size()-1 and nothing else. Operations involving two bitvectors (like AND, OR, XOR, etc.) will throw an IllegalArgumentException if the secondary bit vector has a size smaller than the receiver.
A BitVector is never automatically resized, but it can manually be grown or shrinked via setSize(...).
For use cases that need to store several bits per information entity, quick accessors are provided that interpret subranges as 64 bit long integers.
Why this class? Fist, boolean[] take one byte per stored bit. This class takes one bit per stored bit. Second, many applications find the semantics of java.util.BitSet not particularly helpful for their needs. Third, operations working on all bits of a bitvector are extremely quick. For example, on NT, Pentium Pro 200 Mhz, SunJDK1.2.2, java -classic, for two bitvectors A,B (both much larger than processor cache), the following results are obtained.
- A.and(B) i.e. A=A & B --> runs at about 35 MB/sec
- A.cardinality(), i.e. determining the selectivity, the number of bits in state "true" --> runs at about 80 MB/sec
- Similar performance for or, xor, andNot, not, copy, replace, partFromTo, indexOf, clear etc.
If you need extremely quick access to individual bits: Although getting and setting individual bits with methods
get(...),
set(...) and
put(...)is quick, it is even quicker (
but not safe) to use
getQuick(...) and
putQuick(...) or even
QuickBitVector.
Note that this implementation is not synchronized.
@author wolfgang.hoschek@cern.ch
@version 1.01, 11/10/99
@see QuickBitVector
@see BitMatrix
@see java.util.BitSet