[Numpy-discussion] Does float16 exist?

[David Cournapeau]

Charles R Harris wrote:
>
>
> On Jan 8, 2008 8:42 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp 
> <mailto:david@ar.media.kyoto-u.ac.jp>> wrote:
>
>     Charles R Harris wrote:
>     >
>     >
>     > On Jan 8, 2008 6:49 PM, Eric Firing <efiring@hawaii.edu
>     <mailto:efiring@hawaii.edu>
>     > <mailto: efiring@hawaii.edu <mailto:efiring@hawaii.edu>>> wrote:
>     >
>     >     Bill Baxter wrote:
>     >     > On Jan 9, 2008 9:18 AM, Charles R Harris
>     >     <charlesr.harris@gmail.com
>     <mailto:charlesr.harris@gmail.com>
>     <mailto:charlesr.harris@gmail.com
>     <mailto:charlesr.harris@gmail.com>>> wrote:
>     >     >> On Jan 8, 2008 5:01 PM, Bill Baxter < wbaxter@gmail.com
>     <mailto:wbaxter@gmail.com>
>     >     <mailto:wbaxter@gmail.com <mailto:wbaxter@gmail.com>>> wrote:
>     >     >>> On Jan 9, 2008 8:03 AM, Charles R Harris
>     >     < charlesr.harris@gmail.com
>     <mailto:charlesr.harris@gmail.com>
>     <mailto:charlesr.harris@gmail.com <mailto:charlesr.harris@gmail.com>>>
>     >     >> wrote:
>     >     >>>> On Jan 8, 2008 1:58 PM, Bill Baxter < wbaxter@gmail.com
>     <mailto:wbaxter@gmail.com>
>     >     <mailto:wbaxter@gmail.com <mailto:wbaxter@gmail.com>>> wrote:
>     >     >>>>> If you're really going to try to do it, Charles,
>     there's an
>     >     >>>>> implementation of float16 in the OpenEXR toolkit.
>     >     >>>>> http://www.openexr.com/
>     >     >>>>>
>     >     >>>>> Or more precisely it's in the files in the Half/ directory
>     >     of this:
>     >     >>>>>
>     >     >>
>     >    
>     http://download.savannah.nongnu.org/releases/openexr/ilmbase-1.0.1.tar.gz
>     >     >>>>> I don't know if it's IEEE conformant or not (especially
>     >     w.r.t. NaN's
>     >     >>>>> and such) but it should be a good start.  The code
>     seems to
>     >     be well
>     >     >>>>> documented.
>     >     >>>> The license looks good, essentially BSD. The code is
>     all C++,
>     >     which is
>     >     >> the
>     >     >>>> obvious way to go for this sort of thing, and I would
>     like to
>     >     stick with
>     >     >> it,
>     >     >>>> but that could lead to build/compatibility problems. I
>     think
>     >     NumPy
>     >     >> itself
>     >     >>>> should really be in C++.  Maybe scons can help with the
>     build.
>     >     >>> Yeh, I was just thinking you'd rip out and C-ify the main
>     >     algorithms
>     >     >>> rather than trying to wrap it as-is.
>     >     >> I'd rather not C-ify the thing, I'd rather C++-ify parts of
>     >     NumPy. I note
>     >     >> that MatPlotLab uses C++, so some of the problems must have
>     >     been solved.
>     >
>     >     A big chunk of C++ in matplotlib has just been replaced, largely
>     >     because
>     >     it was so hard to understand and extend for everyone but its
>     author.
>     >     There is still C++ code as well as C code in mpl.  Personally, I
>     >     prefer
>     >     the C.
>     >
>     >     >
>     >     > If you think that's easier then go for it.
>     >
>     >     The opinion that C++ would improve numpy is not universal,
>     and has
>     >     been
>     >     discussed.
>     >
>     >     http://article.gmane.org/gmane.comp.python.numeric.general/13244
>     >     <
>     http://article.gmane.org/gmane.comp.python.numeric.general/13244>
>     >
>     >
>     > Ah, the trick to interfacing C to C++ is to derive the C++ classes
>     > from the numpy structures and keep the function pointers. Then
>     all the
>     > offsets would work. I would think the main advantage of C++ would be
>     > in arithmetic operator overloading and using template classes while
>     > carefully restricting such things to numbers. Mostly, I would
>     use C++
>     > inline class methods as shorthand that would compile to what the C
>     > approach would do. I suppose we could write a python
>     preprocessor that
>     > would do essentially the same thing; C++ started that way.
>     Are you suggesting to write a compiler to be able to use operator
>     overloading ? :) More seriously, the problem of C/C++ is not only at
>     source level but also at binary level.
>
>
> As  I tried to say, there are ways of dealing with the compatibility 
> problems at the binary level.
Sorry, I was not precise enough: I talked at the binary level wrt 
compilers. C++ object code compiled by different compilers are not 
always compatible, without talking about known linking problems. I am 
afraid this would quickly become a headache to support, specially when 
you start using external C++ libraries (if the float16 library is BSD, 
the source code could be incorporated directly into numpy, though, but 
then compiling the code may be an issue wrt distutils: I don't know how 
flexible C++ support is in distutils).

This is such a big issue (ABI issues) with C++ that some open source 
projects incorporate the libraries they used in their source tree.

David