[Numpy-discussion] Code Freeze for NumPy 1.7

Sun Jul 15 13:18:34 EDT 2012

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.harris at gmail.com> wrote:

>
>
> On Sun, Jul 15, 2012 at 10:56 AM, David Cournapeau <cournape at gmail.com>wrote:
>
>> On Sun, Jul 15, 2012 at 5:42 PM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>> >
>> >
>> > On Sun, Jul 15, 2012 at 10:32 AM, Ralf Gommers <
>> ralf.gommers at googlemail.com>
>> > wrote:
>> >>
>> >>
>> >>
>> >> On Sun, Jul 15, 2012 at 5:57 PM, Nathaniel Smith <njs at pobox.com>
>> wrote:
>> >>>
>> >>> On Sun, Jul 15, 2012 at 1:08 PM, Ralf Gommers
>> >>> <ralf.gommers at googlemail.com> wrote:
>> >>> >
>> >>> >
>> >>> > On Sun, Jul 15, 2012 at 12:45 AM, Travis Oliphant <
>> travis at 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 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/20120715/90e60d87/attachment.html>