[Numpy-discussion] Open CV 3.0 + NPY_RELAXED_STRIDES

[Jaime Fernández del Río]

I'm in the midst of a Python 3.5 + MSVS 2015 compilation frenzy. Today it
was time for Open CV 3.0, where I found a nasty bug that I have eventually
tracked down to using a development version of NumPy, and Open CV 3.0
choking on relaxed strides, as it does a check that every stride is a
multiple of the itemsize.

I was thinking of submitting a patch to opencv to fix this, but was
wondering whether we have plans to eventually have relaxed strides out in
the wild in user releases, or is it just a testing tool for development?

Jaime

[Jaime Fernández del Río]

On Wed, Jun 10, 2015 at 5:53 PM, Jaime Fernández del Río <

Post by Jaime Fernández del Río
I'm in the midst of a Python 3.5 + MSVS 2015 compilation frenzy. Today it
was time for Open CV 3.0, where I found a nasty bug that I have eventually
tracked down to using a development version of NumPy, and Open CV 3.0
choking on relaxed strides, as it does a check that every stride is a
multiple of the itemsize.
I was thinking of submitting a patch to opencv to fix this, but was
wondering whether we have plans to eventually have relaxed strides out in
the wild in user releases, or is it just a testing tool for development?

I see that in the release notes of 1.9 we had the following:


- Relaxed stride checking will be the default in 1.10.0

Is this still the plan?

Jaime

[Charles R Harris]

On Wed, Jun 10, 2015 at 7:02 PM, Jaime Fernández del Río <

Post by Jaime Fernández del Río
On Wed, Jun 10, 2015 at 5:53 PM, Jaime Fernández del Río <

Post by Jaime Fernández del Río
I'm in the midst of a Python 3.5 + MSVS 2015 compilation frenzy. Today it
was time for Open CV 3.0, where I found a nasty bug that I have eventually
tracked down to using a development version of NumPy, and Open CV 3.0
choking on relaxed strides, as it does a check that every stride is a
multiple of the itemsize.
I was thinking of submitting a patch to opencv to fix this, but was
wondering whether we have plans to eventually have relaxed strides out in
the wild in user releases, or is it just a testing tool for development?

- Relaxed stride checking will be the default in 1.10.0
Is this still the plan?

Yes, but it won't be quite the same as the master branch. Currently an
unusual value for the stride (?) is used in order to smoke out misuse, but
that value will be more rational in the release.

Chuck

[Sebastian Berg]

On Mi, 2015-06-10 at 21:03 -0600, Charles R Harris wrote:
<snip>

* Relaxed stride checking will be the default in 1.10.0
Is this still the plan?
Yes, but it won't be quite the same as the master branch. Currently
an unusual value for the stride (?) is used in order to smoke out
misuse, but that value will be more rational in the release.

+1, it should not be as bad/common in practice once rolled out. That
said, I do not mind delaying things beyond 1.10, it might be better for
compatibility if someone gets a new numpy on top of oldish other
packages.
So I am good with planning to go ahead for the moment. But if anyone
complains, I would back down for 1.10 probably.

- Sebastian

Chuck
_______________________________________________
NumPy-Discussion mailing list
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Julian Taylor]

On Thu, Jun 11, 2015 at 11:39 AM, Sebastian Berg

Post by Sebastian Berg
<snip>

* Relaxed stride checking will be the default in 1.10.0
Is this still the plan?
Yes, but it won't be quite the same as the master branch. Currently
an unusual value for the stride (?) is used in order to smoke out
misuse, but that value will be more rational in the release.

+1, it should not be as bad/common in practice once rolled out. That
said, I do not mind delaying things beyond 1.10, it might be better for
compatibility if someone gets a new numpy on top of oldish other
packages.
So I am good with planning to go ahead for the moment. But if anyone
complains, I would back down for 1.10 probably.
- Sebastian

With beside scipy.ndimage also opencv being broken I think we will
have to delay it beyond 1.10, though we should have at least an alpha,
maybe even a beta with it enabled to induce some panic that hopefully
will spure some fixes.

[Jaime Fernández del Río]

On Thu, Jun 11, 2015 at 2:44 AM, Julian Taylor <

Post by Julian Taylor
On Thu, Jun 11, 2015 at 11:39 AM, Sebastian Berg

Post by Sebastian Berg
<snip>

* Relaxed stride checking will be the default in 1.10.0
Is this still the plan?
Yes, but it won't be quite the same as the master branch. Currently
an unusual value for the stride (?) is used in order to smoke out
misuse, but that value will be more rational in the release.

+1, it should not be as bad/common in practice once rolled out. That
said, I do not mind delaying things beyond 1.10, it might be better for
compatibility if someone gets a new numpy on top of oldish other
packages.
So I am good with planning to go ahead for the moment. But if anyone
complains, I would back down for 1.10 probably.
- Sebastian

With beside scipy.ndimage also opencv being broken I think we will
have to delay it beyond 1.10, though we should have at least an alpha,
maybe even a beta with it enabled to induce some panic that hopefully
will spure some fixes.

OpenCV shouldn't be broken any more if the merge this:

https://github.com/Itseez/opencv/pull/4117

I would appreciate a second set of eyes looking over the logic in that PR.

Jaime

[Nathaniel Smith]

On Wed, Jun 10, 2015 at 5:53 PM, Jaime Fernández del Río

Post by Jaime Fernández del Río
I'm in the midst of a Python 3.5 + MSVS 2015 compilation frenzy. Today it
was time for Open CV 3.0, where I found a nasty bug that I have eventually
tracked down to using a development version of NumPy, and Open CV 3.0
choking on relaxed strides, as it does a check that every stride is a
multiple of the itemsize.
I was thinking of submitting a patch to opencv to fix this, but was
wondering whether we have plans to eventually have relaxed strides out in
the wild in user releases, or is it just a testing tool for development?

The ultimate goal is certainly to get it out into the wild, as not
having relaxed strides creates other weird bugs instead. (Mostly
spurious copies because of arrays being considered discontiguous when
they actually were contiguous all along, but also fun stuff like tiny
irrelevant changes in numpy breaking people's code because they are
expecting an array with F contiguity and numpy has started describing
the output array as C contiguity, when in fact it is both and the bug
is entirely in the arbitrary assignment of these flags.)

-n