[Numpy-discussion] Does float16 exist?

[David Cournapeau]

Charles R Harris wrote:
>
>
> On Jan 8, 2008 6:49 PM, Eric Firing <efiring at hawaii.edu 
> <mailto:efiring at hawaii.edu>> wrote:
>
>     Bill Baxter wrote:
>     > On Jan 9, 2008 9:18 AM, Charles R Harris
>     <charlesr.harris at gmail.com <mailto:charlesr.harris at gmail.com>> wrote:
>     >> On Jan 8, 2008 5:01 PM, Bill Baxter < wbaxter at gmail.com
>     <mailto:wbaxter at gmail.com>> wrote:
>     >>> On Jan 9, 2008 8:03 AM, Charles R Harris
>     <charlesr.harris at gmail.com <mailto:charlesr.harris at gmail.com>>
>     >> wrote:
>     >>>> On Jan 8, 2008 1:58 PM, Bill Baxter < wbaxter at gmail.com
>     <mailto:wbaxter at 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.

David