[Numpy-discussion] Does float16 exist?

David Cournapeau david@ar.media.kyoto-u.ac...
Wed Jan 9 00:26:21 CST 2008


Charles R Harris wrote:
>
>
> On Jan 8, 2008 8:55 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 8:42 PM, David Cournapeau
>     <david@ar.media.kyoto-u.ac.jp <mailto:david@ar.media.kyoto-u.ac.jp>
>     > <mailto: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>>
>     >     > <mailto: 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>>
>     >     <mailto: 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>>
>     >     >     <mailto: 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>>
>     >     <mailto: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>>
>     >     >     <mailto: 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>
>     >     >     <
>     >    
>     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.
There are also issues, but they are much simpler.
> The C++ name mangling can be worked around.
name mangling is just the top of the iceberg. There are problems wrt to 
static initialization, exception, etc...; ABI compatibility is much 
easier to break in C++ than in C. And then, there is the problem of C++ 
ability of compilers.

http://developer.mozilla.org/en/docs/C%2B%2B_Portability_Guide
http://techbase.kde.org/index.php?title=Policies/Binary_Compatibility_Issues_With_C%2B%2B

I am not saying it is not possible, or that we should not do it: just 
that it has a high cost. IMHO, the benefits would have to be high.
> 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.
I agree on this point (custom code generators use). Note that there are 
standard tools to generate simple templates in C (autogen).

If what you want to do is to be able to use simple templates (by simple, 
I mean template function parametrized with the numerical type), C++ is 
overkill IMHO.

cheers,

David


More information about the Numpy-discussion mailing list