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