On Tue, Dec 20, 2011 at 6:24 PM, Geoffrey Irving <irv...@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: https://github.com/numpy/numpy/pull/175 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. Cheers, Mark > > Geoffrey > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
