The sorting module looks okay modulo the name 'half' for the new type. Not that I have a better name in mind.

The OpenGL people debated this and settled on half, so it may not be worth too much effort to try finding an alternative. See the discussion under Issue 2: http://www.opengl.org/registry/specs/ARB/half_float_pixel.txt

There is an impressive amount of work here. It would be nice to have this go in.

I notice that you didn't touch any of the scons files. We have two build systems at the moment and the scons files need to be kept current. The scons build should probably be checked, or at least the files looked at in the directories where you added new files.

I think the documentation needs updating for the scons support (and separate compilation - do people use that option?). I assumed these were experimental/unsupported - here's the documentation about building I found:

http://docs.scipy.org/doc/numpy/user/install.html

In fact, looking at that page closer, it doesn't even describe the installation step, just building in the 'choosing your fortran compiler' section. In my opinion, this should also have an 'advanced' section describing how NumPy developers work with multiple Python versions and NumPy versions simultaneously.

The scons support was David Cournapeau's first project for numpy, it might have been a Google Summer of Code thing, and the hope was to improve on the standard Python build system. In the upshot, I think David found scons not such an improvement as he hoped. Since he has graduated and now has a job, what spare time he has seems to be spent working on bento for packaging with waf as the build system. If he finishes this perhaps numpy will move to a new system. Meanwhile, we are stuck maintaining the current two which is a hassle. It might be worth while opening a discussion on the mainling list at some point.

Yes, some folks do use separate compilation, it came in when the previous several monolithic files that then constituted numpy were broken up, and some find it significantly faster. I've not been much troubled by compilation time myself.

The page on building numpy does need updating and expansion. I'm rather old fashioned myself so someone who uses the more advanced stuff should probably update it, Pauli, Ralf, or David might help there. I'd like to improve my practice myself...

I found a bit more about numscons on the developer's wiki: http://projects.scipy.org/numpy/wiki/NumScons.

Looks like a one line change will fix things for numscons.

diff --git a/numpy/core/SConscript b/numpy/core/SConscript
index bb4ec36..5f72123 100644
--- a/numpy/core/SConscript
+++ b/numpy/core/SConscript
@@ -408,7 +408,8 @@ env.Prepend(CPPPATH = ['src/private', 'include', '.', 'include/numpy'])
 # npymath core lib
 npymath_src = [env.GenerateFromTemplate(pjoin('src', 'npymath', 'npy_math.c.src')),
                env.GenerateFromTemplate(pjoin('src', 'npymath', 'npy_math_complex.c.src')),
-               env.GenerateFromTemplate(pjoin('src', 'npymath', 'ieee754.c.src'))]
+               env.GenerateFromTemplate(pjoin('src', 'npymath', 'ieee754.c.src')),
+               pjoin('src', 'npymath', 'halffloat.c')]
 env.DistutilsInstalledStaticExtLibrary("npymath", npymath_src, install_dir='lib')
 env.Prepend(LIBS=["npymath"])
 env.Prepend(LIBPATH=["."])

I've been playing with the half types and they are pretty neat. I think the scalar types could use a bit more str precision, maybe 5 like the repr.

In [16]: print float16(10.11111)
10.1

In [17]: float16(10.11111)
Out[17]: 10.109

There is probably a bit too much precision in printing float16 arrays. Also the npz files created by savez don't load but that should be easy to fix. And I'm not sure what we want to do about PEP 3118, probably extend it. But all in all, I think this is about ready to go in.

The problem with np.load is that the order modifiers {=,<,>} for the type aren't recogized.

In [9]: np.dtype('f2')
Out[9]: dtype('float16')

In [10]: np.dtype('<f2')
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/home/charris/<ipython console> in <module>()

TypeError: data type not understood

It doesn't look like there's a way to change the array printing precision, because that's controlled by set_printoptions for all floating point types together.

Is there any automated build infrastructure to check that everything compiles and passes the tests on every supported architecture, once I commit it?

I think I've dealt with all your comments, can you do a double check? I may not have understood the documentation change you suggested, so definitely read that over. Once it looks good I can rewrite the changes to be a bit more logical again, then commit.

There is a buildbot at buildbot.scipy.org and it looks like it might working for github now. Except that it seems that all the buldbots are segfaulting somewhere after the test for ticket #1299. Hmm...

OK, looks like the buildbot isn't working for github yet. The failed builds were initiated by Stefan and I suspect he was just testing things.

Couple of missing declarations which may be due to merge problems that I had:

numpy/core/src/multiarray/convert_datatype.c:573: error: ‘to’ undeclared (first use in this function)
numpy/core/src/multiarray/convert_datatype.c:573: error: (Each undeclared identifier is reported only once
numpy/core/src/multiarray/convert_datatype.c:573: error: for each function it appears in.)
numpy/core/src/multiarray/convert_datatype.c:574: error: ‘telsize’ undeclared (first use in this function)
numpy/core/src/multiarray/convert_datatype.c:575: error: ‘felsize’ undeclared (first use in this function)

Also one test failure for coercion of float32. I suspect the recent casting changes in master are causing problems, you might want to rebase your changes to master. The other problems are fixed.

I've rebased and shuffled the history a bit to make the changes a better progression again. I think it's good to go.

I've merged the branch, we can deal with any problems that show up later. You should add some notes to doc/release/2.0.0-notes.rst