Re: [Numpy-discussion] Does float16 exist?

[Charles R Harris]

On Jan 8, 2008 11:26 PM, David Cournapeau <[EMAIL PROTECTED]>
wrote:


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

So I pulled the template subsystem out of
Django
and I already like it a lot. It seems to work well with some quick C code
templates that I wrote and the markup looks decent. The template language
itself has some built in control tags (if, for loops, etc), templates have
inheritance, and you can invent your own tags. It is all done in Python and
the license is essentially BSD. Note that the template examples on the
Django site generate html code, so all those html tags are just a
distraction. There is also a Django book , so it
is documented.

Chuck


>
> cheers,
>
> David
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[David M. Cooke]

On Jan 9, 2008, at 00:00 , Robert Kern wrote:

> Charles R Harris wrote:
>
>> I see that there are already a number of parsers available for  
>> Python,
>> SPARK, for instance is included in the 2.5.1 distribution.
>
> No, it isn't.


It's used to generate the new parser in 2.5 (Parser/spark.py). It's  
just not included when installed :)

-- 
|>|\/|<
/--\
|David M. Cooke  http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Charles R Harris]

On Jan 9, 2008 6:00 AM, Matthieu Brucher <[EMAIL PROTECTED]> wrote:

> > One would naturally have to be very careful about which features to
> > > use. In particular, don't use anything that throws, and I suppose one
> > > would want to avoid having to link to the stdc++ library also. I don't
> > > know if that is possible.
> > Avoiding linking to the stdc++ would be quite difficult, I think (from
> > the build process, at least). Certainly doable, but difficult.
> >
>
> Why would you want to avoid linking to the stdc++ ?
>

Because I was sleep deprived. That's my story and I'm sticking to it.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Matthieu Brucher]

>
> > One would naturally have to be very careful about which features to
> > use. In particular, don't use anything that throws, and I suppose one
> > would want to avoid having to link to the stdc++ library also. I don't
> > know if that is possible.
> Avoiding linking to the stdc++ would be quite difficult, I think (from
> the build process, at least). Certainly doable, but difficult.
>

Why would you want to avoid linking to the stdc++ ?

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[David Cournapeau]

Charles R Harris wrote:
>
>
> On Jan 8, 2008 11:26 PM, David Cournapeau 
> <[EMAIL PROTECTED] > 
> wrote:
>
> Charles R Harris wrote:
> >
> >
>
> 
>
>
> > 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.
>
>  
> One would naturally have to be very careful about which features to 
> use. In particular, don't use anything that throws, and I suppose one 
> would want to avoid having to link to the stdc++ library also. I don't 
> know if that is possible.
Avoiding linking to the stdc++ would be quite difficult, I think (from 
the build process, at least). Certainly doable, but difficult.
>
>  
> 
>
> I agree on this point (custom code generators use). Note that
> there are
> standard tools to generate simple templates in C (autogen).
>
>  
> Unfortunately, autogen is GPL and I suspect NumPy would be regarded as 
> a derived work. Are you familiar with any other standard, maintained 
> program of that sort with a BSD style license?
I don't think generated source files should be considered as GPL 
(otherwise, you could not build non GPL source with gcc either: I don't 
see where the difference would be between object code generated by the 
compiler and generated source
by autogen). If you read the point 0 of the GPL, it looks quite clear to me:

"Activities other than copying, distribution and modification are not 
covered by this License; they are outside its scope. The act of running 
the Program is not restricted, and the output from the Program is 
covered only if its contents constitute a work based on the Program 
(independent of having been made by running the Program). Whether that 
is true depends on what the Program does."

Once you get the generated source file, you do not need autogen at all 
anymore, which is a pretty strong hint that it is not derived work, 
IMHO. Of course, IANAL, blah blah blah.

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Charles R Harris]

On Jan 8, 2008 11:26 PM, David Cournapeau <[EMAIL PROTECTED]>
wrote:

> Charles R Harris wrote:
> >
> >
>


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


One would naturally have to be very careful about which features to use. In
particular, don't use anything that throws, and I suppose one would want to
avoid having to link to the stdc++ library also. I don't know if that is
possible.



> I agree on this point (custom code generators use). Note that there are
> standard tools to generate simple templates in C (autogen).


Unfortunately, autogen is GPL and I suspect NumPy would be regarded as a
derived work. Are you familiar with any other standard, maintained program
of that sort with a BSD style license?


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

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Matthieu Brucher]

>
> > This is no longer the case, sincerely. I use C++ compilers from
> > different vendors for some time, and I had almost no problem safe from
> > some template depth issues.
> C++ ability is not so much a problem with recent compilers, I agree. But
> not all platforms are or can use a recent C++ compiler. In particular,
> proprietary UNIX. Now, maybe that's something we do not want to support.
> If we limit ourselves to gcc 4 and recent intel/MS compilers, then this
> issue indeed is moot, at least for basic things.


Well, even for basic stuff, I have to say that GCC 4.0 can mysteriously
crash (the SFINAE principle is not respected, 4.1 is fine in that matter),
so using C++ is not worth the trouble now (and besides, I don't know what we
could use right now that cannot be done "easily" in C)

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[David Cournapeau]

Matthieu Brucher wrote:
>
> > 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.
>
>
>
> This is no longer the case, sincerely. I use C++ compilers from 
> different vendors for some time, and I had almost no problem safe from 
> some template depth issues.
C++ ability is not so much a problem with recent compilers, I agree. But 
not all platforms are or can use a recent C++ compiler. In particular, 
proprietary UNIX. Now, maybe that's something we do not want to support. 
If we limit ourselves to gcc 4 and recent intel/MS compilers, then this 
issue indeed is moot, at least for basic things.

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Matthieu Brucher]

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



This is no longer the case, sincerely. I use C++ compilers from different
vendors for some time, and I had almost no problem safe from some template
depth issues.


http://developer.mozilla.org/en/docs/C%2B%2B_Portability_Guide


This is... well... outdated. I'm sorry, but the issues mentionned there are
pre- 2003 standard and since then, the C++ compilers follow the  standard.


http://techbase.kde.org/index.php?title=Policies/Binary_Compatibility_Issues_With_C%2B%2B



KDE wants to maintain binary compatibility across versions. I don't know if
Numpy wants to stay compatible this way, but even there, I don't think Numpy
will use many virtual functions (too slow), and for the change of the
signature of a function, it is logical that it should not work.


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


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


There are some other stuff that are interesting, but I don't think it would
be easy to use, like expression templates, but some operator overloading are
very simple to use (like specializing a template multplication to use CBLAS
if available).

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[David Cournapeau]

Charles R Harris wrote:
>
>
> On Jan 8, 2008 8:55 PM, David Cournapeau <[EMAIL PROTECTED] 
> > wrote:
>
> Charles R Harris wrote:
> >
> >
> > On Jan 8, 2008 8:42 PM, David Cournapeau
> <[EMAIL PROTECTED] 
> >  >> wrote:
> >
> > Charles R Harris wrote:
> > >
> > >
> > > On Jan 8, 2008 6:49 PM, Eric Firing < [EMAIL PROTECTED]
> 
> > >
> > > mailto:[EMAIL PROTECTED]>
>  > >
> > > Bill Baxter wrote:
> > > > On Jan 9, 2008 9:18 AM, Charles R Harris
> > > <[EMAIL PROTECTED]
> 
> >  >
> >  
> >   > > >> On Jan 8, 2008 5:01 PM, Bill Baxter <
> [EMAIL PROTECTED] 
> > >
> > > mailto:[EMAIL PROTECTED]>
>  > > >>> On Jan 9, 2008 8:03 AM, Charles R Harris
> > > < [EMAIL PROTECTED]
> 
> >  >
> >  
>   > > >> wrote:
> > >  On Jan 8, 2008 1:58 PM, Bill Baxter <
> [EMAIL PROTECTED] 
> > >
> > > mailto:[EMAIL PROTECTED]>
>  > > > 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
>   

Re: [Numpy-discussion] Does float16 exist?

[Charles R Harris]

On Jan 8, 2008 10:00 PM, Robert Kern <[EMAIL PROTECTED]> wrote:

> Charles R Harris wrote:
>
> > I see that there are already a number of parsers available for Python,
> > SPARK, for instance is included in the 2.5.1 distribution.
>
> No, it isn't.


Oops, so it isn't. Looks like this news item at the spark site is incorrect.

26 June 2007: John DeGood pointed out that SPARK is in the Python
distribution now – yay!

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Robert Kern]

Charles R Harris wrote:

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

No, it isn't.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Charles R Harris]

On Jan 8, 2008 8:55 PM, David Cournapeau <[EMAIL PROTECTED]>
wrote:

> Charles R Harris wrote:
> >
> >
> > On Jan 8, 2008 8:42 PM, David Cournapeau <[EMAIL PROTECTED]
> > > wrote:
> >
> > Charles R Harris wrote:
> > >
> > >
> > > On Jan 8, 2008 6:49 PM, Eric Firing <[EMAIL PROTECTED]
> > 
> > > mailto:[EMAIL PROTECTED]>>> wrote:
> > >
> > > Bill Baxter wrote:
> > > > On Jan 9, 2008 9:18 AM, Charles R Harris
> > > <[EMAIL PROTECTED]
> > 
> >  > >> wrote:
> > > >> On Jan 8, 2008 5:01 PM, Bill Baxter < [EMAIL PROTECTED]
> > 
> > > >> wrote:
> > > >>> On Jan 9, 2008 8:03 AM, Charles R Harris
> > > < [EMAIL PROTECTED]
> > 
> >  >>>
> > > >> wrote:
> > >  On Jan 8, 2008 1:58 PM, Bill Baxter < [EMAIL PROTECTED]
> > 
> > > >> 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, alt

Re: [Numpy-discussion] Does float16 exist?

[David Cournapeau]

Charles R Harris wrote:
>
>
> On Jan 8, 2008 8:42 PM, David Cournapeau <[EMAIL PROTECTED] 
> > wrote:
>
> Charles R Harris wrote:
> >
> >
> > On Jan 8, 2008 6:49 PM, Eric Firing <[EMAIL PROTECTED]
> 
> > mailto:[EMAIL PROTECTED]>>> wrote:
> >
> > Bill Baxter wrote:
> > > On Jan 9, 2008 9:18 AM, Charles R Harris
> > <[EMAIL PROTECTED]
> 
>  >> wrote:
> > >> On Jan 8, 2008 5:01 PM, Bill Baxter < [EMAIL PROTECTED]
> 
> > >> wrote:
> > >>> On Jan 9, 2008 8:03 AM, Charles R Harris
> > < [EMAIL PROTECTED]
> 
> >>
> > >> wrote:
> >  On Jan 8, 2008 1:58 PM, Bill Baxter < [EMAIL PROTECTED]
> 
> > >> 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
___
Numpy-discussion mailing list
Numpy-discussion@scip

Re: [Numpy-discussion] Does float16 exist?

[Charles R Harris]

On Jan 8, 2008 8:42 PM, David Cournapeau <[EMAIL PROTECTED]>
wrote:

> Charles R Harris wrote:
> >
> >
> > On Jan 8, 2008 6:49 PM, Eric Firing <[EMAIL PROTECTED]
> > > wrote:
> >
> > Bill Baxter wrote:
> > > On Jan 9, 2008 9:18 AM, Charles R Harris
> > <[EMAIL PROTECTED] >
> wrote:
> > >> On Jan 8, 2008 5:01 PM, Bill Baxter < [EMAIL PROTECTED]
> > > wrote:
> > >>> On Jan 9, 2008 8:03 AM, Charles R Harris
> > <[EMAIL PROTECTED] >
> > >> wrote:
> >  On Jan 8, 2008 1:58 PM, Bill Baxter < [EMAIL PROTECTED]
> > > 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
> > 
> >
> >
> > 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
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[David Cournapeau]

Charles R Harris wrote:
>
>
> On Jan 8, 2008 6:49 PM, Eric Firing <[EMAIL PROTECTED] 
> > wrote:
>
> Bill Baxter wrote:
> > On Jan 9, 2008 9:18 AM, Charles R Harris
> <[EMAIL PROTECTED] > wrote:
> >> On Jan 8, 2008 5:01 PM, Bill Baxter < [EMAIL PROTECTED]
> > wrote:
> >>> On Jan 9, 2008 8:03 AM, Charles R Harris
> <[EMAIL PROTECTED] >
> >> wrote:
>  On Jan 8, 2008 1:58 PM, Bill Baxter < [EMAIL PROTECTED]
> > 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
> 
>
>
> 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
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Charles R Harris]

On Jan 8, 2008 6:49 PM, Eric Firing <[EMAIL PROTECTED]> wrote:

> Bill Baxter wrote:
> > On Jan 9, 2008 9:18 AM, Charles R Harris <[EMAIL PROTECTED]>
> wrote:
> >> On Jan 8, 2008 5:01 PM, Bill Baxter <[EMAIL PROTECTED]> wrote:
> >>> On Jan 9, 2008 8:03 AM, Charles R Harris <[EMAIL PROTECTED]>
> >> wrote:
>  On Jan 8, 2008 1:58 PM, Bill Baxter < [EMAIL PROTECTED]> 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
>

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.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[David Cournapeau]

Charles R Harris wrote:
>
>
> On Jan 8, 2008 1:58 PM, Bill Baxter <[EMAIL PROTECTED] 
> > 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.
Why do you think scons would help ? You can build C++ code today with 
distutils; but I am not sure it is ok to use C++ in numpy (e.g. adding a 
C++ compiler dependency). Also, note that C++ is really a mess to 
support on multi-platform because of compiler incompabilities (at the 
source and at the binary level).

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Eric Firing]

Bill Baxter wrote:
> On Jan 9, 2008 9:18 AM, Charles R Harris <[EMAIL PROTECTED]> wrote:
>> On Jan 8, 2008 5:01 PM, Bill Baxter <[EMAIL PROTECTED]> wrote:
>>> On Jan 9, 2008 8:03 AM, Charles R Harris <[EMAIL PROTECTED]>
>> wrote:
 On Jan 8, 2008 1:58 PM, Bill Baxter < [EMAIL PROTECTED]> 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

Eric


> 
> As far as classes go, though, you pretty much won't find anything
> easier than this to C-ify.  Or just to wrap in C.  No templates.  No
> inheritance.  Just a simple value-type struct that supports a small
> set of operations.
> 
> --bb
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Bill Baxter]

On Jan 9, 2008 9:18 AM, Charles R Harris <[EMAIL PROTECTED]> wrote:
> On Jan 8, 2008 5:01 PM, Bill Baxter <[EMAIL PROTECTED]> wrote:
> > On Jan 9, 2008 8:03 AM, Charles R Harris <[EMAIL PROTECTED]>
> wrote:
> > > On Jan 8, 2008 1:58 PM, Bill Baxter < [EMAIL PROTECTED]> 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.

If you think that's easier then go for it.

As far as classes go, though, you pretty much won't find anything
easier than this to C-ify.  Or just to wrap in C.  No templates.  No
inheritance.  Just a simple value-type struct that supports a small
set of operations.

--bb
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Charles R Harris]

On Jan 8, 2008 5:01 PM, Bill Baxter <[EMAIL PROTECTED]> wrote:

> On Jan 9, 2008 8:03 AM, Charles R Harris <[EMAIL PROTECTED]>
> wrote:
> > On Jan 8, 2008 1:58 PM, Bill Baxter <[EMAIL PROTECTED]> 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.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Bill Baxter]

On Jan 9, 2008 8:03 AM, Charles R Harris <[EMAIL PROTECTED]> wrote:
> On Jan 8, 2008 1:58 PM, Bill Baxter <[EMAIL PROTECTED]> 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.

--bb
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Charles R Harris]

On Jan 8, 2008 1:58 PM, Bill Baxter <[EMAIL PROTECTED]> 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.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Bill Baxter]

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.

--bb

On Jan 9, 2008 5:24 AM, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
>
>
> On Jan 8, 2008 1:09 PM, Anne Archibald <[EMAIL PROTECTED]> wrote:
> >
> > On 08/01/2008, Charles R Harris <[EMAIL PROTECTED]> wrote:
> >
> >
> > > Well, at a minimum people will want to read, write, print, and promote
> them.
> > > That would at least let people work with the numbers, and since my
> > > understanding is that the main virtue of the format is compactness for
> > > storage and communication, a basic need will be filled right there. One
> > > potential problem I see is handling +/-inf and nans, tests for these
> should
> > > probably be built into the type.
> >
> > The el-cheapo solution to this simply provides two functions: take an
> > int16 array (which actually contains float16) and produce a float32
> > array, and vice versa. Then people do all their work in float32 (or
> > float64 is float32  doesn't have inf/nan, I don't remember) but can
> > read and write float16.
> >
>
> Sure, but where's the fun in that? Besides, I think that adding a data type
> might be an opportunity to generate a detailed road map for future projects
> that might actually matter (quads and decimal floats for money stuff), and
> might provide a chance to revisit some code and see if it can be simplified.
> It's tough to get up the motivation to do that without some other prod.
> Besides, it's new and I have a weakness for new stuff.
>
>
> >
> > Of course it would be nicer to use flaot16 natively, more or less, but
> > without all the math that's going to be a frustrating experience.
>
> I would plan on at least arithmetic. Adding special functions probably ain't
> worth it and even now a lot of things are done by promoting things to floats
> or doubles and calling routines in LAPACK.
>
> Chuck
>
>
>
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Darren Dale]

On Tuesday 08 January 2008 03:24:49 pm Charles R Harris wrote:
> On Jan 8, 2008 1:09 PM, Anne Archibald <[EMAIL PROTECTED]> wrote:
> > On 08/01/2008, Charles R Harris <[EMAIL PROTECTED]> wrote:
> > > Well, at a minimum people will want to read, write, print, and promote
> >
> > them.
> >
> > > That would at least let people work with the numbers, and since my
> > > understanding is that the main virtue of the format is compactness for
> > > storage and communication, a basic need will be filled right there. One
> > > potential problem I see is handling +/-inf and nans, tests for these
> >
> > should
> >
> > > probably be built into the type.
> >
> > The el-cheapo solution to this simply provides two functions: take an
> > int16 array (which actually contains float16) and produce a float32
> > array, and vice versa. Then people do all their work in float32 (or
> > float64 is float32  doesn't have inf/nan, I don't remember) but can
> > read and write float16.
>
> Sure, but where's the fun in that? Besides, I think that adding a data type
> might be an opportunity to generate a detailed road map for future projects
> that might actually matter (quads and decimal floats for money stuff), and
> might provide a chance to revisit some code and see if it can be
> simplified. It's tough to get up the motivation to do that without some
> other prod. Besides, it's new and I have a weakness for new stuff.
>
> > Of course it would be nicer to use flaot16 natively, more or less, but
> > without all the math that's going to be a frustrating experience.
>
> I would plan on at least arithmetic. Adding special functions probably
> ain't worth it and even now a lot of things are done by promoting things to
> floats or doubles and calling routines in LAPACK.

For what its worth, the people I work with were interested in using float16's 
for their work too (not just storage), but since they are not available, they 
will use float32 and are investigating pytables to cut back on memory and 
disk use.

-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

[EMAIL PROTECTED]
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Charles R Harris]

On Jan 8, 2008 1:09 PM, Anne Archibald <[EMAIL PROTECTED]> wrote:

> On 08/01/2008, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
> > Well, at a minimum people will want to read, write, print, and promote
> them.
> > That would at least let people work with the numbers, and since my
> > understanding is that the main virtue of the format is compactness for
> > storage and communication, a basic need will be filled right there. One
> > potential problem I see is handling +/-inf and nans, tests for these
> should
> > probably be built into the type.
>
> The el-cheapo solution to this simply provides two functions: take an
> int16 array (which actually contains float16) and produce a float32
> array, and vice versa. Then people do all their work in float32 (or
> float64 is float32  doesn't have inf/nan, I don't remember) but can
> read and write float16.
>

Sure, but where's the fun in that? Besides, I think that adding a data type
might be an opportunity to generate a detailed road map for future projects
that might actually matter (quads and decimal floats for money stuff), and
might provide a chance to revisit some code and see if it can be simplified.
It's tough to get up the motivation to do that without some other prod.
Besides, it's new and I have a weakness for new stuff.


> Of course it would be nicer to use flaot16 natively, more or less, but
> without all the math that's going to be a frustrating experience.


I would plan on at least arithmetic. Adding special functions probably ain't
worth it and even now a lot of things are done by promoting things to floats
or doubles and calling routines in LAPACK.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Anne Archibald]

On 08/01/2008, Charles R Harris <[EMAIL PROTECTED]> wrote:

> Well, at a minimum people will want to read, write, print, and promote them.
> That would at least let people work with the numbers, and since my
> understanding is that the main virtue of the format is compactness for
> storage and communication, a basic need will be filled right there. One
> potential problem I see is handling +/-inf and nans, tests for these should
> probably be built into the type.

The el-cheapo solution to this simply provides two functions: take an
int16 array (which actually contains float16) and produce a float32
array, and vice versa. Then people do all their work in float32 (or
float64 is float32  doesn't have inf/nan, I don't remember) but can
read and write float16.

Of course it would be nicer to use flaot16 natively, more or less, but
without all the math that's going to be a frustrating experience.

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Charles R Harris]

On Jan 8, 2008 12:03 PM, Anne Archibald <[EMAIL PROTECTED]> wrote:

> On 08/01/2008, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
> > I'm starting to get interested in implementing float16 support ;) My
> > tentative program goes something like this:
> >
> > 1) Add the operators to the scalar type. This will give sorting, basic
> > printing, addition, etc.
> > 2) Add conversions to other types. This will allow promotion of data to
> > currently supported types.
> > 3) Unoptimized BLAS or ATLAS additions for the type. This would give
> array
> > operations.
> > 4) Figure out what the precedence relations are.
> >
> > Can you add some details to this roadmap? It also strikes me that this
> > exercise can be repeated for quad precision floats, so might be a good
> > preparation for future IEEE types like the proposed decimal floating
> types.
> > Note that we are going to need some way to distinguish quads and
> extended
> > precision types on 64bit platforms, as both will both register as
> float128
> > in the current notation. Decimal floats can be added with the notation
> > decimal64, etc.
>
> How were you planning to implement the basic mathematics (addition,
> multiplication, trig, what have you)? Were you planning to code all


Basic math isn't bad and I expect that there are already emulations out
there. Comparisons look easy for all the floating types. Type conversions
are going to be a mess if we get into the decimal floats. And support for
ufuncs is probably pointless for the type as is. I will probably look into
using up/down conversions on an element by element basis if I do go that
route. Logic operators shouldn't be a problem, avg and such already
accumulate in greater precision, so there is probably a subset of the
ufuncts that should go right over.


> that from scratch or is there a 16-bit float math library? Or were you
> planning to make this work only on machines with 16-bit math hardware?
> Or ship it out to a graphics card?
>
> Without hardware support, people may be happier using 16-bit floats
> only for on-disk storage...


Well, at a minimum people will want to read, write, print, and promote them.
That would at least let people work with the numbers, and since my
understanding is that the main virtue of the format is compactness for
storage and communication, a basic need will be filled right there. One
potential problem I see is handling +/-inf and nans, tests for these should
probably be built into the type.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Anne Archibald]

On 08/01/2008, Charles R Harris <[EMAIL PROTECTED]> wrote:

> I'm starting to get interested in implementing float16 support ;) My
> tentative program goes something like this:
>
> 1) Add the operators to the scalar type. This will give sorting, basic
> printing, addition, etc.
> 2) Add conversions to other types. This will allow promotion of data to
> currently supported types.
> 3) Unoptimized BLAS or ATLAS additions for the type. This would give array
> operations.
> 4) Figure out what the precedence relations are.
>
> Can you add some details to this roadmap? It also strikes me that this
> exercise can be repeated for quad precision floats, so might be a good
> preparation for future IEEE types like the proposed decimal floating types.
> Note that we are going to need some way to distinguish quads and extended
> precision types on 64bit platforms, as both will both register as float128
> in the current notation. Decimal floats can be added with the notation
> decimal64, etc.

How were you planning to implement the basic mathematics (addition,
multiplication, trig, what have you)? Were you planning to code all
that from scratch or is there a 16-bit float math library? Or were you
planning to make this work only on machines with 16-bit math hardware?
Or ship it out to a graphics card?

Without hardware support, people may be happier using 16-bit floats
only for on-disk storage...

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Charles R Harris]

On Jan 7, 2008 1:09 PM, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:

> Darren Dale wrote:
> > One of my collaborators would like to use 16bit float arrays. According
> to
> > http://www.scipy.org/Tentative_NumPy_Tutorial, and references to float16
> in
> > numpy.core.numerictypes, it appears that this should be possible, but
> the
> > following doesnt work:
> >
>
> No, it's only possible, if the C-implementation NumPy was compiled with
> has 16-bits for its float scalar.
>
> Only float, double, and long double are implemented.  These translate to
> various bit-widths on different platforms.  numerictypes is overly
> aggressive at guessing what they might translate to.
>

I'm starting to get interested in implementing float16 support ;) My
tentative program goes something like this:

1) Add the operators to the scalar type. This will give sorting, basic
printing, addition, etc.
2) Add conversions to other types. This will allow promotion of data to
currently supported types.
3) Unoptimized BLAS or ATLAS additions for the type. This would give array
operations.
4) Figure out what the precedence relations are.

Can you add some details to this roadmap? It also strikes me that this
exercise can be repeated for quad precision floats, so might be a good
preparation for future IEEE types like the proposed decimal floating types.
Note that we are going to need some way to distinguish quads and extended
precision types on 64bit platforms, as both will both register as float128
in the current notation. Decimal floats can be added with the notation
decimal64, etc.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Darren Dale]

On Monday 07 January 2008 03:09:33 pm Travis E. Oliphant wrote:
> Darren Dale wrote:
> > One of my collaborators would like to use 16bit float arrays. According
> > to http://www.scipy.org/Tentative_NumPy_Tutorial, and references to
> > float16 in numpy.core.numerictypes, it appears that this should be
> > possible, but the following doesnt work:
>
> No, it's only possible, if the C-implementation NumPy was compiled with
> has 16-bits for its float scalar.
>
> Only float, double, and long double are implemented.  These translate to
> various bit-widths on different platforms.  numerictypes is overly
> aggressive at guessing what they might translate to.

Thanks for the clarification, Travis.

Darren
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Darren Dale]

On Monday 07 January 2008 03:53:06 pm Charles R Harris wrote:
> Hi,
>
> On Jan 7, 2008 1:00 PM, Darren Dale <[EMAIL PROTECTED]> wrote:
> > One of my collaborators would like to use 16bit float arrays. According
> > to http://www.scipy.org/Tentative_NumPy_Tutorial, and references to
> > float16 in
> > numpy.core.numerictypes, it appears that this should be possible, but the
> > following doesnt work:
> >
> > a=arange(10, dtype='float16')
> > TypeError: data type not understood
> >
> > Can anyone offer some advice?
>
> Does he care about speed? I think some graphics cards might support
> float16, but any normal implementation in C would reguire software floating
> point, a new type, and you couldn't rely on the normal operators. It might
> be doable in C++ with operator overloading and templates, but doing it in C
> would be a real hassle.

He is analyzing many sets of 2D data, each array is 3450x3450 pixels. I think 
memory/space is a greater concern at the moment than speed, 24 vs 48 
megabytes. They are more concerned with processing these arrays than viewing 
them.

Darren
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Charles R Harris]

Hi,

On Jan 7, 2008 1:00 PM, Darren Dale <[EMAIL PROTECTED]> wrote:

> One of my collaborators would like to use 16bit float arrays. According to
> http://www.scipy.org/Tentative_NumPy_Tutorial, and references to float16
> in
> numpy.core.numerictypes, it appears that this should be possible, but the
> following doesnt work:
>
> a=arange(10, dtype='float16')
> TypeError: data type not understood
>
> Can anyone offer some advice?
>

Does he care about speed? I think some graphics cards might support float16,
but any normal implementation in C would reguire software floating point, a
new type, and you couldn't rely on the normal operators. It might be doable
in C++ with operator overloading and templates, but doing it in C would be a
real hassle.


> Thanks,
> Darren


Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Travis E. Oliphant]

Darren Dale wrote:
> One of my collaborators would like to use 16bit float arrays. According to 
> http://www.scipy.org/Tentative_NumPy_Tutorial, and references to float16 in 
> numpy.core.numerictypes, it appears that this should be possible, but the 
> following doesnt work:
>   

No, it's only possible, if the C-implementation NumPy was compiled with 
has 16-bits for its float scalar.

Only float, double, and long double are implemented.  These translate to 
various bit-widths on different platforms.  numerictypes is overly 
aggressive at guessing what they might translate to.

-Travis O.


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Does float16 exist?

[Matthieu Brucher]

float16 is not defined in my version of Numpy :(

Matthieu

2008/1/7, Darren Dale <[EMAIL PROTECTED]>:
>
> One of my collaborators would like to use 16bit float arrays. According to
> http://www.scipy.org/Tentative_NumPy_Tutorial, and references to float16
> in
> numpy.core.numerictypes, it appears that this should be possible, but the
> following doesnt work:
>
> a=arange(10, dtype='float16')
> TypeError: data type not understood
>
> Can anyone offer some advice?
>
> Thanks,
> Darren
>
> --
> Darren S. Dale, Ph.D.
> Staff Scientist
> Cornell High Energy Synchrotron Source
> Cornell University
> 275 Wilson Lab
> Rt. 366 & Pine Tree Road
> Ithaca, NY 14853
>
> [EMAIL PROTECTED]
> office: (607) 255-3819
> fax: (607) 255-9001
> http://www.chess.cornell.edu
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Does float16 exist?

[Darren Dale]

One of my collaborators would like to use 16bit float arrays. According to 
http://www.scipy.org/Tentative_NumPy_Tutorial, and references to float16 in 
numpy.core.numerictypes, it appears that this should be possible, but the 
following doesnt work:

a=arange(10, dtype='float16')
TypeError: data type not understood

Can anyone offer some advice?

Thanks,
Darren

-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

[EMAIL PROTECTED]
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion