On Thu, Mar 31, 2011 at 12:36 PM, Robert Kern <robert.kern@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. (If we have to choose a single-letter code, I would vote for 'a' for hAlf and 'u' for qUad.) 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.