[Python-ideas] Adding a half-float (16-bit) type to PEP 3118 (and possibly the struct module?)

[Robert Kern]

On 3/31/11 12:58 PM, Alexander Belopolsky wrote:
> On Thu, Mar 31, 2011 at 12:36 PM, Robert Kern<robert.kern at gmail.com>  wrote:
> ..
>> The proposed letter code is 'e', as used in numpy. I'm not sure of the logic
>> that went behind the choice, except perhaps that 'e' is near 'd' and 'f'.
>
> So it is  'e' for half, 'f' for single and 'd' for double.  Given that
> in English alphabet the order is d, e, f, I find this choice rather
> unintuitive.
>
>> It's not too late to change, though. I don't know of any other group that
>> has decided on such any kind of letter code for half-floats.
>>
>
> There is a language, Q, that uses "e" for single-precision floats.
> They call C-float "real" and C-double "float".  See
> <http://www.kx.com/q/d/primer.htm>.  Codes "e" for binary32 and "f"
> for binary64 make some sense alphabetically, but would suggest "d" for
> binary16, which would neither work for Python nor for Q because "d" is
> double in Python and date in Q.
>
> Note that IEEE 754-2008 also defines a binary128, quadruple precision
> format.  If we keep assigning single letter codes to datatypes,
> struct/buffer format will soon resemble strftime with every letter of
> English alphabet having some (often non-obvious) meaning.

Oh, we're well down that path. :-)

> (If we have
> to choose a single-letter code, I would vote for 'a' for hAlf and 'u'
> for qUad.)

'u' is already reserved in PEP 3118, and 'a' is already used in numpy, though 
not in the PEP 3118 interface implementation.

> I would rather see some syntax that would allow multi-character type
> specifications.  For example, {binary16} for half-floats and
> {binary128} for quadruple precision floats.  This syntax may allow for
> support 3rd party type registry and private extensions.

PEP 3118 does define a parametric 't' type: 16t would be a 16-bit field with 
undefined internal format. Elsewhere in the thread I suggested an extension to 
this add a freeform name to this type to allow 3rd parties agree on new types 
without needing changes to PEP 3118 or needing more single-letter codes. E.g.

   16t{halffloat} -> IEEE 754-2008 half-float
   128t{quadfloat} -> IEEE 754-2008 quad-float
   96t{80bitfloat} -> 80-bit extended precision float stored in 96 bits

etc.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco