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

[Robert Kern]

On 3/30/11 3:05 PM, Mark Dickinson wrote:
> On Wed, Mar 30, 2011 at 8:53 PM, Robert Kern<robert.kern at gmail.com>  wrote:
>>
>> Like Ellipsis, multidimensional extended slicing, complex numbers, and
>> non-bool rich comparisons? :-)
>
> Indeed!
>
> (BTW, I didn't know that Python's complex numbers were NumPy
> influenced:  thanks for that.)
>
>> capably handled by the old buffer protocol. Still, it's worth defining the
>> standard to allow third parties to communicate the full spectrum of things
>> they want to tell each other.
>
> Yes, that makes sense.  It's not very clear to me what the scope of
> the Python additions would be.

As far as I can tell (and I've really only looked at PEP 3118 in any detail 
today), only producers and consumers of the buffer actually care about the 
contents of the format string, and consumers are free to reject format codes 
that they don't understand. I think you can just treat the section of the PEP 
defining the format codes as informational, much like the DB-API only a little 
more rigorous. Adding support for it to the struct module is a good bonus.

As a digression, it would be great if the format codes were defined in an 
extensible fashion, such that two agreeing third parties could talk to each 
other using their own format codes without having to modify the PEP. It already 
contains a little bit of this with the 't' code. If you could add a 
distinguishing name as well (besides the ':name:' syntax, which is reserved for 
adding names to fields, not types), then numpy and Cython could simply agree 
that '16t{half}', for example, meant a half-float without having to wait for the 
PEP to be modified.

> [OT]: How is NumPy's float16 type implemented?  Is it clever enough to
> do correct rounding for all basic arithmetic operations, or does it
> suffer from the double-rounding problems that you'd get from (convert
> operands to float64; do op in float64; round back to float16)?

We do the latter, I'm afraid. Except with float32 instead of float64.

https://github.com/numpy/numpy/blob/master/numpy/core/src/umath/loops.c.src#L1443
https://github.com/numpy/numpy/blob/master/numpy/core/src/npymath/halffloat.c

-- 
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