[Numpy-discussion] Does float16 exist?

[Charles R Harris]

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

> Charles R Harris wrote:
> >
> >
> > On Jan 8, 2008 8:42 PM, David Cournapeau <david at ar.media.kyoto-u.ac.jp
> > <mailto: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>
> >     > <mailto: 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>
> >     <mailto: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>
> >     >     <mailto: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>
> >     <mailto: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>
> >     >     <mailto: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.
> 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


This can also be true of C code unless you use compilers in the same family.
The C++ name mangling can be worked around. I'm just thinking out loud about
these things. Note that numpy already uses what are essentially templates to
generate C code using a Python preprocessor, although perhaps the design
could be a bit cleaner and maybe a bit more general so as not to be limited
to the C builtin types. What I want is a clean way to get around the
limitations of the builtin C numeric types. The ability is there in the
Python numeric type, which is function pointer based, so the rest just comes
down to ease of coding and trying to make the result efficient. The last is
where operator overloading and inline code might come in so as to avoid
always calling through a pointer, but it might not be worth the hassle and
the returns might be too small to take that last step.

I see that there are already a number of parsers available for Python,
SPARK, for instance is included in the 2.5.1 distribution.

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