[Numpy-discussion] Help in understanding

2015-08-13 Thread subro 
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

Re: [Numpy-discussion] Changes to np.digitize since NumPy 1.9?

2015-08-13 Thread Jaime Fernández del Río 
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 
> 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 >>> > 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 "", but under the
> 1.10 beta, it prints ""
>
> 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

Re: [Numpy-discussion] [SciPy-Dev] ANN: Numpy 1.10.0b1 release

2015-08-13 Thread Charles R Harris 
On Thu, Aug 13, 2015 at 4:34 PM, Matthew Brett 
wrote:

> On Thu, Aug 13, 2015 at 1:04 PM, Matthew Brett 
> wrote:
> > Hi,
> >
> > On Wed, Aug 12, 2015 at 12:23 PM, Sebastian Berg
> >  wrote:
> >> On Mi, 2015-08-12 at 01:07 -0700, Nathaniel Smith wrote:
> >>> On Wed, Aug 12, 2015 at 12:51 AM, Sebastian Berg
> >>>  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

2015-08-13 Thread Matthew Brett 
On Thu, Aug 13, 2015 at 1:04 PM, Matthew Brett  wrote:
> Hi,
>
> On Wed, Aug 12, 2015 at 12:23 PM, Sebastian Berg
>  wrote:
>> On Mi, 2015-08-12 at 01:07 -0700, Nathaniel Smith wrote:
>>> On Wed, Aug 12, 2015 at 12:51 AM, Sebastian Berg
>>>  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] Problems using add_npy_pkg_config

2015-08-13 Thread Ralf Gommers 
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] Multiarray API size mismatch 301 302?

2015-08-13 Thread Sebastian Berg 
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
> >  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

2015-08-13 Thread Pearu Peterson 
Hi Casey,

On Wed, Aug 12, 2015 at 11:46 PM, Casey Deen  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  > > 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 
> >  +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
> >
>
> --
> 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

2015-08-13 Thread Christian Engwer 
> >> 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] Multiarray API size mismatch 301 302?

2015-08-13 Thread Sebastian Berg 
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
>  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] Multiarray API size mismatch 301 302?

2015-08-13 Thread Benjamin Root 
Did you do a "git clean -fxd" before re-installing?

On Thu, Aug 13, 2015 at 2:34 PM, Sebastian Berg 
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] Multiarray API size mismatch 301 302?

2015-08-13 Thread Sebastian Berg 
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] Development workflow (not git tutorial)

2015-08-13 Thread Stefan van der Walt 
On 2015-08-13 08:52:22, Anne Archibald  
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] Changes to np.digitize since NumPy 1.9?

2015-08-13 Thread Jaime Fernández del Río 
On Thu, Aug 13, 2015 at 7:59 AM, Nathan Goldbaum 
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 
>>> 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 "", but under the
 1.10 beta, it prints ""

 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] Development workflow (not git tutorial)

2015-08-13 Thread Charles R Harris 
On Thu, Aug 13, 2015 at 10:00 AM, Sebastian Berg  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

Re: [Numpy-discussion] Development workflow (not git tutorial)

2015-08-13 Thread Sebastian Berg 
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

[Numpy-discussion] Development workflow (not git tutorial)

2015-08-13 Thread Anne Archibald 
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] Changes to np.digitize since NumPy 1.9?

2015-08-13 Thread Nathan Goldbaum 
On Thu, Aug 13, 2015 at 9:44 AM, Charles R Harris  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 
>> 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 "", but under the
>>> 1.10 beta, it prints ""
>>>
>>> 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] Changes to np.digitize since NumPy 1.9?

2015-08-13 Thread Charles R Harris 
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 
> 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 "", but under the
>> 1.10 beta, it prints ""
>>
>> 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] [SciPy-Dev] ANN: Numpy 1.10.0b1 release

2015-08-13 Thread Matthew Brett 
Hi,

On Wed, Aug 12, 2015 at 12:23 PM, Sebastian Berg
 wrote:
> On Mi, 2015-08-12 at 01:07 -0700, Nathaniel Smith wrote:
>> On Wed, Aug 12, 2015 at 12:51 AM, Sebastian Berg
>>  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?

2015-08-13 Thread Nathaniel Smith 
On Aug 12, 2015 11:12 PM, "Jaime Fernández del Río" 
wrote:
>
> On Wed, Aug 12, 2015 at 2:03 PM, Nathan Goldbaum 
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 "", but under the
1.10 beta, it prints ""
>>
>> 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