[Numpy-discussion] test code for user defined types in numpy

Mark Wiebe mwwiebe at gmail.com
Wed Dec 21 00:10:56 EST 2011

On Tue, Dec 20, 2011 at 6:24 PM, Geoffrey Irving <irving at naml.us> wrote:

> Hello,
> As a followup to the prior thread on bugs in user defined types in
> numpy, I converted my rational number class from C++ to C and switched
> to 32 bits to remove the need for unportable 128 bit numbers.  It
> should be usable as a fairly thorough test case for user defined types
> now.  It does rather more than a minimal test case would need to do,
> but that isn't a problem unless you're concerned about code size.  Let
> me know if any further changes are needed before it's suitable for
> inclusion in numpy as a test case.  The repository is here:
>    https://github.com/girving/rational
> The tests run under either py.test or nose.
> For completeness, my branch fixing all but one of the bugs I found in
> numpy user defined types is here:
>    https://github.com/girving/numpy/tree/fixuserloops
> The remaining bug is that numpy incorrectly releases the GIL during
> casts even though NPY_NEEDS_API is set.  The resulting crash goes away
> if the line defining ACQUIRE_GIL is uncommented.  With the necessary
> locks in place, all my tests pass with my branch of numpy.  I haven't
> tracked this one down and fixed it yet, but it shouldn't be hard to do
> so.

Looks great. I've added some comments to the pull request for the
fixuserloops branch, which is here:


I would advise anyone with an interest in the low-level aspects of how
NumPy's handling of the GIL and multi-threading/concurrency should evolve
to take a look. Prior to anything I contributed, NumPy hardcoded whether to
release the GIL during ufuncs or not. I added a needs_api flag in a few
places to indicate whether the inner loop functions call the CPython API or
not. Note that for ABI compatibility reasons, this flag is not 100%
correctly integrated throughout NumPy.

What Geoffrey is proposing here conflicts with the way I imagined the flag
would be used, but supporting both of our ways of calling the inner loop
seems useful to me. Take a look at the pull request for more details.


> Geoffrey
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20111220/c315f69f/attachment.html>

More information about the NumPy-Discussion mailing list