Just added PR #359. The purpose is to allow the nditer object operand and iter flags to be set for a ufunc to provide better control over how an array is iterated over by a ufunc and how the ufunc uses the operands passed to it. One specific motivation for this is to be able to specify an input operand to a ufunc as being read/write instead of read only. For example, to allow your ufunc to write back to the first operand:
PyObject *ufunc = PyUFunc_FromFuncAndData((PyUFuncGenericFunction*)func, data, types, 1, 2, 1, PyUFunc_None, "ufunc_name", "ufunc_doc", 0); /* override the default NPY_ITER_READONLY flag */ ((PyUFuncObject*)ufunc)->op_flags[0] = NPY_ITER_READWRITE; /* global iter flag that needs to be set for read/write flag to work */ ((PyUFuncObject*)ufunc)->iter_flags = NPY_ITER_REDUCE_OK; Thoughts? -Jay On Sun, Jul 15, 2012 at 12:10 PM, Charles R Harris < charlesr.har...@gmail.com> wrote: > > > On Sun, Jul 15, 2012 at 10:56 AM, David Cournapeau <courn...@gmail.com>wrote: > >> On Sun, Jul 15, 2012 at 5:42 PM, Charles R Harris >> <charlesr.har...@gmail.com> wrote: >> > >> > >> > On Sun, Jul 15, 2012 at 10:32 AM, Ralf Gommers < >> ralf.gomm...@googlemail.com> >> > wrote: >> >> >> >> >> >> >> >> On Sun, Jul 15, 2012 at 5:57 PM, Nathaniel Smith <n...@pobox.com> >> wrote: >> >>> >> >>> On Sun, Jul 15, 2012 at 1:08 PM, Ralf Gommers >> >>> <ralf.gomm...@googlemail.com> wrote: >> >>> > >> >>> > >> >>> > On Sun, Jul 15, 2012 at 12:45 AM, Travis Oliphant < >> tra...@continuum.io> >> >>> > wrote: >> >>> >> >> >>> >> >> >>> >> Hey all, >> >>> >> >> >>> >> We are nearing a code-freeze for NumPy 1.7. Are there any >> >>> >> last-minute >> >>> >> changes people are wanting to push into NumPy 1.7? We should >> discuss >> >>> >> them >> >>> >> as soon as possible. >> >>> >> >> >>> >> I'm proposing a code-freeze at midnight UTC on July 18th (7:00pm >> CDT >> >>> >> on >> >>> >> July 17th). This will allow the creation of beta releases of >> NumPy >> >>> >> on the >> >>> >> 18th of July. This is a few days later than originally hoped for >> --- >> >>> >> largely >> >>> >> due to unexpected travel schedules of Ondrej and I, but it does >> give >> >>> >> people >> >>> >> a few more days to get patches in. Of course, we will be able to >> >>> >> apply >> >>> >> bug-fixes to the 1.7.x branch once the tag is made. >> >>> > >> >>> > >> >>> > What about the tickets still open for 1.7.0 >> >>> > (http://projects.scipy.org/numpy/report/3)? There are a few >> important >> >>> > ones >> >>> > left. >> >>> > >> >>> > These I would consider blockers: >> >>> > - #2108 Datetime failures with MinGW >> >>> >> >>> Is there a description anywhere of what the problem actually is here? >> >>> I looked at the ticket, which referred to a PR, and it's hard to work >> >>> out from the PR discussion what the actual remaining test failures are >> >>> -- and there definitely doesn't seem to be any description of the >> >>> underlying problem. (Something about working 64-bit time_t on windows >> >>> being difficult depending on the compiler used?) >> >> >> >> >> >> There's a lot more discussion on >> >> http://projects.scipy.org/numpy/ticket/1909 >> >> https://github.com/numpy/numpy/pull/156 >> >> https://github.com/numpy/numpy/pull/161. >> >> >> >> The issue is that for MinGW 3.x some _s / _t functions seem to be >> missing. >> >> And we don't yet support MinGW 4.x. >> >> >> >> Current issues can be seen from the last test log on our Windows XP >> >> buildbot (June 29, >> >> >> http://buildbot.scipy.org/builders/Windows_XP_x86/builds/1124/steps/shell_1/logs/stdio >> ): >> >> >> >> ====================================================================== >> >> ERROR: test_datetime_arange (test_datetime.TestDateTime) >> >> ---------------------------------------------------------------------- >> >> Traceback (most recent call last): >> >> File >> >> >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_datetime.py", >> >> line 1351, in test_datetime_arange >> >> assert_raises(ValueError, np.arange, np.datetime64('today'), >> >> OSError: Failed to use '_localtime64_s' to convert to a local time >> >> >> >> ====================================================================== >> >> ERROR: test_datetime_y2038 (test_datetime.TestDateTime) >> >> ---------------------------------------------------------------------- >> >> Traceback (most recent call last): >> >> File >> >> >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_datetime.py", >> >> line 1706, in test_datetime_y2038 >> >> a = np.datetime64('2038-01-20T13:21:14') >> >> OSError: Failed to use '_gmtime64_s' to convert to a UTC time >> >> >> >> ====================================================================== >> >> ERROR: test_pydatetime_creation (test_datetime.TestDateTime) >> >> ---------------------------------------------------------------------- >> >> Traceback (most recent call last): >> >> File >> >> >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_datetime.py", >> >> line 467, in test_pydatetime_creation >> >> a = np.array(['today', datetime.date.today()], dtype='M8[D]') >> >> OSError: Failed to use '_localtime64_s' to convert to a local time >> >> >> >> ====================================================================== >> >> ERROR: test_string_parser_variants (test_datetime.TestDateTime) >> >> ---------------------------------------------------------------------- >> >> Traceback (most recent call last): >> >> File >> >> >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_datetime.py", >> >> line 1054, in test_string_parser_variants >> >> assert_equal(np.array(['1980-02-29T01:02:03'], np.dtype('M8[s]')), >> >> OSError: Failed to use '_gmtime64_s' to convert to a UTC time >> >> >> >> ====================================================================== >> >> ERROR: test_timedelta_scalar_construction_units >> >> (test_datetime.TestDateTime) >> >> ---------------------------------------------------------------------- >> >> Traceback (most recent call last): >> >> File >> >> >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_datetime.py", >> >> line 287, in test_timedelta_scalar_construction_units >> >> assert_equal(np.datetime64('2010-03-12T17').dtype, >> >> OSError: Failed to use '_gmtime64_s' to convert to a UTC time >> >> >> >> ====================================================================== >> >> ERROR: Failure: OSError (Failed to use '_gmtime64_s' to convert to a >> UTC >> >> time) >> >> ---------------------------------------------------------------------- >> >> Traceback (most recent call last): >> >> File "C:\Python26\lib\site-packages\nose\loader.py", line 382, in >> >> loadTestsFromName >> >> addr.filename, addr.module) >> >> File "C:\Python26\lib\site-packages\nose\importer.py", line 39, in >> >> importFromPath >> >> return self.importFromDir(dir_path, fqname) >> >> File "C:\Python26\lib\site-packages\nose\importer.py", line 86, in >> >> importFromDir >> >> mod = load_module(part_fqname, fh, filename, desc) >> >> File >> >> >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_multiarray.py", >> >> line 916, in <module> >> >> class TestArgmax(TestCase): >> >> File >> >> >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_multiarray.py", >> >> line 938, in TestArgmax >> >> np.datetime64('1994-06-21T14:43:15'), >> >> OSError: Failed to use '_gmtime64_s' to convert to a UTC time >> >> >> >> >> > >> > I've wondered about the current status of MinGW 4.x, the mingw.orgrelease >> > of GCC 4.7.0 was June 7. Looks like it is still 32 bits and breaks the >> ABI >> >> The main issue with mingw 4.x is the dependency on mingw runtimes. >> With 3.x, it was possible to statically link everything, but not with >> 4.x. Distributing DLL outside numpy is not a good idea IMO, and I >> don't know how to share DLL across python extensions without putting >> them in the python installation (which does not sound like a good idea >> either). >> >> > Have you looked at TDM <http://tdm-gcc.tdragon.net/>? A cursory look > implies that the std/stdc++ libraries can be statically linked. > > Chuck > > > _______________________________________________ > 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