Mailman 3 July 2011 - NumPy-Discussion

import
by Alex Ter-Sarkissov 19 Jul '11

19 Jul '11

this is probably silly question, I've seen in this in one of the tutorials: from tkinter import * import tkinter.messagebox given that * implies importing the whole module, why would anyone bother with importing a specific command on top of it?

2 1

Re: [Numpy-discussion] fate of array interface
by Sam Quinan 18 Jul '11

18 Jul '11

As I got no response to my original email, I figured I'd ask one more time just in case somebody who could answer my question(s) missed it the first time... Is array_interface actually being deprecated in favor of PEP 3118? If so, when? Are there eventual plans for python-side buffer specification of PEP 3118 protocol, in order for users to be able to use PEP 3118 with ctypes-extended libraries? Besides this list is there anywhere else I can check for this information? The numpy 1.4 documentation seems to suggest that it will be deprecated http://docs.scipy.org/doc/numpy-1.4.x/reference/arrays.interface.html while the 1.6 and current development versions of documentation don't mention deprecation, but simply inform users that PEP 3118 exists as an alternative http://docs.scipy.org/doc/numpy/reference/arrays.interface.html Thus my confusion... - Sam On 7/13/11 6:15 PM, "numpy-discussion-request(a)scipy.org" <numpy-discussion-request(a)scipy.org> wrote: > Message: 3 > Date: Wed, 13 Jul 2011 17:47:59 -0500 > From: Sam Quinan <samquinan(a)gmail.com> > Subject: [Numpy-discussion] Fate of Numpy's Array Interface > To: <numpy-discussion(a)scipy.org> > Message-ID: <CA438ACF.6070%samquinan(a)gmail.com> > Content-Type: text/plain; charset="US-ASCII" > > Hey, > > So I'm working on interfacing numpy ndarrays with an n-dimensional array > representation that exists as part of a massive custom C library. Due to the > size of the library, hand-coding a c-extension for the library just was not > really an option; so we wound up using gcc_xml to generate the proper ctypes > code. This works great for accessing our C functions within python, but not > so much for trying share memory between numpy and our custom array > representations... Passing a pointer to the numpy array data to ctypes is > fairly simple, but figuring out the proper way to get memory from ctypes > into numpy has been problematic. > > I know that PEP 3118 is supposed to be superseding the numpy array > interface, but PEP 3118 can only be specified on the C side, which is > problematic for anybody using ctypes to wrap their C code. The legacy > __array_interface__ allows for a python side specification of data buffers, > but there appears to be no corresponding interface capability in the PEP > 3118 protocol. On top of that add the fact that Python's own support for PEP > 3118 has some major bugs (ctypes throwing invalid PEP 3118 codes - > http://bugs.python.org/issue10746 :: issues with python's memoryview object > - http://bugs.python.org/issue10181), and PEP 3118 seems like a nightmare to > deal with. At the same time though, I don't want to simply use the legacy > array interface if it's going to be completely deprecated in the near > future. > > How long before the legacy __array_interface__ goes the way of the dodo? > When that happens, are there plans to add support for a python side > interface to the PEP 3118 protocol? If not, what is the proper way to > interface a ctypes wrapped library with PEP 3118? > > Thanks, > > - Sam Quinan

2 1

Your NumPy application on a Computer Cluster in the Cloud - cloudnumbers.com
by Markus Schmidberger 18 Jul '11

18 Jul '11

Dear NumPy users and experts, cloudnumbers.com provides researchers and companies with the access to resources to perform high performance calculations in the cloud. As cloudnumbers.com's community manager I may invite you to register and test your Python application on a computer cluster in the cloud for free: http://my.cloudnumbers.com/register We are looking forward to get your feedback and consumer insights. Take the chance and have an impact to the development of a new cloud computing calculation platform. Our aim is to change the way of research collaboration is done today by bringing together scientists and businesses from all over the world on a single platform. cloudnumbers.com is a Berlin (Germany) based international high-tech startup striving for enabling everyone to benefit from the High Performance Computing related advantages of the cloud. We provide easy access to applications running on any kind of computer hardware from single core high memory machines up to 1000 cores computer clusters. To get more information check out our web-page (http://www.cloudnumbers.com/) or follow our blog about cloud computing, HPC and HPC applications: http://cloudnumbers.com/blog Key features of our platform for efficient computing in the cloud are: * Turn fixed into variable costs and pay only for the capacity you need. Watch our latest saving costs with cloudnumbers.com video: http://www.youtube.com/watch?v=ln_BSVigUhg&feature=player_embedded * Enter the cloud using an intuitive and user friendly platform. Watch our latest cloudnumbers.com in a nutshell video: http://www.youtube.com/watch?v=0ZNEpR_ElV0&feature=player_embedded * Be released from ongoing technological obsolescence and continuous maintenance costs (e.g. linking to libraries or system dependencies) * Accelerated your Python, C, C++, Fortran, R, ... calculations through parallel processing and great computing capacity - more than 1000 cores are available and GPUs are coming soon. * Share your results worldwide (coming soon). * Get high speed access to public databases (please let us know, if your favorite database is missing!). * We have developed a security architecture that meets high requirements of data security and privacy. Read our security white paper: http://d1372nki7bx5yg.cloudfront.net/wp-content/uploads/2011/06/cloudnumber… Best Markus -- Dr. rer. nat. Markus Schmidberger Senior Community Manager Cloudnumbers.com GmbH Chausseestraße 6 10119 Berlin www.cloudnumbers.com E-Mail: markus.schmidberger(a)cloudnumbers.com ************************* Amtsgericht München, HRB 191138 Geschäftsführer: Erik Muttersbach, Markus Fensterer, Moritz v. Petersdorff-Campen

1 0

PyBUF_SIMPLE requests
by Stefan Krah 18 Jul '11

18 Jul '11

Hello, I'm working on the completion of the PEP-3118 (buffer protocol) implementation in Python core. I was wondering how a PyBUF_SIMPLE buffer request sent to an object with a complex structure should behave. The current Python C-API documentation for a PyBUF_SIMPLE buffer request says: "This is the default flag. The returned buffer exposes a read-only memory area. The format of data is assumed to be raw unsigned bytes, without any particular structure. This is a “stand-alone” flag constant. It never needs to be ‘|’d to the others. The exporter will raise an error if it cannot provide such a contiguous buffer of bytes." To me a memory view "without any particular structure" means that the returned buffer should always expose the whole memory area. But NumPy behaves differently (see below for the printbuffer() hack): Python 3.3.0a0 (default:1dd6908df8f5, Jul 16 2011, 11:16:00) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from numpy import * >>> x = ndarray(buffer=bytearray([1,2,3,4,5,6,7,8,9,10]), shape=[10], strides=[-1], dtype="B", offset=9) >>> x array([10, 9, 8, 7, 6, 5, 4, 3, 2, 1], dtype='uint8') >>> x.printbuffer() PyBUF_FULL: obj: 0x7f527e946240 buf: 0x7f5281268c79 buf[0]: 10 len: 10 itemsize: 1 readonly: 0 ndim: 1 format: B shape: 10 strides: -1 PyBUF_SIMPLE: obj: 0x7f527e946240 buf: 0x7f5281268c79 buf[0]: 10 len: 10 itemsize: 1 readonly: 0 ndim: 0 format: (null) shape: strides: The PyBUF_FULL request returns a reasonable buffer, because consumers that follow the strides will behave correctly. I do not understand the PyBUF_SIMPLE result. According to the C-API docs a consumer would be allowed to access buf[9], which would be invalid. Or is a consumer supposed to observe ndim = 0 and treat the result as a scalar? If so, there is a problem with this approach. For example, consumers like the struct module do not care about ndim and would walk right out of the array. Stefan Krah printbuffer() hack: ============================================================================ diff --git a/numpy/core/src/multiarray/methods.c b/numpy/core/src/multiarray/methods.c index 68f697a..1cd260a 100644 --- a/numpy/core/src/multiarray/methods.c +++ b/numpy/core/src/multiarray/methods.c @@ -2234,6 +2234,51 @@ array_newbyteorder(PyArrayObject *self, PyObject *args) } +static int +do_print(PyObject *self, int flags, const char *flagstring) +{ + Py_buffer view; + int i; + + if (PyObject_GetBuffer(self, &view, flags) < 0) + return -1; + + fprintf(stderr, "%s:\n\n", flagstring); + fprintf(stderr, "obj: %p\n", view.obj); + fprintf(stderr, "buf: %p\n", view.buf); + fprintf(stderr, "buf[0]: %d\n", ((char *)(view.buf))[0]); + fprintf(stderr, "len: %zd\n", view.len); + fprintf(stderr, "itemsize: %zd\n", view.itemsize); + fprintf(stderr, "readonly: %d\n", view. readonly); + fprintf(stderr, "ndim: %d\n", view.ndim); + fprintf(stderr, "format: %s\n", view.format); + + fprintf(stderr, "shape: "); + for (i = 0; i < view.ndim; i++) + fprintf(stderr, "%zd ", view.shape[i]); + fprintf(stderr, "\n"); + + fprintf(stderr, "strides: "); + for (i = 0; i < view.ndim; i++) + fprintf(stderr, "%zd ", view.strides[i]); + fprintf(stderr, "\n\n"); + + PyBuffer_Release(&view); + + return 0; +} + +static PyObject * +array_print_getbuf(PyObject *self, PyObject *dummy) +{ + if (do_print(self, PyBUF_FULL, "PyBUF_FULL") < 0) + return NULL; + if (do_print(self, PyBUF_SIMPLE, "PyBUF_SIMPLE") < 0) + return NULL; + + Py_RETURN_NONE; +} + NPY_NO_EXPORT PyMethodDef array_methods[] = { /* for subtypes */ @@ -2426,6 +2471,9 @@ NPY_NO_EXPORT PyMethodDef array_methods[] = { {"view", (PyCFunction)array_view, METH_VARARGS | METH_KEYWORDS, NULL}, + {"printbuffer", + (PyCFunction)array_print_getbuf, + METH_NOARGS, NULL}, {NULL, NULL, 0, NULL} /* sentinel */ };

2 1

Numpydoc warnings for methods
by Tony Yu 17 Jul '11

17 Jul '11

I'm building documentation using Sphinx, and it seems that numpydoc is raising a lot of warnings. Specifically, the warnings look like "failed to import <method_name>", "toctree references unknown document u'<method_name>'", "toctree contains reference to nonexisting document '<method_name>'---for each method defined. The example below reproduces the issue on my system (Sphinx 1.0.7, numpy HEAD). These warnings appear in my build of the numpy docs, as well. Removing numpydoc from the list of Sphinx extensions gets rid of these warnings (but, of course, adds new warnings if headings for 'Parameters', 'Returns', etc. are present). Am I doing something wrong here? Thanks, -Tony test_sphinx/foo.py: =================== class Bar(object): """Bar docstring""" def baz(self): """baz docstring""" pass test_sphinx/doc/source/foo.rst: =============================== .. autoclass:: foo.Bar :members: Warnings from build: ==================== /Users/Tony/Desktop/test_sphinx/doc/source/foo.rst:13: (WARNING/2) failed to import baz /Users/Tony/Desktop/test_sphinx/doc/source/foo.rst:13: (WARNING/2) toctree references unknown document u'baz' /Users/Tony/Desktop/test_sphinx/doc/source/foo.rst:: WARNING: toctree contains reference to nonexisting document 'baz'

2 2

Adding a linear system type to NumPy?
by Sturla Molden 17 Jul '11

17 Jul '11

The problem I am thinking we might try to might fix is that programmers with less numerical competence is unaware that the matrix expression (X**-1) * Y should be written as np.linalg.solve(X,Y) I've seen numerous times matrix expressions being typed exactly as written in linear algebra text books. Matlab does this with the backslash operator, though it is not that intuitive. Also, there seems to be general agreement against a backslash division operator in Python. So I suggest inverting a NumPy matrix could result in an unsolved linear system type, instead of actually computing the matrix inverse and returning a new matrix. The linear system type would store two arrays, A and X, symbolically representing A * (X**-1). Initially, A would be set to the indenty matrix, I. A matrix expression Y * (X**-1) would result in (1) creation of a LinearSystem object for the iversion of X, and (2) matrix multiplication of Y by A, returning a new LinearSystem object with A updated by A = Y * A. The matrix expression (X**-1) * Y Would result in (1) creation of a LinearSystem object for the iversion of X, and (2) solution of the linear system by calling np.linalg.solve, i.e. np np.linalg.solve(X,Y) The matrix expression would Z * (X**-1) * Y would form a linear system type for X, initialize A to Z, and then evaluate np.dot(A, np np.linalg.solve(X,Y)) cf. Python's evaluation order is left to right. Any other operation on a linear system (e.g. slicing) would result in formation of the inverse, by solving it against the identity matrix, set a flag that the system is solved, and then just behave as an ordinary np.matrix. Thus, (X**-1) * Y would behave as before, but do the "correct" math (instead of explicitely forming the inverse and then multiplying). Consequently this would be the same as Matlab's backslash operator, only more intuitive, as the syntax would be the same as textbook linear algebra notation. A for naming, it could e.g. be np.linear_system. I am just thinking out loudly, so forgive me for spamming the list :-) Sturla

3 3

numpy build issue on i7-2600K CPU
by Christoph Gohlke 17 Jul '11

17 Jul '11

Hello, building numpy 1.6.1rc2 on Windows, i7-2600K CPU, with msvc9 failed with the following error: File "numpy/core/setup_common.py", line 271, in long_double_representation raise ValueError("Could not lock sequences (%s)" % saw) ValueError: Could not lock sequences (None) This problem has been mentioned before at <http://mail.scipy.org/pipermail/numpy-discussion/2011-March/055571.html>. Opening the configtest.obj file in binary mode fixed the issue for me. A patch is attached. Christoph

2 2

Problem with boolean-indexing of structured arrays
by Benjamin Root 16 Jul '11

16 Jul '11

Just a heads-up, I have uncovered a serious bug in one of my programs and traced it down to a boolean indexing of a structured array in the current master branch of numpy. While I am still investigating exactly what is happening, my initial suspicion is that data from another structured array is getting transplanted into the array view that I have. I have not encountered this bug before, but I am currently checking with older versions of numpy to see if it is a regression or not. I will update with more information shortly. Ben Root

1 1

Fwd: [Enthought-Dev] Linking issues with libX11.so
by Ilan Schnell 15 Jul '11

15 Jul '11

Hello List, Varun, who is a debian packager ran into some problems while compiling Enable, as it uses numpy.distutils, which did not locate the location of the X11 libraries correctly. Maybe this can be fixed in the numpy 1.6.1 release. Please the the forwarded conversation below. Thanks Ilan ---------- Forwarded message ---------- From: Varun Hiremath <varunhiremath(a)gmail.com> Date: Wed, Jul 13, 2011 at 4:03 PM Subject: [Enthought-Dev] Linking issues with libX11.so To: enthought-dev(a)enthought.com Hi Ilan, You were right, the issue was with the X11 library. The _plat_support.so was not linked to libX11 and so the chaco examples were failing; and the reason libX11 was not linked was because numpy distutils' x11_info was failing. I figured out that in debian/ubuntu with a new multi_arch build support [1] the libraries are being moved from the standard /usr/lib and /usr/lib64 directories to architecture specific directories like: /usr/lib/i386-linux-gnu/ /usr/lib/x86_64-linux-gnu/ and so the numpy.distutil was failing to find libX11 with the latest version of libX11-dev on debian which installs libX11.so in /usr/lib/x86_64-linux-gnu/ (on my amd64 system). The nump.distutils' scripts need to be updated to handle this, but for now I am using the following patch to force _plat_support.so link with X11 (which I think is always present in the default search path): --------------------------- @@ -230,6 +144,7 @@ elif plat in ['x11','gtk1']: x11_info = get_info('x11', notfound_action=1) dict_append(plat_info, **x11_info) + dict_append(plat_info, libraries = ['X11']) --------------------------- With this everything seems to be working fine! Thanks, Varun [1] https://wiki.ubuntu.com/MultiarchSpec On Mon, Jul 11, 2011 at 10:53 PM, Ilan Schnell <ischnell(a)enthought.com> wrote: > Hello Varun, > > the important part is: _plat_support.so: undefined symbol: XCreateImage > This indicates that the kiva/agg/_plat_support.so C extension was > not linked to X11 while compiling. Until > https://github.com/enthought/enable/commit/ebecdbfc5c4596282204e61ff687c3ab… > which was made shortly after the release, it was easy to create a broken > Enable build like this one. Note that this commit does *not* fix the problem, > it only causes the build to fail right away, instead of creating a broken build. > This was added because of the famous esr quote: > "When you must fail, fail noisily and as soon as possible." > > As enable uses numpy.distutils to build agg, the fix is to edit: > <python prefix>/lib/python2.6/site-packages/numpy/distutils/site.cfg > > and add: > [x11] > library_dirs = ... > include_dirs = ... > > - Ilan > > > On Mon, Jul 11, 2011 at 9:23 PM, Varun Hiremath <varunhiremath(a)gmail.com> wrote: >> Hi all, >> >> I am facing another issue running chaco examples with the new ETS 4.0 >> packages. I am getting the following error when I run any chaco >> example: >> -------------------------- >> $$ python zoom_plot.py >> /usr/lib/python2.6/dist-packages/enable/wx/image.py:16: Warning: Error initializing Agg: /usr/lib/python2.6/dist-packages/kiva/agg/_plat_support.so: undefined symbol: XCreateImage >> from kiva.agg import CompiledPath, GraphicsContextSystem as GraphicsContext >> Traceback (most recent call last): >> File "zoom_plot.py", line 15, in <module> >> from enable.api import Component, ComponentEditor >> File "/usr/lib/python2.6/dist-packages/enable/api.py", line 42, in <module> >> from graphics_context import GraphicsContextEnable, ImageGraphicsContextEnable >> File "/usr/lib/python2.6/dist-packages/enable/graphics_context.py", line 86, in <module> >> class GraphicsContextEnable(EnableGCMixin, GraphicsContext): >> TypeError: Error when calling the metaclass bases >> metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases >> ------------------------- >> >> Does anybody know what could be the problem? >> >> Thanks, >> Varun >> >> p.s. Most of the ETS 4.0 debian packages are now available in debian unstable. >> >> >> On Sat, 09 Jul, 2011 at 12:45:32PM -0500, Ilan Schnell wrote: >>> I'm glad it worked. That's a good idea, I'll release traitsui-4.0.1 >>> later today. >>> >>> - Ilan >>> >>> >>> On Sat, Jul 9, 2011 at 11:20 AM, Varun Hiremath <varunhiremath(a)gmail.com> wrote: >>> > Hi Ilan, >>> > >>> > Thanks, that worked! Are you planning on doing a point release for >>> > traitsui to fix this bug? It would make packaging easier then. >>> > >>> > Thanks, >>> > Varun >>> > >>> > On Sat, 09 Jul, 2011 at 11:11:26AM -0500, Ilan Schnell wrote: >>> >> Hello Varun, >>> >> >>> >> I ran into the same bug when preparing the EPD 7.1 release. >>> >> The fix is commited to the github master of traitsui: >>> >> https://github.com/enthought/traitsui/commit/4f36a8a27cfa131347dd90d1a8e10a… >>> >> >>> >> Just replace the two zip-files with the fixed ones, and it should work. >>> >> >>> >> - Ilan >>> >> >>> >> >>> >> On Sat, Jul 9, 2011 at 10:27 AM, Varun Hiremath <varunhiremath(a)gmail.com> wrote: >>> >> > Hi, >>> >> > >>> >> > I was trying to update the debian packages to the new ETS 4.0 release, >>> >> > but I am having some trouble getting mayavi2 running. I get the error >>> >> > shown below when I run mayavi2. Could someone please let me know what >>> >> > might be causing this error? >>> >> > >>> >> > Thanks, >>> >> > Varun >>> >> > >>> >> > ----------------- >>> >> > $ mayavi2 >>> >> > Traceback (most recent call last): >>> >> > File "/usr/bin/mayavi2", line 658, in <module> >>> >> > main() >>> >> > File "/usr/bin/mayavi2", line 649, in main >>> >> > mayavi.main(sys.argv[1:]) >>> >> > File "/usr/lib/python2.6/dist-packages/mayavi/plugins/app.py", line 195, in main >>> >> > app.run() >>> >> > File "/usr/lib/python2.6/dist-packages/mayavi/plugins/mayavi_workbench_application.py", line 81, in run >>> >> > window.open() >>> >> > File "/usr/lib/python2.6/dist-packages/pyface/workbench/workbench_window.py", line 144, in open >>> >> > self._create() >>> >> > File "/usr/lib/python2.6/dist-packages/pyface/ui/wx/application_window.py", line 150, in _create >>> >> > contents = self._create_contents(body) >>> >> > File "/usr/lib/python2.6/dist-packages/pyface/workbench/workbench_window.py", line 217, in _create_contents >>> >> > contents = self.layout.create_initial_layout(parent) >>> >> > File "/usr/lib/python2.6/dist-packages/pyface/ui/wx/workbench/workbench_window_layout.py", line 151, in create_initial_layout >>> >> > self._wx_view_dock_window = WorkbenchDockWindow(parent) >>> >> > File "/usr/lib/python2.6/dist-packages/pyface/dock/dock_window.py", line 324, in __init__ >>> >> > if self.theme.use_theme_color: >>> >> > File "/usr/lib/python2.6/dist-packages/pyface/dock/dock_window.py", line 335, in _theme_default >>> >> > return dock_window_theme() >>> >> > File "/usr/lib/python2.6/dist-packages/traitsui/dock_window_theme.py", line 92, in dock_window_theme >>> >> > from .default_dock_window_theme import default_dock_window_theme >>> >> > File "/usr/lib/python2.6/dist-packages/traitsui/default_dock_window_theme.py", line 39, in <module> >>> >> > label = ( 0, -3 ), content = ( 7, 6, 0, 0 ) ), >>> >> > File "/usr/lib/python2.6/dist-packages/traitsui/theme.py", line 63, in __init__ >>> >> > self.image = image >>> >> > File "/usr/lib/python2.6/dist-packages/traitsui/ui_traits.py", line 229, in validate >>> >> > self.error( object, name, value ) >>> >> > File "/usr/lib/python2.6/dist-packages/traits/trait_handlers.py", line 168, in error >>> >> > value ) >>> >> > traits.trait_errors.TraitError: The 'image' trait of a Theme instance must be an ImageResource or string that can be used to define one, but a value of '@std:tab_active' <type 'str'> was specified. >>> >> > Exception in thread Thread-1: >>> >> > Traceback (most recent call last): >>> >> > File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner >>> >> > self.run() >>> >> > File "/usr/lib/python2.6/threading.py", line 484, in run >>> >> > self.__target(*self.__args, **self.__kwargs) >>> >> > File "/usr/lib/python2.6/dist-packages/traitsui/image/image.py", line 329, in _process >>> >> > if time() > (self.time_stamp + 2.0): >>> >> > TypeError: 'NoneType' object is not callable >>> >> > --------------- >>> >> > _______________________________________________ >>> >> > Enthought-Dev mailing list >>> >> > Enthought-Dev(a)mail.enthought.com >>> >> > https://mail.enthought.com/mailman/listinfo/enthought-dev >>> >> > >>> >> _______________________________________________ >>> >> Enthought-Dev mailing list >>> >> Enthought-Dev(a)mail.enthought.com >>> >> https://mail.enthought.com/mailman/listinfo/enthought-dev >>> > _______________________________________________ >>> > Enthought-Dev mailing list >>> > Enthought-Dev(a)mail.enthought.com >>> > https://mail.enthought.com/mailman/listinfo/enthought-dev >>> > >>> _______________________________________________ >>> Enthought-Dev mailing list >>> Enthought-Dev(a)mail.enthought.com >>> https://mail.enthought.com/mailman/listinfo/enthought-dev >> _______________________________________________ >> Enthought-Dev mailing list >> Enthought-Dev(a)mail.enthought.com >> https://mail.enthought.com/mailman/listinfo/enthought-dev >> > _______________________________________________ > Enthought-Dev mailing list > Enthought-Dev(a)mail.enthought.com > https://mail.enthought.com/mailman/listinfo/enthought-dev > _______________________________________________ Enthought-Dev mailing list Enthought-Dev(a)mail.enthought.com https://mail.enthought.com/mailman/listinfo/enthought-dev

3 2

ANN: NumPy 1.6.1 release candidate 2
by Ralf Gommers 15 Jul '11

15 Jul '11

Hi, I am pleased to announce the availability (only a little later than planned) of the second release candidate of NumPy 1.6.1. This is a bugfix release, list of fixed bugs: #1834 einsum fails for specific shapes #1837 einsum throws nan or freezes python for specific array shapes #1838 object <-> structured type arrays regression #1851 regression for SWIG based code in 1.6.0 #1863 Buggy results when operating on array copied with astype() #1870 Fix corner case of object array assignment #1843 Py3k: fix error with recarray #1885 nditer: Error in detecting double reduction loop #1874 f2py: fix --include_paths bug #1749 Fix ctypes.load_library() If no new problems are reported, the final release will be in one week. Sources and binaries can be found at https://sourceforge.net/projects/numpy/files/NumPy/1.6.1rc2/ Enjoy, Ralf

7 14