<div dir="ltr"><div>Here is a snapshot of the hierarchy I used in VW several years ago.</div><div><br></div><div><div><img src="cid:ii_k9sv52b20" alt="Capture d’écran 2020-05-04 à 21.11.17.png" width="371" height="488"><br></div><div>It is in cincom store SYSEXT-RawArray</div><div>Unlike squeak, I have used single-byte elements uniformly.</div><div>VW only provide 8(byte) and 16(word) bits elements, so there is not much to gain in complexifying the interface.<br></div><div>I did use Float and Double rather than Float32 and Float64 to fit what is in a VW image. For the rest, just int and uint...</div><div>I might re-create a similar hierarchy in STEM, but I would prefer to see a good one in the base image. That's useful for everyone. <br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 4 mai 2020 à 09:29, K K Subbu <<a href="mailto:kksubbu.ml@gmail.com">kksubbu.ml@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 03/05/20 7:22 pm, Nicolas Cellier wrote:<br>
> More than often, the data transfer can handle offset and stride via a <br>
> BitBlt tricks (unless we have an odd layout).<br>
> This enables extracting a single "column" or bloc of data from a big <br>
> file with a single copy.<br>
> I may need to extend BitBlt to cope with all the available bit-widths, <br>
> not just 8 (byte) or 32 (word) though.<br>
> <br>
> Also, those formats offer packed and contiguous memory layout which is <br>
> an advantage too when dealing with large chunks of data.<br>
> Especially if we have vectorized primitives operating on the arrays.<br>
Ha! Now I get it. But FixedWidthBitArray is too primitive a type for <br>
this purpose. It would expose host's word size to class methods instead <br>
of encapsulating it in plugins.<br>
<br>
I would apply recursive decomposition and use something like <br>
PackedVector(stride, length) on the lines of a Form(width, height). <br>
PackedVectors may decomposed into smaller packedvectors recursively <br>
until they are small enough for ImmediateClass (i.e. stride = host's <br>
word size). This would be well-suited to speed up through arch-specific <br>
plugins.<br>
<br>
When loading a packedvector from an image on a smaller word size host, <br>
ImmediateClass elements could be converted into packedvectors. The <br>
reverse could happen on larger word size hosts with a one-time <br>
conversion cost.<br>
<br>
Regards .. Subbu<br>
<br>
</blockquote></div>