The compact ASCII format is a block of index/value tuples for the
non-zero entries:
{ (index1 value1) (index2 value2) (index3 value3) }
For PackedList<1>, and thus PackedBoolList, the compact ASCII format is
a block of indices for the non-zero entries:
{ index1 index2 index3 }
Thus either of the following could be used - for PackedList<2>:
- a list of all values:
16(0 3 0 2 0 0 3 1 0 0 0 0 0 0 0 1)
- a block of index/value tuples:
{(1 3) (3 2) (7 3) (8 1) (15 1)}
For PackedList<1> and PackedBoolList, either of the following could be
used:
- a list of all values, using any valid bool representation:
16(0 1 0 true 0 0 t 1 0 n n 0 0 0 0 yes)
- a block of the indices for non-zero entries:
{1 3 7 8 15}
- now that I re-examined the code, the note in commit 51fd6327a6
can be mostly ignored
PackedList isMaster(nPoints, 1u);
is not really inefficient at all, since the '1u' is packed into
32/64-bits before the subsequent assignment and doesn't involve
shifts/masking for each index
The same misinformation applies to the PackedList(size, 0u) form.
It isn't much slower at all.
Nonetheless, add bool specialization so that it is a simple assign.
- use shift-right instead of shift-left formulation to avoid wrong behaviour
with non-optimized compilation when the packed items fit exactly in the
available number of bits.
- compare iteratorBase == iteratorBase by value, not position
thus this works
list[a] == list[b] ...
- compare iterator == iteratorBase and const_iterator == iteratorBase
by position, not value. The inheritance rules means that this works:
iter == list.end() ...
this will compare positions:
iter == list[5];
Of course, this will still compare values:
*iter == list[5];
- OSspecific: chmod() -> chMod(), even although it's not used anywhere
- ListOps get subset() and inplaceSubset() templated on BoolListType
- added UList<bool>::operator[](..) const specialization.
Returns false (actually pTraits<bool>::zero) for out-of-range elements.
This lets us use List<bool> with lazy evaluation and no noticeable
change in performance.
- use rcIndex() and fcIndex() wherever possible.
Could check if branching or modulus is faster for fcIndex().
- UList and FixedList get 'const T* cdata() const' and 'T* data()' members.
Similar to the STL front() and std::string::data() methods, they return a
pointer to the first element without needing to write '&myList[0]', recast
begin() or violate const-ness.
- moving back to original flat addressing in iterators means there is no
performance issue with using lazy evaluation
- set() method now has ~0 for a default value.
We can thus simply write 'set(i) to trun on all of the bits.
This means we can use it just like labelHashSet::set(i)
- added flip() method for inverting bits. I don't know where we might need
it, but the STL has it so we might as well too.
- dropped auto-vivification for now (performance issue), but reworked to
allow easy reinstatement
- derived both iterator and const_iterator from iteratorBase and use
iteratorBase as our proxy for non-const access to the list elements.
This allows properly chaining assignments:
list[1] = list[2];
list[1] = list[2] = 10;
- assigning iterators from iteratorBase or other iterators works:
iterator iter = list[20];
- made template parameter nBits=1 the default
- the bit counting is relatively fast:
under 0.2 seconds for 1M bits counted 1000 times
- trim()'ing the final zero elements tested for a few cases,
but might need more attention
- added Mattijs' speed tests
- optimized resize() and assignment operators to avoid set() method
- add const_iterator and re-did the proxy handling.
Reading/writing by looping across iterators is still somewhat slow, but
might be acceptable.
- eliminated previous PackedBitRef class, the iterator does all of that and
can also be used to (forward) traverse the list
- no const_iterator yet
- Note that PackedList is also a bit like DynamicList in terms of storage
management and the append() method. Since the underlying storage in
integer, any auto-vivified elements will also flood-fill the gaps with
zero.
