Re: RawBitsArray

On 22/05/20 12:21 pm, Nicolas Cellier wrote:
> I should not have redefined bytesPerElement, because most of the time,
> super will behave as intended

moving to bitsPerElement goes well with raw bits model. Perhaps, we
could throw in a padBitsPerElement. bytesPerElement would then become a
convenience method:

bytesPerElement
        ^(self bitsPerElement + self padBitsPerElement) / 8

The only other time the VM needs to deal with bytes is during endian
swap. We could add beEndian: method to adjust bytes within an element to
match #littleEndian (most processors) or #bigEndian (IP network) order
while sending/receiving a raw object to/from an external source with a
different endian order (image file, network packet etc.)

> We could redefine a slotsPerElement, defaulting to 1, and redefined in
> exceptional cases (like a double complex array would consume 2 slots of
> 8 bytes per element).

This presumes that elements have a slotted structure. I would prefer to
keep raw bits.


> Concerning case of 10 or 12 bits per element, would you store them in
> compact form (all bits concatenated without padding), or rather with
> appropriate padding (in which case we would use a DoubleBytesArray)?

Samples are mostly stored and copied around, so padding would be counter
productive. Extracting them into aligned words wouldn't be
computationally expensive these days.

Regards .. Subbu