Re: [Numpy-discussion] Changes to np.digitize since NumPy 1.9?
On Aug 12, 2015 11:12 PM, Jaime Fernández del Río jaime.f...@gmail.com wrote: On Wed, Aug 12, 2015 at 2:03 PM, Nathan Goldbaum nathan12...@gmail.com wrote: Hi all, I've been testing the package I spend most of my time on, yt, under numpy 1.10b1 since the announcement went out. I think I've narrowed down and fixed all of the test failures that cropped up except for one last issue. It seems that the behavior of np.digitize with respect to ndarray subclasses has changed since the NumPy 1.9 series. Consider the following test script: ```python import numpy as np class MyArray(np.ndarray): def __new__(cls, *args, **kwargs): return np.ndarray.__new__(cls, *args, **kwargs) data = np.arange(100) bins = np.arange(100) + 0.5 data = data.view(MyArray) bins = bins.view(MyArray) digits = np.digitize(data, bins) print type(digits) ``` Under NumPy 1.9.2, this prints type 'numpy.ndarray', but under the 1.10 beta, it prints class '__main__.MyArray' I'm curious why this change was made. Since digitize outputs index arrays, it doesn't make sense to me why it should return anything but a plain ndarray. I see in the release notes that digitize now uses searchsorted under the hood. Is this related? It is indeed searchsorted's fault, as it returns an object of the same type as the needle (the items to search for): import numpy as np class A(np.ndarray): pass class B(np.ndarray): pass np.arange(10).view(A).searchsorted(np.arange(5).view(B)) B([0, 1, 2, 3, 4]) I am all for making index-returning functions always return a base ndarray, and will be more than happy to send a PR fixing this if there is some agreement. Makes sense to me. I won't be surprised if someone else then shows up saying that of course they depend on index array return types matching the input, but if that happens then I guess we can let them and Nathan fight it out :-). -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Changes to np.digitize since NumPy 1.9?
On Wed, Aug 12, 2015 at 2:03 PM, Nathan Goldbaum nathan12...@gmail.com wrote: Hi all, I've been testing the package I spend most of my time on, yt, under numpy 1.10b1 since the announcement went out. I think I've narrowed down and fixed all of the test failures that cropped up except for one last issue. It seems that the behavior of np.digitize with respect to ndarray subclasses has changed since the NumPy 1.9 series. Consider the following test script: ```python import numpy as np class MyArray(np.ndarray): def __new__(cls, *args, **kwargs): return np.ndarray.__new__(cls, *args, **kwargs) data = np.arange(100) bins = np.arange(100) + 0.5 data = data.view(MyArray) bins = bins.view(MyArray) digits = np.digitize(data, bins) print type(digits) ``` Under NumPy 1.9.2, this prints type 'numpy.ndarray', but under the 1.10 beta, it prints class '__main__.MyArray' I'm curious why this change was made. Since digitize outputs index arrays, it doesn't make sense to me why it should return anything but a plain ndarray. I see in the release notes that digitize now uses searchsorted under the hood. Is this related? It is indeed searchsorted's fault, as it returns an object of the same type as the needle (the items to search for): import numpy as np class A(np.ndarray): pass class B(np.ndarray): pass np.arange(10).view(A).searchsorted(np.arange(5).view(B)) B([0, 1, 2, 3, 4]) I am all for making index-returning functions always return a base ndarray, and will be more than happy to send a PR fixing this if there is some agreement. Jaime -- (\__/) ( O.o) ( ) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] ANN: Numpy 1.10.0b1 release
Hi,
On Wed, Aug 12, 2015 at 12:23 PM, Sebastian Berg
sebast...@sipsolutions.net wrote:
On Mi, 2015-08-12 at 01:07 -0700, Nathaniel Smith wrote:
On Wed, Aug 12, 2015 at 12:51 AM, Sebastian Berg
sebast...@sipsolutions.net wrote:
On Mi, 2015-08-12 at 09:41 +0200, Jens Jørgen Mortensen wrote:
On 08/11/2015 11:23 PM, Charles R Harris wrote:
Hi All,
give this release a whirl and report any problems either on the
numpy-discussion list or by opening an issue on github.
I'm pleased to announce the first beta release of Numpy 1.10.0.
There is over a year's worth of enhancements and bug fixes in the
1.10.0 release, so please give this release a whirl and report any
problems either on the numpy-discussion list or by opening an issue
on github. Tarballs, installers, and release notes may be found in
the usual place at Sourceforge.
I'm getting test errors on the standard OSX numpy / scipy compilation rig:
Python.org Python
OSX 10.9
clang
gfortran 4.2.3
Compiling from the `maintenance/1.10.x` branch (is there a 1.10.0b1 tag)?
==
ERROR: test_accelerate_framework_sgemv_fix (test_multiarray.TestDot)
--
Traceback (most recent call last):
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/core/tests/test_multiarray.py,
line 4218, in test_accelerate_framework_sgemv_fix
m = aligned_array(100, 15, np.float32)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/core/tests/test_multiarray.py,
line 4200, in aligned_array
d = np.dtype()
TypeError: Required argument 'dtype' (pos 1) not found
This one should be fixed by https://github.com/numpy/numpy/pull/6202
==
ERROR: test_callback.TestF77Callback.test_string_callback
--
Traceback (most recent call last):
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/nose/case.py,
line 381, in setUp
try_run(self.inst, ('setup', 'setUp'))
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/nose/util.py,
line 471, in try_run
return func()
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 362, in setUp
module_name=self.module_name)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 79, in wrapper
memo[key] = func(*a, **kw)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 170, in build_code
module_name=module_name)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 79, in wrapper
memo[key] = func(*a, **kw)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 150, in build_module
__import__(module_name)
ImportError:
dlopen(/var/folders/s7/r25pn2xj48n4cm76_mgsb78hgn/T/tmpa39XPB/_test_ext_module_5403.so,
2): Symbol not found: _func0_
Referenced from:
/var/folders/s7/r25pn2xj48n4cm76_mgsb78hgn/T/tmpa39XPB/_test_ext_module_5403.so
Expected in: dynamic lookup
Any ideas about this second one?
Cheers,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Changes to np.digitize since NumPy 1.9?
On Thu, Aug 13, 2015 at 12:09 AM, Jaime Fernández del Río jaime.f...@gmail.com wrote: On Wed, Aug 12, 2015 at 2:03 PM, Nathan Goldbaum nathan12...@gmail.com wrote: Hi all, I've been testing the package I spend most of my time on, yt, under numpy 1.10b1 since the announcement went out. I think I've narrowed down and fixed all of the test failures that cropped up except for one last issue. It seems that the behavior of np.digitize with respect to ndarray subclasses has changed since the NumPy 1.9 series. Consider the following test script: ```python import numpy as np class MyArray(np.ndarray): def __new__(cls, *args, **kwargs): return np.ndarray.__new__(cls, *args, **kwargs) data = np.arange(100) bins = np.arange(100) + 0.5 data = data.view(MyArray) bins = bins.view(MyArray) digits = np.digitize(data, bins) print type(digits) ``` Under NumPy 1.9.2, this prints type 'numpy.ndarray', but under the 1.10 beta, it prints class '__main__.MyArray' I'm curious why this change was made. Since digitize outputs index arrays, it doesn't make sense to me why it should return anything but a plain ndarray. I see in the release notes that digitize now uses searchsorted under the hood. Is this related? It is indeed searchsorted's fault, as it returns an object of the same type as the needle (the items to search for): import numpy as np class A(np.ndarray): pass class B(np.ndarray): pass np.arange(10).view(A).searchsorted(np.arange(5).view(B)) B([0, 1, 2, 3, 4]) I am all for making index-returning functions always return a base ndarray, and will be more than happy to send a PR fixing this if there is some agreement. I think that is the right thing to do. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Changes to np.digitize since NumPy 1.9?
On Thu, Aug 13, 2015 at 9:44 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Aug 13, 2015 at 12:09 AM, Jaime Fernández del Río jaime.f...@gmail.com wrote: On Wed, Aug 12, 2015 at 2:03 PM, Nathan Goldbaum nathan12...@gmail.com wrote: Hi all, I've been testing the package I spend most of my time on, yt, under numpy 1.10b1 since the announcement went out. I think I've narrowed down and fixed all of the test failures that cropped up except for one last issue. It seems that the behavior of np.digitize with respect to ndarray subclasses has changed since the NumPy 1.9 series. Consider the following test script: ```python import numpy as np class MyArray(np.ndarray): def __new__(cls, *args, **kwargs): return np.ndarray.__new__(cls, *args, **kwargs) data = np.arange(100) bins = np.arange(100) + 0.5 data = data.view(MyArray) bins = bins.view(MyArray) digits = np.digitize(data, bins) print type(digits) ``` Under NumPy 1.9.2, this prints type 'numpy.ndarray', but under the 1.10 beta, it prints class '__main__.MyArray' I'm curious why this change was made. Since digitize outputs index arrays, it doesn't make sense to me why it should return anything but a plain ndarray. I see in the release notes that digitize now uses searchsorted under the hood. Is this related? It is indeed searchsorted's fault, as it returns an object of the same type as the needle (the items to search for): import numpy as np class A(np.ndarray): pass class B(np.ndarray): pass np.arange(10).view(A).searchsorted(np.arange(5).view(B)) B([0, 1, 2, 3, 4]) I am all for making index-returning functions always return a base ndarray, and will be more than happy to send a PR fixing this if there is some agreement. I think that is the right thing to do. Awesome, I'd appreciate having a PR to fix this. Arguably the return type *could* be the same type as the inputs, but given that it's a behavior change I agree that it's best to add a patch so the output of serachsorted is sanitized to be an ndarray before it's returned by digitize. To answer Nathaniel's question, I opened an issue on yt's bitbucket page to record the test failures: https://bitbucket.org/yt_analysis/yt/issues/1063/new-test-failures-using-numpy-110-beta I've fixed two of the classes of errors in that bug in yt itself, since it looks like we were relying on buggy or deprecated behavior in NumPy. Here are the PRs for those fixes: https://bitbucket.org/yt_analysis/yt/pull-requests/1697/cast-enzo-grid-start-index-to-int-arrays/diff https://bitbucket.org/yt_analysis/yt/pull-requests/1696/add-assert_allclose_units-like/diff 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
Re: [Numpy-discussion] Development workflow (not git tutorial)
On 2015-08-13 08:52:22, Anne Archibald peridot.face...@gmail.com wrote: My current approach is to build an empty virtualenv, pip install nose, and from the numpy root directory do python setup.py build_ext --inplace and python -c 'import numpy; numpy.test()'. This works, for my stock system python, though I get a lot of weird messages suggesting distutils problems (for example python setup.py develop, although suggested by setup.py itself, claims that develop is not a command). But I don't know how (for example) to test with python3 without starting from a separate clean source tree. Nowadays, you can use pip install -e . to install an in-place editable version of numpy. This should also execute build_ext for you. Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Multiarray API size mismatch 301 302?
Did you do a git clean -fxd before re-installing?
On Thu, Aug 13, 2015 at 2:34 PM, Sebastian Berg sebast...@sipsolutions.net
wrote:
Hey,
just for hacking/testing, I tried to add to shape.c:
/*NUMPY_API
*
* Checks if memory overlap exists
*/
NPY_NO_EXPORT int
PyArray_ArraysShareMemory(PyArrayObject *arr1, PyArrayObject *arr2, int
work) {
return solve_may_share_memory(arr1, arr2, work);
}
and to numpy_api.py:
# End 1.10 API
'PyArray_ArraysShareMemory':(301,),
But I am getting the error:
File numpy/core/code_generators/generate_numpy_api.py, line 230, in
do_generate_api
(len(multiarray_api_dict), len(multiarray_api_index)))
AssertionError: Multiarray API size mismatch 301 302
It is puzzling me, so anyone got a quick idea?
- Sebastian
___
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
Re: [Numpy-discussion] Development workflow (not git tutorial)
On Thu, Aug 13, 2015 at 10:00 AM, Sebastian Berg sebast...@sipsolutions.net wrote: On Do, 2015-08-13 at 15:52 +, Anne Archibald wrote: Hi, What is a sensible way to work on (modify, compile, and test) numpy? There is documentation about contributing to numpy at: http://docs.scipy.org/doc/numpy-dev/dev/index.html and: http://docs.scipy.org/doc/numpy-dev/dev/gitwash/development_workflow.html but these are entirely focused on using git. I have no problem with that aspect. It is building and testing that I am looking for the Right Way to do. My current approach is to build an empty virtualenv, pip install nose, and from the numpy root directory do python setup.py build_ext --inplace and python -c 'import numpy; numpy.test()'. This works, for my stock system python, though I get a lot of weird messages suggesting distutils problems (for example python setup.py develop, although suggested by setup.py itself, claims that develop is not a command). But I don't know how (for example) to test with python3 without starting from a separate clean source tree. We have the `runtests.py` script which will do exactly this (don't think it gives lots of weird warnings normally). I think that is the only real tip I can give. +1 for `runtests.py`. Do `python runtests.py --help` to get started. If you want another python, say 3.5, `python3.5 runtests.py`. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Multiarray API size mismatch 301 302?
Hey,
just for hacking/testing, I tried to add to shape.c:
/*NUMPY_API
*
* Checks if memory overlap exists
*/
NPY_NO_EXPORT int
PyArray_ArraysShareMemory(PyArrayObject *arr1, PyArrayObject *arr2, int
work) {
return solve_may_share_memory(arr1, arr2, work);
}
and to numpy_api.py:
# End 1.10 API
'PyArray_ArraysShareMemory':(301,),
But I am getting the error:
File numpy/core/code_generators/generate_numpy_api.py, line 230, in
do_generate_api
(len(multiarray_api_dict), len(multiarray_api_index)))
AssertionError: Multiarray API size mismatch 301 302
It is puzzling me, so anyone got a quick idea?
- Sebastian
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Multiarray API size mismatch 301 302?
On Do, 2015-08-13 at 14:36 -0400, Benjamin Root wrote:
Did you do a git clean -fxd before re-installing?
Yup.
On Thu, Aug 13, 2015 at 2:34 PM, Sebastian Berg
sebast...@sipsolutions.net wrote:
Hey,
just for hacking/testing, I tried to add to shape.c:
/*NUMPY_API
*
* Checks if memory overlap exists
*/
NPY_NO_EXPORT int
PyArray_ArraysShareMemory(PyArrayObject *arr1, PyArrayObject
*arr2, int
work) {
return solve_may_share_memory(arr1, arr2, work);
}
and to numpy_api.py:
# End 1.10 API
'PyArray_ArraysShareMemory':(301,),
But I am getting the error:
File numpy/core/code_generators/generate_numpy_api.py,
line 230, in
do_generate_api
(len(multiarray_api_dict), len(multiarray_api_index)))
AssertionError: Multiarray API size mismatch 301 302
It is puzzling me, so anyone got a quick idea?
- Sebastian
___
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
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problems using add_npy_pkg_config
This doesn't answer your question but: why? If you're not distributing a Python project, there is no reason to use distutils instead of a sane build system. Come on. We don't take it seriously, and neither do the Python core devs. It's also pretty much completely unsupported. Numpy.distutils is a bit better in that respect than Python distutils, which doesn't even get sane patches merged. Try Scons, Tup, Gradle, Shake, Waf or anything else that's at least somewhat modern and supported. Do not use numpy.distutils unless there's no other mature choice (i.e. you're developing a Python project). Sorry, reading my mail again, it seems that I didn't make this point clear. I have a project which is python + c-lib. The later which should be used by other c-projects as well. The minimal working example is without any python code, as I only have problems with the pkg config file. ... and concerning cmake, yes we tried this as well, but using cmake to distribute the python code is also a pita ;-) ... Christian ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Changes to np.digitize since NumPy 1.9?
On Thu, Aug 13, 2015 at 7:59 AM, Nathan Goldbaum nathan12...@gmail.com wrote: On Thu, Aug 13, 2015 at 9:44 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Aug 13, 2015 at 12:09 AM, Jaime Fernández del Río jaime.f...@gmail.com wrote: On Wed, Aug 12, 2015 at 2:03 PM, Nathan Goldbaum nathan12...@gmail.com wrote: Hi all, I've been testing the package I spend most of my time on, yt, under numpy 1.10b1 since the announcement went out. I think I've narrowed down and fixed all of the test failures that cropped up except for one last issue. It seems that the behavior of np.digitize with respect to ndarray subclasses has changed since the NumPy 1.9 series. Consider the following test script: ```python import numpy as np class MyArray(np.ndarray): def __new__(cls, *args, **kwargs): return np.ndarray.__new__(cls, *args, **kwargs) data = np.arange(100) bins = np.arange(100) + 0.5 data = data.view(MyArray) bins = bins.view(MyArray) digits = np.digitize(data, bins) print type(digits) ``` Under NumPy 1.9.2, this prints type 'numpy.ndarray', but under the 1.10 beta, it prints class '__main__.MyArray' I'm curious why this change was made. Since digitize outputs index arrays, it doesn't make sense to me why it should return anything but a plain ndarray. I see in the release notes that digitize now uses searchsorted under the hood. Is this related? It is indeed searchsorted's fault, as it returns an object of the same type as the needle (the items to search for): import numpy as np class A(np.ndarray): pass class B(np.ndarray): pass np.arange(10).view(A).searchsorted(np.arange(5).view(B)) B([0, 1, 2, 3, 4]) I am all for making index-returning functions always return a base ndarray, and will be more than happy to send a PR fixing this if there is some agreement. I think that is the right thing to do. Awesome, I'd appreciate having a PR to fix this. Arguably the return type *could* be the same type as the inputs, but given that it's a behavior change I agree that it's best to add a patch so the output of serachsorted is sanitized to be an ndarray before it's returned by digitize. It is relatively simple to do, just replace Py_TYPE(ap2) with PyArray_Type in this line: https://github.com/numpy/numpy/blob/maintenance/1.10.x/numpy/core/src/multiarray/item_selection.c#L1725 Then fix all the tests that are expecting searchsorted to return something else than a base ndarray. We already have modified nonzero to return base ndarray's in this release, see the release notes, so it will go with the same theme. For 1.11 I think we should try to extend this if it returns an index, it will be a base ndarray to all other functions that don't right now. Then sit back and watch AstroPy come down in flames... ;-))) Seriously, I think this makes a lot of sense, and should be documented as the way NumPy handles index arrays. Anyway, I will try to find time tonight to put this PR together, unless someone beats me to it, which I would be totally fine with. Jaime To answer Nathaniel's question, I opened an issue on yt's bitbucket page to record the test failures: https://bitbucket.org/yt_analysis/yt/issues/1063/new-test-failures-using-numpy-110-beta I've fixed two of the classes of errors in that bug in yt itself, since it looks like we were relying on buggy or deprecated behavior in NumPy. Here are the PRs for those fixes: https://bitbucket.org/yt_analysis/yt/pull-requests/1697/cast-enzo-grid-start-index-to-int-arrays/diff https://bitbucket.org/yt_analysis/yt/pull-requests/1696/add-assert_allclose_units-like/diff 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 -- (\__/) ( O.o) ( ) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] ANN: Numpy 1.10.0b1 release
On Thu, Aug 13, 2015 at 4:34 PM, Matthew Brett matthew.br...@gmail.com
wrote:
On Thu, Aug 13, 2015 at 1:04 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Wed, Aug 12, 2015 at 12:23 PM, Sebastian Berg
sebast...@sipsolutions.net wrote:
On Mi, 2015-08-12 at 01:07 -0700, Nathaniel Smith wrote:
On Wed, Aug 12, 2015 at 12:51 AM, Sebastian Berg
sebast...@sipsolutions.net wrote:
On Mi, 2015-08-12 at 09:41 +0200, Jens Jørgen Mortensen wrote:
On 08/11/2015 11:23 PM, Charles R Harris wrote:
Hi All,
give this release a whirl and report any problems either on the
numpy-discussion list or by opening an issue on github.
I'm pleased to announce the first beta release of Numpy 1.10.0.
There is over a year's worth of enhancements and bug fixes in the
1.10.0 release, so please give this release a whirl and report any
problems either on the numpy-discussion list or by opening an
issue
on github. Tarballs, installers, and release notes may be found in
the usual place at Sourceforge.
I'm getting test errors on the standard OSX numpy / scipy compilation
rig:
Python.org Python
OSX 10.9
clang
gfortran 4.2.3
Compiling from the `maintenance/1.10.x` branch (is there a 1.10.0b1 tag)?
==
ERROR: test_accelerate_framework_sgemv_fix (test_multiarray.TestDot)
--
Traceback (most recent call last):
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/core/tests/test_multiarray.py,
line 4218, in test_accelerate_framework_sgemv_fix
m = aligned_array(100, 15, np.float32)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/core/tests/test_multiarray.py,
line 4200, in aligned_array
d = np.dtype()
TypeError: Required argument 'dtype' (pos 1) not found
This one should be fixed by https://github.com/numpy/numpy/pull/6202
==
ERROR: test_callback.TestF77Callback.test_string_callback
--
Traceback (most recent call last):
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/nose/case.py,
line 381, in setUp
try_run(self.inst, ('setup', 'setUp'))
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/nose/util.py,
line 471, in try_run
return func()
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 362, in setUp
module_name=self.module_name)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 79, in wrapper
memo[key] = func(*a, **kw)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 170, in build_code
module_name=module_name)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 79, in wrapper
memo[key] = func(*a, **kw)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 150, in build_module
__import__(module_name)
ImportError:
dlopen(/var/folders/s7/r25pn2xj48n4cm76_mgsb78hgn/T/tmpa39XPB/_test_ext_module_5403.so,
2): Symbol not found: _func0_
Referenced from:
/var/folders/s7/r25pn2xj48n4cm76_mgsb78hgn/T/tmpa39XPB/_test_ext_module_5403.so
Expected in: dynamic lookup
Any ideas about this second one?
I don't get this second error when building with homebrew gfortran
4.8. Is this expected? Should we be raising an error for earlier
gfortrans?
Probaby, or we could make the failing bit, if we can find it, gcc version
dependent. gcc 4.2 is eight years old, which OS X versions depend on it?
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] ANN: Numpy 1.10.0b1 release
On Thu, Aug 13, 2015 at 1:04 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Wed, Aug 12, 2015 at 12:23 PM, Sebastian Berg
sebast...@sipsolutions.net wrote:
On Mi, 2015-08-12 at 01:07 -0700, Nathaniel Smith wrote:
On Wed, Aug 12, 2015 at 12:51 AM, Sebastian Berg
sebast...@sipsolutions.net wrote:
On Mi, 2015-08-12 at 09:41 +0200, Jens Jørgen Mortensen wrote:
On 08/11/2015 11:23 PM, Charles R Harris wrote:
Hi All,
give this release a whirl and report any problems either on the
numpy-discussion list or by opening an issue on github.
I'm pleased to announce the first beta release of Numpy 1.10.0.
There is over a year's worth of enhancements and bug fixes in the
1.10.0 release, so please give this release a whirl and report any
problems either on the numpy-discussion list or by opening an issue
on github. Tarballs, installers, and release notes may be found in
the usual place at Sourceforge.
I'm getting test errors on the standard OSX numpy / scipy compilation rig:
Python.org Python
OSX 10.9
clang
gfortran 4.2.3
Compiling from the `maintenance/1.10.x` branch (is there a 1.10.0b1 tag)?
==
ERROR: test_accelerate_framework_sgemv_fix (test_multiarray.TestDot)
--
Traceback (most recent call last):
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/core/tests/test_multiarray.py,
line 4218, in test_accelerate_framework_sgemv_fix
m = aligned_array(100, 15, np.float32)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/core/tests/test_multiarray.py,
line 4200, in aligned_array
d = np.dtype()
TypeError: Required argument 'dtype' (pos 1) not found
This one should be fixed by https://github.com/numpy/numpy/pull/6202
==
ERROR: test_callback.TestF77Callback.test_string_callback
--
Traceback (most recent call last):
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/nose/case.py,
line 381, in setUp
try_run(self.inst, ('setup', 'setUp'))
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/nose/util.py,
line 471, in try_run
return func()
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 362, in setUp
module_name=self.module_name)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 79, in wrapper
memo[key] = func(*a, **kw)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 170, in build_code
module_name=module_name)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 79, in wrapper
memo[key] = func(*a, **kw)
File
/Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/numpy/f2py/tests/util.py,
line 150, in build_module
__import__(module_name)
ImportError:
dlopen(/var/folders/s7/r25pn2xj48n4cm76_mgsb78hgn/T/tmpa39XPB/_test_ext_module_5403.so,
2): Symbol not found: _func0_
Referenced from:
/var/folders/s7/r25pn2xj48n4cm76_mgsb78hgn/T/tmpa39XPB/_test_ext_module_5403.so
Expected in: dynamic lookup
Any ideas about this second one?
I don't get this second error when building with homebrew gfortran
4.8. Is this expected? Should we be raising an error for earlier
gfortrans?
Cheers,
Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Multiarray API size mismatch 301 302?
So as Julian helped me, it was the wrong style of the function, the
curly bracket has to go on the next line for the API generation to pick
it up.
- Sebastian
On Do, 2015-08-13 at 20:42 +0200, Sebastian Berg wrote:
On Do, 2015-08-13 at 14:36 -0400, Benjamin Root wrote:
Did you do a git clean -fxd before re-installing?
Yup.
On Thu, Aug 13, 2015 at 2:34 PM, Sebastian Berg
sebast...@sipsolutions.net wrote:
Hey,
just for hacking/testing, I tried to add to shape.c:
/*NUMPY_API
*
* Checks if memory overlap exists
*/
NPY_NO_EXPORT int
PyArray_ArraysShareMemory(PyArrayObject *arr1, PyArrayObject
*arr2, int
work) {
return solve_may_share_memory(arr1, arr2, work);
}
and to numpy_api.py:
# End 1.10 API
'PyArray_ArraysShareMemory':(301,),
But I am getting the error:
File numpy/core/code_generators/generate_numpy_api.py,
line 230, in
do_generate_api
(len(multiarray_api_dict), len(multiarray_api_index)))
AssertionError: Multiarray API size mismatch 301 302
It is puzzling me, so anyone got a quick idea?
- Sebastian
___
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py and callbacks with variables
Hi Casey, On Wed, Aug 12, 2015 at 11:46 PM, Casey Deen d...@mpia.de wrote: Hi Pearu- Thanks so much! This works! Can you point me to a reference for the format of the .pyf files? My ~day of searching found a few pages on the scipy website, but nothing which went into this amount of detail. Try this: https://sysbio.ioc.ee/projects/f2py2e/usersguide/index.html#signature-file I also asked Stackoverflow, and unless you object, I'd like to add your explanation and mark it as SOLVED for future poor souls wrestling with this problem. I'll also update the github repository with before and after versions of the .pyf file. Go ahead with stackoverflow. Best regards, Pearu Cheers, Casey On 08/12/2015 09:34 PM, Pearu Peterson wrote: Hi Casey, What you observe, is not a f2py bug. When f2py sees a code like subroutine foo call bar end subroutine foo then it will not make an attempt to analyze bar because of implicit assumption that all statements that has no references to foo arguments are irrelevant for wrapper function generation. For your example, f2py needs some help. Try the following signature in .pyf file: subroutine barney ! in :flintstone:nocallback.f use test__user__routines, fred=fred, bambam=bambam intent(callback, hide) fred external fred intent(callback,hide) bambam external bambam end subroutine barney Btw, instead of f2py -c -m flintstone flintstone.pyf callback.f nocallback.f use f2py -c flintstone.pyf callback.f nocallback.f because module name comes from the .pyf file. HTH, Pearu On Wed, Aug 12, 2015 at 7:12 PM, Casey Deen d...@mpia.de mailto:d...@mpia.de wrote: Hi all- I've run into what I think might be a bug in f2py and callbacks to python. Or, maybe I'm not using things correctly. I have created a very minimal example which illustrates my problem at: https://github.com/soylentdeen/fluffy-kumquat The issue seems to affect call backs with variables, but only when they are called indirectly (i.e. from other fortran routines). For example, if I have a python function def show_number(n): print(%d % n) and I setup a callback in a fortran routine: subroutine cb cf2py intent(callback, hide) blah external blah call blah(5) end and connect it to the python routine fortranObject.blah = show_number I can successfully call the cb routine from python: fortranObject.cb 5 However, if I call the cb routine from within another fortran routine, it seems to lose its marbles subroutine no_cb call cb end capi_return is NULL Call-back cb_blah_in_cb__user__routines failed. For more information, please have a look at the github repository. I've reproduced the behavior on both linux and mac. I'm not sure if this is an error in the way I'm using the code, or if it is an actual bug. Any and all help would be very much appreciated. Cheers, Casey -- Dr. Casey Deen Post-doctoral Researcher d...@mpia.de mailto:d...@mpia.de +49-6221-528-375 tel:%2B49-6221-528-375 Max Planck Institut für Astronomie (MPIA) Königstuhl 17 D-69117 Heidelberg, Germany ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org mailto: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 -- Dr. Casey Deen Post-doctoral Researcher d...@mpia.de +49-6221-528-375 Max Planck Institut für Astronomie (MPIA) Königstuhl 17 D-69117 Heidelberg, Germany ___ 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
Re: [Numpy-discussion] Problems using add_npy_pkg_config
On Thu, Aug 13, 2015 at 8:45 PM, Christian Engwer christian.eng...@uni-muenster.de wrote: This doesn't answer your question but: why? If you're not distributing a Python project, there is no reason to use distutils instead of a sane build system. Come on. We don't take it seriously, and neither do the Python core devs. It's also pretty much completely unsupported. Numpy.distutils is a bit better in that respect than Python distutils, which doesn't even get sane patches merged. Try Scons, Tup, Gradle, Shake, Waf or anything else that's at least somewhat modern and supported. Do not use numpy.distutils unless there's no other mature choice (i.e. you're developing a Python project). Sorry, reading my mail again, it seems that I didn't make this point clear. I have a project which is python + c-lib. The later which should be used by other c-projects as well. Thanks for clarifying. It makes more sense now:) The minimal working example is without any python code, as I only have problems with the pkg config file. I stared at it for a while, and can't figure it out despite you following the example in the add_npy_pkg_config docstring pretty much to the letter. When you see that the error is generated in a function that starts with ``# XXX: another ugly workaround to circumvent distutils brain damage.``, you're usually in trouble. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Changes to np.digitize since NumPy 1.9?
On Thu, Aug 13, 2015 at 9:57 AM, Jaime Fernández del Río jaime.f...@gmail.com wrote: On Thu, Aug 13, 2015 at 7:59 AM, Nathan Goldbaum nathan12...@gmail.com wrote: On Thu, Aug 13, 2015 at 9:44 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Aug 13, 2015 at 12:09 AM, Jaime Fernández del Río jaime.f...@gmail.com wrote: On Wed, Aug 12, 2015 at 2:03 PM, Nathan Goldbaum nathan12...@gmail.com wrote: Hi all, I've been testing the package I spend most of my time on, yt, under numpy 1.10b1 since the announcement went out. I think I've narrowed down and fixed all of the test failures that cropped up except for one last issue. It seems that the behavior of np.digitize with respect to ndarray subclasses has changed since the NumPy 1.9 series. Consider the following test script: ```python import numpy as np class MyArray(np.ndarray): def __new__(cls, *args, **kwargs): return np.ndarray.__new__(cls, *args, **kwargs) data = np.arange(100) bins = np.arange(100) + 0.5 data = data.view(MyArray) bins = bins.view(MyArray) digits = np.digitize(data, bins) print type(digits) ``` Under NumPy 1.9.2, this prints type 'numpy.ndarray', but under the 1.10 beta, it prints class '__main__.MyArray' I'm curious why this change was made. Since digitize outputs index arrays, it doesn't make sense to me why it should return anything but a plain ndarray. I see in the release notes that digitize now uses searchsorted under the hood. Is this related? It is indeed searchsorted's fault, as it returns an object of the same type as the needle (the items to search for): import numpy as np class A(np.ndarray): pass class B(np.ndarray): pass np.arange(10).view(A).searchsorted(np.arange(5).view(B)) B([0, 1, 2, 3, 4]) I am all for making index-returning functions always return a base ndarray, and will be more than happy to send a PR fixing this if there is some agreement. I think that is the right thing to do. Awesome, I'd appreciate having a PR to fix this. Arguably the return type *could* be the same type as the inputs, but given that it's a behavior change I agree that it's best to add a patch so the output of serachsorted is sanitized to be an ndarray before it's returned by digitize. It is relatively simple to do, just replace Py_TYPE(ap2) with PyArray_Type in this line: https://github.com/numpy/numpy/blob/maintenance/1.10.x/numpy/core/src/multiarray/item_selection.c#L1725 Then fix all the tests that are expecting searchsorted to return something else than a base ndarray. We already have modified nonzero to return base ndarray's in this release, see the release notes, so it will go with the same theme. For 1.11 I think we should try to extend this if it returns an index, it will be a base ndarray to all other functions that don't right now. Then sit back and watch AstroPy come down in flames... ;-))) Seriously, I think this makes a lot of sense, and should be documented as the way NumPy handles index arrays. Anyway, I will try to find time tonight to put this PR together, unless someone beats me to it, which I would be totally fine with. PR #6206 it is: https://github.com/numpy/numpy/pull/6206 Jaime -- (\__/) ( O.o) ( ) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Help in understanding
Hi, I am new to NumPy, Can someone help me in understanding below code. names = np.array(['Bob', 'Joe', 'Will', 'Bob', 'Will', 'Joe', 'Joe']) data = np.random.random((7,4)) print data [[ 0.85402649 0.12827655 0.580 0.86288236] [ 0.30162683 0.45269508 0.98098039 0.1291469 ] [ 0.21229924 0.37497112 0.57367496 0.08607771] [ 0.3028660.42160468 0.26879288 0.68032467] [ 0.60612492 0.35210577 0.91355096 0.57872181] [ 0.11583826 0.8192 0.39214077 0.51377566] [ 0.03767641 0.1920532 0.24872009 0.36068313]] data[names == 'Bob'] array([[ 0.85402649, 0.12827655, 0.580 , 0.86288236], [ 0.302866 , 0.42160468, 0.26879288, 0.68032467]]) Also, can someone help me where and how to practice NumPy? -- View this message in context: http://numpy-discussion.10968.n7.nabble.com/Help-in-understanding-tp40827.html Sent from the Numpy-discussion mailing list archive at Nabble.com. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Development workflow (not git tutorial)
Hi, What is a sensible way to work on (modify, compile, and test) numpy? There is documentation about contributing to numpy at: http://docs.scipy.org/doc/numpy-dev/dev/index.html and: http://docs.scipy.org/doc/numpy-dev/dev/gitwash/development_workflow.html but these are entirely focused on using git. I have no problem with that aspect. It is building and testing that I am looking for the Right Way to do. My current approach is to build an empty virtualenv, pip install nose, and from the numpy root directory do python setup.py build_ext --inplace and python -c 'import numpy; numpy.test()'. This works, for my stock system python, though I get a lot of weird messages suggesting distutils problems (for example python setup.py develop, although suggested by setup.py itself, claims that develop is not a command). But I don't know how (for example) to test with python3 without starting from a separate clean source tree. What do you recommend: use virtualenvs? Is building inplace the way to go? Is there a better way to run all tests? Are there other packages that should go into the virtualenv? What is the best way to test on multiple python versions? Switch cleanly between feature branches? Surely I can't be the only person wishing for advice on a sensible way to work with an in-development version of numpy? Perhaps this would be a good addition to CONTRIBUTING.md or the website? Thanks, Anne ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Development workflow (not git tutorial)
On Do, 2015-08-13 at 15:52 +, Anne Archibald wrote: Hi, What is a sensible way to work on (modify, compile, and test) numpy? There is documentation about contributing to numpy at: http://docs.scipy.org/doc/numpy-dev/dev/index.html and: http://docs.scipy.org/doc/numpy-dev/dev/gitwash/development_workflow.html but these are entirely focused on using git. I have no problem with that aspect. It is building and testing that I am looking for the Right Way to do. My current approach is to build an empty virtualenv, pip install nose, and from the numpy root directory do python setup.py build_ext --inplace and python -c 'import numpy; numpy.test()'. This works, for my stock system python, though I get a lot of weird messages suggesting distutils problems (for example python setup.py develop, although suggested by setup.py itself, claims that develop is not a command). But I don't know how (for example) to test with python3 without starting from a separate clean source tree. We have the `runtests.py` script which will do exactly this (don't think it gives lots of weird warnings normally). I think that is the only real tip I can give. - Sebastian What do you recommend: use virtualenvs? Is building inplace the way to go? Is there a better way to run all tests? Are there other packages that should go into the virtualenv? What is the best way to test on multiple python versions? Switch cleanly between feature branches? Surely I can't be the only person wishing for advice on a sensible way to work with an in-development version of numpy? Perhaps this would be a good addition to CONTRIBUTING.md or the website? Thanks, Anne ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
