<p dir="ltr">On 4 Mar 2013 23:21, "Jaime Fernández del Río" <<a href="mailto:jaime.frio@gmail.com">jaime.frio@gmail.com</a>> wrote:<br>
><br>
> On Mon, Mar 4, 2013 at 2:29 PM, Todd <<a href="mailto:toddrjen@gmail.com">toddrjen@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> 5. Currently dtypes are limited to a set of fixed types, or combinations of these types.  You can't have, say, a 48 bit float or a 1-bit bool.  This project would be to allow users to create entirely new, non-standard dtypes based on simple rules, such as specifying the length of the sign, length of the exponent, and length of the mantissa for a custom floating-point number.  Hopefully this would mostly be used for reading in non-standard data and not used that often, but for some situations it could be useful for storing data too (such as large amounts of boolean data, or genetic code which can be stored in 2 bits and is often very large).<br>

><br>
><br>
> I second this general idea. Simply having a pair of packbits/unpackbits functions that could work with 2 and 4 bit uints would make my life easier. If it were possible to have an array of dtype 'uint4' that used half the space of a 'uint8', but could have ufuncs an the like ran on it, it would be pure bliss. Not that I'm complaining, but a man can dream...</p>

<p dir="ltr">This would be quite difficult, since it would require reworking the guts of the ndarray data structure to store strides and buffer offsets in bits rather than bytes, and probably with endianness handling too. Indexing is all done at the ndarray buffer-of-bytes layer, without any involvement of the dtype.</p>

<p dir="ltr">Consider:</p>
<p dir="ltr">a = zeros(10, dtype=uint4)<br>
b = a[1::3]</p>
<p dir="ltr">Now b is a view onto a discontiguous set of half-bytes within a...</p>
<p dir="ltr">You could have a dtype that represented several uint4s that together added up to an integral number of bytes, sort of like a structured dtype. Or packbits()/unpackbits(), like you say.</p>
<p dir="ltr">-n<br>
</p>