[Numpy-discussion] Does float16 exist?

[Charles R Harris]

On Jan 8, 2008 8:42 PM, David Cournapeau <david at ar.media.kyoto-u.ac.jp>
wrote:

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

As  I tried to say, there are ways of dealing with the compatibility
problems at the binary level.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080108/225313ac/attachment.html>