On Thu, Sep 20, 2012 at 4:50 AM, Richard Hattersley <rhattersley@gmail.com> wrote:

Hi,

[First of all - thanks to everyone involved in the 1.7 release. Especially Ondřej - it takes a lot of time & energy to coordinate something like this.]

Is there an up to date release schedule anywhere? The trac milestone still references June.

Well, originally we were supposed to release about a month ago, but it turned out there are more things to fix. Currently, we just need to fix all the issues here: https://github.com/numpy/numpy/issues/396 it looks like a lot, but many of them are really easy to fix, so my hope is that it will not take long. The hardest one is this: http://projects.scipy.org/numpy/ticket/2108 if anyone wants to help with this one, that'd be very much appreciated. After these are fixed, the rc1 (possibly rc2) and the final release should go quickly, as I already know how to make the binaries easily. Ondrej

On Thu, Sep 20, 2012 at 12:00 PM, Nathaniel Smith <njs@pobox.com> wrote:

On Thu, Sep 20, 2012 at 3:33 PM, Ondřej Čertík <ondrej.certik@gmail.com> wrote:

...

On Thu, Sep 20, 2012 at 4:50 AM, Richard Hattersley <rhattersley@gmail.com> wrote:

...

Hi,

[First of all - thanks to everyone involved in the 1.7 release. Especially Ondřej - it takes a lot of time & energy to coordinate something like this.]

Is there an up to date release schedule anywhere? The trac milestone still references June.

Well, originally we were supposed to release about a month ago, but it turned out there are more things to fix. Currently, we just need to fix all the issues here:

https://github.com/numpy/numpy/issues/396

it looks like a lot, but many of them are really easy to fix, so my hope is that it will not take long. The hardest one is this:

http://projects.scipy.org/numpy/ticket/2108

if anyone wants to help with this one, that'd be very much appreciated.

This particular bug should actually be pretty trivial to fix if anyone is looking for something to do (esp. if you have a working win32 build environment to test your work): http://thread.gmane.org/gmane.comp.python.numeric.general/50950/focus=50980

Ah, that looks easy. I'll try to give it a shot. See my repo here how to get a working win32 environment: https://github.com/certik/numpy-vendor However, I don't have access to MSVC, but I am sure somebody else can test it there, once the PR is ready. Ondrej

On Mon, Sep 24, 2012 at 2:25 PM, Frédéric Bastien <nouiz@nouiz.org> wrote:

Hi,

I tested this new beta on Theano and discovered an interface change that was not there in the beta 1.

New behavior: numpy.ndindex().next() (0,)

Old behavior: numpy.ndindex().next() ()

This break some Theano code that look like this:

import numpy shape=() out_shape=[12] random_state=numpy.random.RandomState()

out = numpy.zeros(out_shape, int) for i in numpy.ndindex(*shape): out[i] = random_state.permutation(5)

I suppose this is an regression as the only mention of ndindex in the first email of this change is that it is faster.

I think this problem has been brought up on the list. It is interesting that it turned up after the first beta. Could you do a bisection to discover which commit is responsible?

There is a second "regression" in ndindex This was working in the past, but it raise an ValueError now:

numpy.ndindex((2,1,1,1))

But If I call numpy.ndindex(2,1,1,1)

The documentation[1] do not talk about receiving a tuple as input. I already make a commit to change Theano code to make it work. But this could break other people code. It is up to you to decide if you want this, but a warning in the release note would be great to help people know that the old not documented behavior changed.

Do you know if the first change is expected? This will probably cause bad results in some people code if you intended this change.

Chuck

25.09.2012 00:55, Frédéric Bastien kirjoitti:

On Mon, Sep 24, 2012 at 5:47 PM, Charles R Harris [clip]

...

I think this problem has been brought up on the list. It is interesting that it turned up after the first beta. Could you do a bisection to discover which commit is responsible?

I'll check that. Do I need to reinstall numpy from scratch everytimes or is there a better way to do that?

Reinstallation is needed, but this is reasonably simple to automate, check "git bisect run". For instance like so: https://github.com/pv/scipy-build-makefile/blob/master/bisectrun.py -- Pauli Virtanen

On Mon, Sep 24, 2012 at 10:47 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:

On Mon, Sep 24, 2012 at 2:25 PM, Frédéric Bastien <nouiz@nouiz.org> wrote:

...

Hi,

I tested this new beta on Theano and discovered an interface change that was not there in the beta 1.

New behavior: numpy.ndindex().next() (0,)

Old behavior: numpy.ndindex().next() ()

This break some Theano code that look like this:

import numpy shape=() out_shape=[12] random_state=numpy.random.RandomState()

out = numpy.zeros(out_shape, int) for i in numpy.ndindex(*shape): out[i] = random_state.permutation(5)

I suppose this is an regression as the only mention of ndindex in the first email of this change is that it is faster.

I think this problem has been brought up on the list. It is interesting that it turned up after the first beta. Could you do a bisection to discover which commit is responsible?

No need, the problem is already known. It was introduced by that ndindex speed up patch, PR #393, which was backported into the first beta as well. There's a follow-up patch in PR #445 that fixes both of these issues, though it also exposes some more fundamental issues with the nditer API, so there's lots of discussion there about if we want some more changes... this is a good summary: https://github.com/numpy/numpy/pull/445#issuecomment-8740982 For 1.7 purposes though the bottom line is that we already have multiple acceptable solutions, so both the issues reported here should definitely be fixed. -n

On Tue, Sep 25, 2012 at 1:27 AM, Ondřej Čertík <ondrej.certik@gmail.com> wrote:

On Mon, Sep 24, 2012 at 3:49 PM, Nathaniel Smith <njs@pobox.com> wrote:

...

On Mon, Sep 24, 2012 at 10:47 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:

...

On Mon, Sep 24, 2012 at 2:25 PM, Frédéric Bastien <nouiz@nouiz.org> wrote:

...

Hi,

I tested this new beta on Theano and discovered an interface change that was not there in the beta 1.

New behavior: numpy.ndindex().next() (0,)

Old behavior: numpy.ndindex().next() ()

This break some Theano code that look like this:

import numpy shape=() out_shape=[12] random_state=numpy.random.RandomState()

out = numpy.zeros(out_shape, int) for i in numpy.ndindex(*shape): out[i] = random_state.permutation(5)

I suppose this is an regression as the only mention of ndindex in the first email of this change is that it is faster.

I think this problem has been brought up on the list. It is interesting that it turned up after the first beta. Could you do a bisection to discover which commit is responsible?

No need, the problem is already known. It was introduced by that ndindex speed up patch, PR #393, which was backported into the first beta as well. There's a follow-up patch in PR #445 that fixes both of these issues, though it also exposes some more fundamental issues with the nditer API, so there's lots of discussion there about if we want some more changes... this is a good summary: https://github.com/numpy/numpy/pull/445#issuecomment-8740982

For 1.7 purposes though the bottom line is that we already have multiple acceptable solutions, so both the issues reported here should definitely be fixed.

Should we just remove (revert) this PR #393 patch from the release branch? It shouldn't have been there in the first place, the only reason I included it is because other patches depended on it and I would have to fix collisions, and we thought it would be harmless to just include it. Which turned out to be a mistake, for which I apologize.

That way we'll feel confident that the branch works, and we can get the right solution into master and test it there.

So I am actually convinced I should simply revert this patch in the release branch. Let me know what you think.

Sounds good to me. (I also thought it would be harmless to include it, and also missed that the other patch that depended on it was part of the same change and could be reverted too.) -n

On Tue, Sep 25, 2012 at 8:56 AM, Charles R Harris <charlesr.harris@gmail.com

wrote:

On Thu, Sep 20, 2012 at 12:24 AM, Ondřej Čertík <ondrej.certik@gmail.com>wrote:

...

Hi,

I'm pleased to announce the availability of the second beta release of NumPy 1.7.0b2.

Sources and binary installers can be found at https://sourceforge.net/projects/numpy/files/NumPy/1.7.0b2/

Please test this release and report any issues on the numpy-discussion mailing list. Since beta1, we've fixed most of the known (back then) issues, except:

http://projects.scipy.org/numpy/ticket/2076 http://projects.scipy.org/numpy/ticket/2101 http://projects.scipy.org/numpy/ticket/2108 http://projects.scipy.org/numpy/ticket/2150

And many other issues that were reported since the beta1 release. The log of changes is attached. The full list of issues that we still need to work on is at:

https://github.com/numpy/numpy/issues/396

Any help is welcome, the best is to send a PR fixing any of the issues -- against master, and I'll then back-port it to the release branch (unless it is something release specific, in which case just send the PR against the release branch).

Cheers, Ondrej

* f217517 Release 1.7.0b2 * 50f71cb MAINT: silence Cython warnings about changes dtype/ufunc size. * fcacdcc FIX: use py24-compatible version of virtualenv on Travis * d01354e FIX: loosen numerical tolerance in test_pareto() * 65ec87e TST: Add test for boolean insert * 9ee9984 TST: Add extra test for multidimensional inserts. * 8460514 BUG: Fix for issues #378 and #392 This should fix the problems with numpy.insert(), where the input values were not checked for all scalar types and where values did not get inserted properly, but got duplicated by default. * 07e02d0 BUG: fix npymath install location. * 6da087e BUG: fix custom post_check. * 095a3ab BUG: forgot to build _dotblas in bento build. * cb0de72 REF: remove unused imports in bscript. * 6e3e289 FIX: Regenerate mtrand.c with Cython 0.17 * 3dc3b1b Retain backward compatibility. Enforce C order. * 5a471b5 Improve ndindex execution speed. * 2f28db6 FIX: Add a test for Ticket #2066 * ca29849 BUG: Add a test for Ticket #2189 * 1ee4a00 BUG: Add a test for Ticket #1588 * 7b5dba0 BUG: Fix ticket #1588/gh issue #398, refcount error in clip * f65ff87 FIX: simplify the import statement * 124a608 Fix returned copy * 996a9fb FIX: bug in np.where and recarray swapping * 7583adc MAINT: silence DeprecationWarning in np.safe_eval(). * 416af9a pavement.py: rename "yop" to "atlas" * 3930881 BUG: fix bento build. * fbad4a7 Remove test_recarray_from_long_formats * 5cb80f8 Add test for long number in shape specifier of dtype string * 24da7f6 Add test for long numbers in numpy.rec.array formats string * 77da3f8 Allow long numbers in numpy.rec.array formats string * 99c9397 Use PyUnicode_DecodeUTF32() * 31660d0 Follow the C guidelines * d5d6894 Fix memory leak in concatenate. * 8141e1e FIX: Make sure the tests produce valid unicode * d67785b FIX: Fixes the PyUnicodeObject problem in py-3.3 * a022015 Re-enable unpickling optimization for large py3k bytes objects. * 470486b Copy bytes object when unpickling an array * d72280f Fix tests for empty shape, strides and suboffsets on Python 3.3 * a1561c2 [FIX] Add missing header so separate compilation works again * ea23de8 TST: set raise-on-warning behavior of NoseTester to release mode. * 28ffac7 REL: set version number to 1.7.0rc1-dev.

Ticket #2218 needs to be fixed.

The all method fails also. In [1]: a = zeros(5, complex) In [2]: a.imag = 1 In [3]: a.all() Out[3]: False Chuck