Re: [Numpy-discussion] 1.7.1

[Charles R Harris]

On Tue, Feb 26, 2013 at 5:43 PM, Ondřej Čertík wrote:

> On Tue, Feb 26, 2013 at 1:21 PM, Charles R Harris
>  wrote:
> >
> >
> > On Tue, Feb 26, 2013 at 2:03 PM, Ralf Gommers 
> > wrote:
> >>
> >>
> >>
> >>
> >> On Tue, Feb 26, 2013 at 7:47 PM, Charles R Harris
> >>  wrote:
> >>>
> >>> When should we put out 1.7.1? Discuss ;)
> >>
> >>
> >> When we have X times more fixes in maintenance/1.7.x than the one commit
> >> with a one-liner fix that we have now. Where X is >= 5 at least, unless
> >> there's a very high prio fix that needs releasing asap?
> >>
> >> Having at least 2 months between bugfix releases unless something very
> >> urgent comes up would also make sense to me.
> >>
> >> I think we do need to be diligent in backporting fixes quickly after
> >> they're merged into master, and not leaving that till right before the
> >> release candidate is scheduled.
> >>
> >
> > Ralph, the backports are PR's marked with the backport tag and there are
> > more than one. It is up to Ondrej to decide whether to include them or
> not.
>
> I can't see the backport tag. How can I find it at github?
>
> Otherwise I think we should release sooner, I think this bug is quite
> annoying
> for scikit-learn:
>
> https://github.com/scikit-learn/scikit-learn/issues/1715
>
>
I don't know the best way, but you can go to the search box, type
numpy/numpy issues, and when the results come up select the stable 1.7
backport milestone. Nathaniel committed a bunch, but it looks like there is
still one to backport.

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

Re: [Numpy-discussion] 1.7.1

[Ondřej Čertík]

On Tue, Feb 26, 2013 at 1:21 PM, Charles R Harris
 wrote:
>
>
> On Tue, Feb 26, 2013 at 2:03 PM, Ralf Gommers 
> wrote:
>>
>>
>>
>>
>> On Tue, Feb 26, 2013 at 7:47 PM, Charles R Harris
>>  wrote:
>>>
>>> When should we put out 1.7.1? Discuss ;)
>>
>>
>> When we have X times more fixes in maintenance/1.7.x than the one commit
>> with a one-liner fix that we have now. Where X is >= 5 at least, unless
>> there's a very high prio fix that needs releasing asap?
>>
>> Having at least 2 months between bugfix releases unless something very
>> urgent comes up would also make sense to me.
>>
>> I think we do need to be diligent in backporting fixes quickly after
>> they're merged into master, and not leaving that till right before the
>> release candidate is scheduled.
>>
>
> Ralph, the backports are PR's marked with the backport tag and there are
> more than one. It is up to Ondrej to decide whether to include them or not.

I can't see the backport tag. How can I find it at github?

Otherwise I think we should release sooner, I think this bug is quite annoying
for scikit-learn:

https://github.com/scikit-learn/scikit-learn/issues/1715

Ondrej
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 1.7.1

[Ralf Gommers]

On Tue, Feb 26, 2013 at 10:54 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:

>
>
> On Tue, Feb 26, 2013 at 2:46 PM, Nathaniel Smith  wrote:
>
>> On Tue, Feb 26, 2013 at 9:21 PM, Charles R Harris
>>  wrote:
>> >
>> >
>> > On Tue, Feb 26, 2013 at 2:03 PM, Ralf Gommers 
>> > wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On Tue, Feb 26, 2013 at 7:47 PM, Charles R Harris
>> >>  wrote:
>> >>>
>> >>> When should we put out 1.7.1? Discuss ;)
>> >>
>> >>
>> >> When we have X times more fixes in maintenance/1.7.x than the one
>> commit
>> >> with a one-liner fix that we have now. Where X is >= 5 at least, unless
>> >> there's a very high prio fix that needs releasing asap?
>>
>> There is, actually; we (probably I) broke
>> np.diagonal()/ndarray.diagonal() so any array that has diagonal()
>> called on it gets pinned in memory forever. That's why the
>> scikits-learn folk are grumpy.
>>
>> >> Having at least 2 months between bugfix releases unless something very
>> >> urgent comes up would also make sense to me.
>>
>> I'm not sure why -- bug-fixes don't age like wine or anything.
>> Obviously there's a trade-off around how much effort we want to spend
>> on managing releases versus other things, but I don't see why there'd
>> be anything *wrong* with putting out a tiny point-release whenever we
>> find a real bug in a stable series. No-one has to upgrade...
>>
>
Nothing wrong per se, just a waste of developer and packager resources if
the frequency is too high. Of course if there's 10 bug fixes ready sooner
after the previous release, do a bugfix release sooner. But then we should
really look in the mirror and ask why there's so many fixes so soon


>> >> I think we do need to be diligent in backporting fixes quickly after
>> >> they're merged into master, and not leaving that till right before the
>> >> release candidate is scheduled.
>> >
>> > Ralph, the backports are PR's marked with the backport tag and there are
>> > more than one. It is up to Ondrej to decide whether to include them or
>> not.
>>
>> Oh argh, we should probably document some of this stuff, I just merged
>> a bunch of them myself (which all looked fine of course). Mea culpa.
>>
>> For the moment: Ondrej, heads up that I did this!
>>
>
> That's OK, I think you did a fine job.
>
>
>>
>> For the future: I definitely see the benefit of having one person
>> keeping track of what goes in and what doesn't as we get into the late
>> stage of the release cycle, but in between, maybe it makes sense for
>> us all to work together on keeping the basic backports branch up to
>> date and taking some of the load off the release manager.
>
>
+1


> (I'll try
>> not to continue implementing this plan unless we agree on it,
>> though...)
>>
>>
>
> You seem to have a pretty good eye on things.
>

+1

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] numpy.scipy.org giving 404 error

[Peter Cock]

Hello all,

http://numpy.scipy.org is giving a GitHub 404 error.

As this used to be a widely used URL for the project,
and likely appears in many printed references, could
it be fixed to point to or redirect to the (relatively new)
http://www.numpy.org site please?

Thanks,

Peter
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 1.7.1

[Charles R Harris]

On Tue, Feb 26, 2013 at 2:46 PM, Nathaniel Smith  wrote:

> On Tue, Feb 26, 2013 at 9:21 PM, Charles R Harris
>  wrote:
> >
> >
> > On Tue, Feb 26, 2013 at 2:03 PM, Ralf Gommers 
> > wrote:
> >>
> >>
> >>
> >>
> >> On Tue, Feb 26, 2013 at 7:47 PM, Charles R Harris
> >>  wrote:
> >>>
> >>> When should we put out 1.7.1? Discuss ;)
> >>
> >>
> >> When we have X times more fixes in maintenance/1.7.x than the one commit
> >> with a one-liner fix that we have now. Where X is >= 5 at least, unless
> >> there's a very high prio fix that needs releasing asap?
>
> There is, actually; we (probably I) broke
> np.diagonal()/ndarray.diagonal() so any array that has diagonal()
> called on it gets pinned in memory forever. That's why the
> scikits-learn folk are grumpy.
>
> >> Having at least 2 months between bugfix releases unless something very
> >> urgent comes up would also make sense to me.
>
> I'm not sure why -- bug-fixes don't age like wine or anything.
> Obviously there's a trade-off around how much effort we want to spend
> on managing releases versus other things, but I don't see why there'd
> be anything *wrong* with putting out a tiny point-release whenever we
> find a real bug in a stable series. No-one has to upgrade...
>
> >> I think we do need to be diligent in backporting fixes quickly after
> >> they're merged into master, and not leaving that till right before the
> >> release candidate is scheduled.
> >
> > Ralph, the backports are PR's marked with the backport tag and there are
> > more than one. It is up to Ondrej to decide whether to include them or
> not.
>
> Oh argh, we should probably document some of this stuff, I just merged
> a bunch of them myself (which all looked fine of course). Mea culpa.
>
> For the moment: Ondrej, heads up that I did this!
>

That's OK, I think you did a fine job.


>
> For the future: I definitely see the benefit of having one person
> keeping track of what goes in and what doesn't as we get into the late
> stage of the release cycle, but in between, maybe it makes sense for
> us all to work together on keeping the basic backports branch up to
> date and taking some of the load off the release manager? (I'll try
> not to continue implementing this plan unless we agree on it,
> though...)
>
>
You seem to have a pretty good eye on things.

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

Re: [Numpy-discussion] 1.7.1

[Nathaniel Smith]

On Tue, Feb 26, 2013 at 9:21 PM, Charles R Harris
 wrote:
>
>
> On Tue, Feb 26, 2013 at 2:03 PM, Ralf Gommers 
> wrote:
>>
>>
>>
>>
>> On Tue, Feb 26, 2013 at 7:47 PM, Charles R Harris
>>  wrote:
>>>
>>> When should we put out 1.7.1? Discuss ;)
>>
>>
>> When we have X times more fixes in maintenance/1.7.x than the one commit
>> with a one-liner fix that we have now. Where X is >= 5 at least, unless
>> there's a very high prio fix that needs releasing asap?

There is, actually; we (probably I) broke
np.diagonal()/ndarray.diagonal() so any array that has diagonal()
called on it gets pinned in memory forever. That's why the
scikits-learn folk are grumpy.

>> Having at least 2 months between bugfix releases unless something very
>> urgent comes up would also make sense to me.

I'm not sure why -- bug-fixes don't age like wine or anything.
Obviously there's a trade-off around how much effort we want to spend
on managing releases versus other things, but I don't see why there'd
be anything *wrong* with putting out a tiny point-release whenever we
find a real bug in a stable series. No-one has to upgrade...

>> I think we do need to be diligent in backporting fixes quickly after
>> they're merged into master, and not leaving that till right before the
>> release candidate is scheduled.
>
> Ralph, the backports are PR's marked with the backport tag and there are
> more than one. It is up to Ondrej to decide whether to include them or not.

Oh argh, we should probably document some of this stuff, I just merged
a bunch of them myself (which all looked fine of course). Mea culpa.

For the moment: Ondrej, heads up that I did this!

For the future: I definitely see the benefit of having one person
keeping track of what goes in and what doesn't as we get into the late
stage of the release cycle, but in between, maybe it makes sense for
us all to work together on keeping the basic backports branch up to
date and taking some of the load off the release manager? (I'll try
not to continue implementing this plan unless we agree on it,
though...)

-n
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 1.7.1

[Charles R Harris]

On Tue, Feb 26, 2013 at 2:03 PM, Ralf Gommers wrote:

>
>
>
> On Tue, Feb 26, 2013 at 7:47 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> When should we put out 1.7.1? Discuss ;)
>>
>
> When we have X times more fixes in maintenance/1.7.x than the one commit
> with a one-liner fix that we have now. Where X is >= 5 at least, unless
> there's a very high prio fix that needs releasing asap?
>
> Having at least 2 months between bugfix releases unless something very
> urgent comes up would also make sense to me.
>
> I think we do need to be diligent in backporting fixes quickly after
> they're merged into master, and not leaving that till right before the
> release candidate is scheduled.
>
>
Ralph, the backports are PR's marked with the backport tag and there are
more than one. It is up to Ondrej to decide whether to include them or not.

Chuck

>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [EXTERNAL] swig interface file (numpy.i) warning

[Bill Spotz]

So the difference is that I was wanting to make changes in the git repository 
that is at version 1.8.  I would expect it to still work, though.

I can take a look at the scipy issue.

-Bill

On Feb 26, 2013, at 1:41 PM, Ralf Gommers wrote:

> On Mon, Feb 25, 2013 at 6:12 AM, Bill Spotz  wrote:
> I wanted to take a stab at updating numpy.i to not use deprecated NumPy C/API 
> code.  Nothing in the git logs indicates this has already been done. I added
> 
>  #define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION
> 
> to numpy.i right before it includes numpy/arrayobject.h.  The built-in tests 
> for numpy.i should be sufficient to ferret out all of the deprecated calls.  
> When I try to make the tests, the compiler tells me that it has included
> 
>  npy_deprecated_api.h
> 
> and I get a compiler error when it includes old_defines.h, telling me that it 
> is deprecated.  Shouldn't my #define prevent this from happening?  I'm 
> confused.  Any guidance would be appreciated.
> 
> Hi Bill, this works as expected for me. I did the following:
> 
> 1. Build 1.7.0 release in-place
> 2. Set PYTHONPATH to in-place build.
> 3. $ cd doc/swig
> 4. $ make test  # runs all tests
> 5. Add define in numpy.i like you did
> 6. $ make test  # now fails because old_defines.h wasn't included
> 
> First failure is:
> 
> Array_wrap.cxx:5506:20: error: ‘PyArrayObject’ has no member named ‘data’
> Array_wrap.cxx: In function ‘PyObject* _wrap_new_Array2(PyObject*, 
> PyObject*)’:
> Array_wrap.cxx:5635:55: error: cannot convert ‘PyObject* {aka _object*}’ to 
> ‘const PyArrayObject* {aka const tagPyArrayObject*}’ for argument ‘1’ to ‘int 
> PyArray_TYPE(const PyArrayObject*)’
> error: command 'gcc' failed with exit status 1
> 
> 
> If you're about to update numpy.i, maybe you could take along the divergence 
> between the numpy and scipy versions of it? A ticket was just opened for 
> that: http://projects.scipy.org/scipy/ticket/1825
> I don't know how much work that would be, or why we even have two versions.
> 
> Cheers,
> Ralf
> 
>  
> 
> Thanks,
> Bill
> 
> On Oct 9, 2012, at 9:18 PM, Tom Krauss wrote:
> 
> > This code reproduces the error - I think it is small enough for email.  
> > (large) numpy.i not included, let me know if you want that too.  Makefile 
> > will need to be tailored to your environment.
> > If it's more convenient, or you have trouble reproducing, I can create a 
> > branch on github - let me know.
> >
> > On Tue, Oct 9, 2012 at 1:47 PM, Tom Krauss  
> > wrote:
> > I can't attach the exact code but would be happy to provide something 
> > simple that has the same issue.  I'll post something here when I can get to 
> > it.
> > - Tom
> >
> >
> > On Tue, Oct 9, 2012 at 10:52 AM, Bill Spotz  wrote:
> > Tom, Charles,
> >
> > If you discuss this further, be sure to CC me.
> >
> > -Bill Spotz
> >
> > On Oct 9, 2012, at 8:50 AM, Charles R Harris wrote:
> >
> >> Hi Tom,
> >>
> >> On Tue, Oct 9, 2012 at 8:30 AM, Tom Krauss  
> >> wrote:
> >> Hi,
> >>
> >> I've been happy to use numpy.i for generating SWIG interfaces to C++.
> >>
> >> For a while, I've noticed this warning while compiling:
> >> /Users/tkrauss/projects/dev_env/lib/python2.7/site-packages/numpy-1.8.0.dev_f2f0ac0_20120725-py2.7-macosx-10.8-x86_64.egg/numpy/core/include/numpy/npy_deprecated_api.h:11:2:
> >>  warning: #warning "Using deprecated NumPy API, disable it by #defining 
> >> NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
> >>
> >> and today tried to get rid of the warning.
> >>
> >> So, in numpy.i, I followed the warning's advice.  I added the # def here:
> >>
> >> %{
> >> #ifndef SWIG_FILE_WITH_INIT
> >> #  define NO_IMPORT_ARRAY
> >> #endif
> >> #include "stdio.h"
> >> #define NPY_NO_DEPRECATED_API  NPY_1_7_API_VERSION
> >> #include 
> >> %}
> >>
> >> SWIG was happy, but when compiling the C++ wrapper, there were many 
> >> warnings followed by many errors.  The warnings were for redefinition of 
> >> NPY_MIN_BYTE and similar.  The errors were for all kinds of stuff, excerpt 
> >> here:
> >> native_wrap.cpp:3632: error: ‘PyArray_NOTYPE’ was not declared in this 
> >> scope
> >> native_wrap.cpp:3633: error: cannot convert ‘PyObject*’ to ‘const 
> >> PyArrayObject*’ for argument ‘1’ to ‘int PyArray_TYPE(const 
> >> PyArrayObject*)’
> >> native_wrap.cpp: At global scope:
> >> native_wrap.cpp:3877: error: ‘intp’ has not been declared
> >> native_wrap.cpp: In function ‘int require_fortran(PyArrayObject*)’:
> >> native_wrap.cpp:3929: error: ‘struct tagPyArrayObject’ has no member named 
> >> ‘nd’
> >> native_wrap.cpp:3933: error: ‘struct tagPyArrayObject’ has no member named 
> >> ‘flags’
> >> native_wrap.cpp:3933: error: ‘FARRAY’ was not declared in this scope
> >> native_wrap.cpp:20411: error: ‘struct tagPyArrayObject’ has no member 
> >> named ‘data’
> >>
> >> It looks like there is a new C API for numpy, and the version of numpy.i 
> >> that I have doesn't use it.
> >>
> >> Is there a new version of numpy.i available (or in development) that works 
> >> wit

Re: [Numpy-discussion] 1.7.1

[Ralf Gommers]

On Tue, Feb 26, 2013 at 7:47 PM, Charles R Harris  wrote:

> When should we put out 1.7.1? Discuss ;)
>

When we have X times more fixes in maintenance/1.7.x than the one commit
with a one-liner fix that we have now. Where X is >= 5 at least, unless
there's a very high prio fix that needs releasing asap?

Having at least 2 months between bugfix releases unless something very
urgent comes up would also make sense to me.

I think we do need to be diligent in backporting fixes quickly after
they're merged into master, and not leaving that till right before the
release candidate is scheduled.

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [EXTERNAL] swig interface file (numpy.i) warning

[Ralf Gommers]

On Mon, Feb 25, 2013 at 6:12 AM, Bill Spotz  wrote:

> I wanted to take a stab at updating numpy.i to not use deprecated NumPy
> C/API code.  Nothing in the git logs indicates this has already been done.
> I added
>
>  #define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION
>
> to numpy.i right before it includes numpy/arrayobject.h.  The built-in
> tests for numpy.i should be sufficient to ferret out all of the deprecated
> calls.  When I try to make the tests, the compiler tells me that it has
> included
>
>  npy_deprecated_api.h
>
> and I get a compiler error when it includes old_defines.h, telling me that
> it is deprecated.  Shouldn't my #define prevent this from happening?  I'm
> confused.  Any guidance would be appreciated.
>

Hi Bill, this works as expected for me. I did the following:

1. Build 1.7.0 release in-place
2. Set PYTHONPATH to in-place build.
3. $ cd doc/swig
4. $ make test  # runs all tests
5. Add define in numpy.i like you did
6. $ make test  # now fails because old_defines.h wasn't included

First failure is:

Array_wrap.cxx:5506:20: error: ‘PyArrayObject’ has no member named ‘data’
Array_wrap.cxx: In function ‘PyObject* _wrap_new_Array2(PyObject*,
PyObject*)’:
Array_wrap.cxx:5635:55: error: cannot convert ‘PyObject* {aka _object*}’ to
‘const PyArrayObject* {aka const tagPyArrayObject*}’ for argument ‘1’ to
‘int PyArray_TYPE(const PyArrayObject*)’
error: command 'gcc' failed with exit status 1


If you're about to update numpy.i, maybe you could take along the
divergence between the numpy and scipy versions of it? A ticket was just
opened for that: http://projects.scipy.org/scipy/ticket/1825
I don't know how much work that would be, or why we even have two versions.

Cheers,
Ralf



>
> Thanks,
> Bill
>
> On Oct 9, 2012, at 9:18 PM, Tom Krauss wrote:
>
> > This code reproduces the error - I think it is small enough for email.
>  (large) numpy.i not included, let me know if you want that too.  Makefile
> will need to be tailored to your environment.
> > If it's more convenient, or you have trouble reproducing, I can create a
> branch on github - let me know.
> >
> > On Tue, Oct 9, 2012 at 1:47 PM, Tom Krauss 
> wrote:
> > I can't attach the exact code but would be happy to provide something
> simple that has the same issue.  I'll post something here when I can get to
> it.
> > - Tom
> >
> >
> > On Tue, Oct 9, 2012 at 10:52 AM, Bill Spotz  wrote:
> > Tom, Charles,
> >
> > If you discuss this further, be sure to CC me.
> >
> > -Bill Spotz
> >
> > On Oct 9, 2012, at 8:50 AM, Charles R Harris wrote:
> >
> >> Hi Tom,
> >>
> >> On Tue, Oct 9, 2012 at 8:30 AM, Tom Krauss 
> wrote:
> >> Hi,
> >>
> >> I've been happy to use numpy.i for generating SWIG interfaces to C++.
> >>
> >> For a while, I've noticed this warning while compiling:
> >>
> /Users/tkrauss/projects/dev_env/lib/python2.7/site-packages/numpy-1.8.0.dev_f2f0ac0_20120725-py2.7-macosx-10.8-x86_64.egg/numpy/core/include/numpy/npy_deprecated_api.h:11:2:
> warning: #warning "Using deprecated NumPy API, disable it by #defining
> NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
> >>
> >> and today tried to get rid of the warning.
> >>
> >> So, in numpy.i, I followed the warning's advice.  I added the # def
> here:
> >>
> >> %{
> >> #ifndef SWIG_FILE_WITH_INIT
> >> #  define NO_IMPORT_ARRAY
> >> #endif
> >> #include "stdio.h"
> >> #define NPY_NO_DEPRECATED_API  NPY_1_7_API_VERSION
> >> #include 
> >> %}
> >>
> >> SWIG was happy, but when compiling the C++ wrapper, there were many
> warnings followed by many errors.  The warnings were for redefinition of
> NPY_MIN_BYTE and similar.  The errors were for all kinds of stuff, excerpt
> here:
> >> native_wrap.cpp:3632: error: ‘PyArray_NOTYPE’ was not declared in this
> scope
> >> native_wrap.cpp:3633: error: cannot convert ‘PyObject*’ to ‘const
> PyArrayObject*’ for argument ‘1’ to ‘int PyArray_TYPE(const PyArrayObject*)’
> >> native_wrap.cpp: At global scope:
> >> native_wrap.cpp:3877: error: ‘intp’ has not been declared
> >> native_wrap.cpp: In function ‘int require_fortran(PyArrayObject*)’:
> >> native_wrap.cpp:3929: error: ‘struct tagPyArrayObject’ has no member
> named ‘nd’
> >> native_wrap.cpp:3933: error: ‘struct tagPyArrayObject’ has no member
> named ‘flags’
> >> native_wrap.cpp:3933: error: ‘FARRAY’ was not declared in this scope
> >> native_wrap.cpp:20411: error: ‘struct tagPyArrayObject’ has no member
> named ‘data’
> >>
> >> It looks like there is a new C API for numpy, and the version of
> numpy.i that I have doesn't use it.
> >>
> >> Is there a new version of numpy.i available (or in development) that
> works with the new API?  Short term it will just get rid of a warning but I
> am interested in a good long term solution in case I need to upgrade numpy.
> >>
> >>
> >> In the long term we would like to hide the ndarray internals,
> essentially making them private. There are still some incomplete areas,
> f2py and, apparently, numpy.i. Your feedback here is quite helpful and if
> you have som

Re: [Numpy-discussion] drawing the line

[Alan G Isaac]

On 2/26/2013 1:11 PM, josef.p...@gmail.com wrote:
> Alan was in favor of the dot method



I still really like this, and it probably violates
any simple rule for drawing the line.

Nevertheless it would be nice to have some
principle(s) other than the squeaky wheel principle
for thinking about such proposals.

Cheers,
Alan

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

Re: [Numpy-discussion] drawing the line (was: Adding .abs() method to the array object)

[josef . pktd]

On Tue, Feb 26, 2013 at 1:11 PM,   wrote:
> On Tue, Feb 26, 2013 at 12:33 PM, eat  wrote:
>> Huh,
>>
>> On Tue, Feb 26, 2013 at 5:03 PM,  wrote:
>>>
>>> On Tue, Feb 26, 2013 at 9:39 AM, Benjamin Root  wrote:
>>> >
>>> >
>>> > On Mon, Feb 25, 2013 at 8:23 PM, Alan G Isaac 
>>> > wrote:
>>> >>
>>> >> I'm hoping this discussion will return to the drawing the line
>>> >> question.
>>> >>
>>> >>
>>> >> http://stackoverflow.com/questions/8108688/in-python-when-should-i-use-a-function-instead-of-a-method
>>> >>
>>> >> Alan Isaac
>>> >
>>> >
>>> > Proposed line:
>>> >
>>> > Reduction methods only.
>>> >
>>> > Discuss...
>>>
>>> arr.dot ?
>>>
>>> the 99 most common functions for which chaining looks nice.
>>
>> Care to elaborate more for us less uninitiated?
>
> partially a joke. I don't see any good and simple rule to restrict the
> number of methods.

99 was just the first number that came to mind that sounded exaggerated enough.

(I like methods and will use __abs__ from now on, but I won't argue
much in any direction of changes.)

Josef
http://en.wikipedia.org/wiki/99_Luftballons

>
> dot was added as a method a few numpy versions ago, because it is
> painful to write nested or sequential dot products. Alan was in favor
> of the dot method and of matrix algebra because it's much easier on
> new users who come from a background that has a dot product as "*" or
> similar operator.
>
> As Skipper, I think the number of methods is not really huge
> (especially not numerical operations)
>
> Josef
>
>>
>> Regards,
>> -eat
>>>
>>>
>>> Josef
>>>
>>> >
>>> >
>>> > Ben Root
>>> >
>>> > ___
>>> > 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
>>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] drawing the line (was: Adding .abs() method to the array object)

[josef . pktd]

On Tue, Feb 26, 2013 at 12:33 PM, eat  wrote:
> Huh,
>
> On Tue, Feb 26, 2013 at 5:03 PM,  wrote:
>>
>> On Tue, Feb 26, 2013 at 9:39 AM, Benjamin Root  wrote:
>> >
>> >
>> > On Mon, Feb 25, 2013 at 8:23 PM, Alan G Isaac 
>> > wrote:
>> >>
>> >> I'm hoping this discussion will return to the drawing the line
>> >> question.
>> >>
>> >>
>> >> http://stackoverflow.com/questions/8108688/in-python-when-should-i-use-a-function-instead-of-a-method
>> >>
>> >> Alan Isaac
>> >
>> >
>> > Proposed line:
>> >
>> > Reduction methods only.
>> >
>> > Discuss...
>>
>> arr.dot ?
>>
>> the 99 most common functions for which chaining looks nice.
>
> Care to elaborate more for us less uninitiated?

partially a joke. I don't see any good and simple rule to restrict the
number of methods.

dot was added as a method a few numpy versions ago, because it is
painful to write nested or sequential dot products. Alan was in favor
of the dot method and of matrix algebra because it's much easier on
new users who come from a background that has a dot product as "*" or
similar operator.

As Skipper, I think the number of methods is not really huge
(especially not numerical operations)

Josef

>
> Regards,
> -eat
>>
>>
>> Josef
>>
>> >
>> >
>> > Ben Root
>> >
>> > ___
>> > 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
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] drawing the line (was: Adding .abs() method to the array object)

[eat]

Huh,

On Tue, Feb 26, 2013 at 5:03 PM,  wrote:

> On Tue, Feb 26, 2013 at 9:39 AM, Benjamin Root  wrote:
> >
> >
> > On Mon, Feb 25, 2013 at 8:23 PM, Alan G Isaac 
> wrote:
> >>
> >> I'm hoping this discussion will return to the drawing the line question.
> >>
> >>
> http://stackoverflow.com/questions/8108688/in-python-when-should-i-use-a-function-instead-of-a-method
> >>
> >> Alan Isaac
> >
> >
> > Proposed line:
> >
> > Reduction methods only.
> >
> > Discuss...
>
> arr.dot ?
>
> the 99 most common functions for which chaining looks nice.
>
Care to elaborate more for us less uninitiated?

Regards,
-eat

>
> Josef
>
> >
> >
> > Ben Root
> >
> > ___
> > 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

Re: [Numpy-discussion] drawing the line (was: Adding .abs() method to the array object)

[josef . pktd]

On Tue, Feb 26, 2013 at 9:39 AM, Benjamin Root  wrote:
>
>
> On Mon, Feb 25, 2013 at 8:23 PM, Alan G Isaac  wrote:
>>
>> I'm hoping this discussion will return to the drawing the line question.
>>
>> http://stackoverflow.com/questions/8108688/in-python-when-should-i-use-a-function-instead-of-a-method
>>
>> Alan Isaac
>
>
> Proposed line:
>
> Reduction methods only.
>
> Discuss...

arr.dot ?

the 99 most common functions for which chaining looks nice.

Josef

>
>
> Ben Root
>
> ___
> 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] drawing the line (was: Adding .abs() method to the array object)

[Benjamin Root]

On Mon, Feb 25, 2013 at 8:23 PM, Alan G Isaac  wrote:

> I'm hoping this discussion will return to the drawing the line question.
>
> http://stackoverflow.com/questions/8108688/in-python-when-should-i-use-a-function-instead-of-a-method
>
> Alan Isaac
>

Proposed line:

Reduction methods only.

Discuss...


Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Adding .abs() method to the array object

[Robert Kern]

On Tue, Feb 26, 2013 at 12:11 AM, Charles R Harris
 wrote:
>
> On Sat, Feb 23, 2013 at 1:33 PM, Robert Kern  wrote:
>>
>> On Sat, Feb 23, 2013 at 7:25 PM, Nathaniel Smith  wrote:
>> > On Sat, Feb 23, 2013 at 3:38 PM, Till Stensitzki 
>> > wrote:
>> >> Hello,
>> >> i know that the array object is already crowded, but i would like
>> >> to see the abs method added, especially doing work on the console.
>> >> Considering that many much less used functions are also implemented
>> >> as a method, i don't think adding one more would be problematic.
>> >
>> > My gut feeling is that we have too many methods on ndarray, not too
>> > few, but in any case, can you elaborate? What's the rationale for why
>> > np.abs(a) is so much harder than a.abs(), and why this function and
>> > not other unary functions?
>>
>> Or even abs(a).
>
>
> Well, that just calls a method:
>
> In [1]: ones(3).__abs__()
> Out[1]: array([ 1.,  1.,  1.])
>
> Which shows the advantage of methods, they provide universal function hooks.

I'm not sure what point you are trying to make. It does not appear to
be relevant to adding an ndarray.abs() method.

-- 
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] What should np.ndarray.__contains__ do

[Nathaniel Smith]

On Tue, Feb 26, 2013 at 10:21 AM, Sebastian Berg
 wrote:
> On Mon, 2013-02-25 at 16:33 +, Nathaniel Smith wrote:
>> On Mon, Feb 25, 2013 at 3:10 PM, Sebastian Berg
>>  wrote:
>> > Hello all,
>> >
>> > currently the `__contains__` method or the `in` operator on arrays, does
>> > not return what the user would expect when in the operation `a in b` the
>> > `a` is not a single element (see "In [3]-[4]" below).
>>
>> True, I did not expect that!
>>
> 
>
>> The two approaches that I can see, and which generalize the behaviour
>> of simple Python lists in natural ways, are:
>>
>> a) the left argument is coerced to a scalar of the appropriate type,
>> then we check if that value appears anywhere in the array (basically
>> raveling the right argument).
>>
>
> How did I misread that? I guess you mean element and never subarray
> matching. Actually I am starting to think that is best. Subarray
> matching may be useful, but would probably be better off inside its own
> function.
> That also might be best with object arrays, since it is difficult to
> know if the user means a tuple as an element or a two element subarray,
> unless you say "input is array-like", which is possible (or more
> sensible) for a function.
>
> That would mean just make the use cases that current give weird results
> into errors. And maybe those errors hint to np.in1d and if numpy would
> get it, some dedicated subarray matching function.

Yeah, I don't have a strong opinion on whether or not sub-array
matching should work, but personally I lean towards "not". There's
precedent both ways:

In [2]: "bc" in "abcd"
Out[2]: True

In [3]: ["b", "c"] in ["a", "b", "c", "d"]
Out[3]: False

But arrays are much more like lists than they are like strings. And
it's not clear to what extent anyone even wants this kind of sub-array
matching. (I can't think of any use cases, really. I can for a version
that returns all the match locations, or a similarity map, like
cv.MatchTemplate, but not for this itself...) And there's a lot of
ambiguity about which axes are matched with which axes. So maybe
subarray matching is better off in its own function that can have some
extra arguments and more flexibility in its return value and so forth.

-n
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Adding .abs() method to the array object

[Sebastian Berg]

On Tue, 2013-02-26 at 11:16 +0100, Todd wrote:
> On Tue, Feb 26, 2013 at 10:58 AM, Sebastian Berg
>  wrote:
> On Mon, 2013-02-25 at 22:04 -0500, josef.p...@gmail.com wrote:
> > On Mon, Feb 25, 2013 at 9:58 PM,  
> wrote:
> > > On Mon, Feb 25, 2013 at 9:20 PM, Sebastian Berg
> > >  wrote:
> > >> On Mon, 2013-02-25 at 10:50 -0500, Skipper Seabold wrote:
> > >>> On Mon, Feb 25, 2013 at 10:43 AM, Till Stensitzki
> 
> > >>> wrote:
> > >>> >
> > >>> > First, sorry that i didnt search for an old thread,
> but because i
> > >>> disagree with
> > >>> > conclusion i would at least address my reason:
> > >>> >
> 
> 
> > >> Two small things (not sure if it matters much). But first
> almost all of
> > >> these methods are related to the container and not the
> elements. Second
> > >> actually using a method arr.abs() has a tiny pitfall,
> since abs would
> > >> work on numpy types, but not on python types. This means
> that:
> > >>
> > >> np.array([1, 2, 3]).max().abs()
> > >>
> > >> works, but
> > >>
> > >> np.array([1, 2, 3], dtype=object).max().abs()
> > >>
> > >> breaks. Python has a safe name for abs already...
> > >
> >  (np.array([1, 2, 3], dtype=object)).max()
> > > 3
> >  (np.array([1, 2, 3], dtype=object)).__abs__().max()
> > > 3
> >  (np.array([1, 2, '3'], dtype=object)).__abs__()
> > > Traceback (most recent call last):
> > >   File "", line 1, in 
> > > TypeError: bad operand type for abs(): 'str'
> > >
> >  map(abs, [1, 2, 3])
> > > [1, 2, 3]
> >  map(abs, [1, 2, '3'])
> > > Traceback (most recent call last):
> > >   File "", line 1, in 
> > > TypeError: bad operand type for abs(): 'str'
> >
> > or maybe more useful
> >
> > >>> from decimal import Decimal
> > >>> d = [Decimal(str(k)) for k in np.linspace(-1, 1, 5)]
> > >>> map(abs, d)
> > [Decimal('1.0'), Decimal('0.5'), Decimal('0.0'),
> Decimal('0.5'), Decimal('1.0')]
> >
> > >>> np.asarray(d).__abs__()
> > array([1.0, 0.5, 0.0, 0.5, 1.0], dtype=object)
> > >>> np.asarray(d).__abs__()[0]
> > Decimal('1.0')
> >
> > Josef
> >
> > >
> > > I don't see a difference.
> > >
> > > (I don't expect to use max abs on anything else than
> numbers.)
> > >
> 
> 
> The difference is about scalars only. And of course __abs__ is
> fine, but
> if numpy adds an abs method, its scalars would logically have
> it too.
> But then you diverge from python scalars. That has exactly the
> downside
> that you may write code that suddenly stops working for python
> scalars
> without noticing.
> 
> I turned around the abs and max order here, so that the abs
> works on the
> scalar, not useful but just as an example.
> 
> 
> But doesn't this also apply to many existing methods?
> 
I do not think that it does, or at a different quality. Almost all of
those methods either logically work on the container not the array. I.e.
reshape, etc. or are the most common reductions like mean/max/min (which
are also only sensible for containers). Now those also work on numpy
scalars but you should rarely use them on scalars. The only example I
can see is round (there is no special method for that before python 3,
so you could argue that python did not provide a canonical way for
numpy).

Now this is not a huge argument, obviously scalars can have a lot of
specialized methods (like decimals for example), but in the case of abs,
python provides a default way of doing it which always works, and it
makes me tend to say that it is better to use that (even if I sometimes
write .abs() too...).

> ___
> 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] What should np.ndarray.__contains__ do

[Sebastian Berg]

On Mon, 2013-02-25 at 16:33 +, Nathaniel Smith wrote:
> On Mon, Feb 25, 2013 at 3:10 PM, Sebastian Berg
>  wrote:
> > Hello all,
> >
> > currently the `__contains__` method or the `in` operator on arrays, does
> > not return what the user would expect when in the operation `a in b` the
> > `a` is not a single element (see "In [3]-[4]" below).
> 
> True, I did not expect that!
> 


> The two approaches that I can see, and which generalize the behaviour
> of simple Python lists in natural ways, are:
> 
> a) the left argument is coerced to a scalar of the appropriate type,
> then we check if that value appears anywhere in the array (basically
> raveling the right argument).
> 

How did I misread that? I guess you mean element and never subarray
matching. Actually I am starting to think that is best. Subarray
matching may be useful, but would probably be better off inside its own
function.
That also might be best with object arrays, since it is difficult to
know if the user means a tuple as an element or a two element subarray,
unless you say "input is array-like", which is possible (or more
sensible) for a function.

That would mean just make the use cases that current give weird results
into errors. And maybe those errors hint to np.in1d and if numpy would
get it, some dedicated subarray matching function.

-- Sebastian

> b) for an array with shape (n1, n2, n3, ...), the left argument is
> treated as an array of shape (n2, n3, ...), and we check if that
> subarray (as a whole) appears anywhere in the array. Or in other
> words, 'A in B' is true iff there is some i such that
> np.array_equals(B[i], A).
> 
> Question 1: are there any other sensible options that aren't on this list?
> 
> Question 2: if not, then which should we choose? (Or we could choose
> both, I suppose, depending on what the left argument looks like.)
> 
> Between these two options, I like (a) and don't like (b). The
> pretending-to-be-a-list-of-lists special case behaviour for
> multidimensional arrays is already weird and confusing, and besides,
> I'd expect equality comparison on arrays to use ==, not array_equals.
> So (b) feels pretty inconsistent with other numpy conventions to me.
> 
> -n
> 
> > I have opened an issue for it:
> > https://github.com/numpy/numpy/issues/3016#issuecomment-14045545
> >
> >
> > Regards,
> >
> > Sebastian
> >
> > In [1]: a = np.array([0, 2])
> >
> > In [2]: b = np.arange(10).reshape(5,2)
> >
> > In [3]: b
> > Out[3]:
> > array([[0, 1],
> >[2, 3],
> >[4, 5],
> >[6, 7],
> >[8, 9]])
> >
> > In [4]: a in b
> > Out[4]: True
> >
> > In [5]: (b == a).any()
> > Out[5]: True
> >
> > In [6]: (b == a).all(0).any() # the 0 could be multiple axes
> > Out[6]: False
> >
> > In [7]: a_2d = a[None,:]
> >
> > In [8]: a_2d in b # broadcast dimension means "any" -> True
> > Out[8]: True
> >
> > In [9]: [0, 1] in b[:,:1] # should not work (or be False, not True)
> > Out[9]: True
> >
> >
> > ___
> > 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

[Numpy-discussion] GSOC 2013

[Todd]

Is numpy planning to participate in GSOC this year, either on their own or
as a part of another group?  If so, should we start trying to get some
project suggestions together?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Adding .abs() method to the array object

[Todd]

On Tue, Feb 26, 2013 at 10:58 AM, Sebastian Berg  wrote:

> On Mon, 2013-02-25 at 22:04 -0500, josef.p...@gmail.com wrote:
> > On Mon, Feb 25, 2013 at 9:58 PM,   wrote:
> > > On Mon, Feb 25, 2013 at 9:20 PM, Sebastian Berg
> > >  wrote:
> > >> On Mon, 2013-02-25 at 10:50 -0500, Skipper Seabold wrote:
> > >>> On Mon, Feb 25, 2013 at 10:43 AM, Till Stensitzki 
> > >>> wrote:
> > >>> >
> > >>> > First, sorry that i didnt search for an old thread, but because i
> > >>> disagree with
> > >>> > conclusion i would at least address my reason:
> > >>> >
> 
> > >> Two small things (not sure if it matters much). But first almost all
> of
> > >> these methods are related to the container and not the elements.
> Second
> > >> actually using a method arr.abs() has a tiny pitfall, since abs would
> > >> work on numpy types, but not on python types. This means that:
> > >>
> > >> np.array([1, 2, 3]).max().abs()
> > >>
> > >> works, but
> > >>
> > >> np.array([1, 2, 3], dtype=object).max().abs()
> > >>
> > >> breaks. Python has a safe name for abs already...
> > >
> >  (np.array([1, 2, 3], dtype=object)).max()
> > > 3
> >  (np.array([1, 2, 3], dtype=object)).__abs__().max()
> > > 3
> >  (np.array([1, 2, '3'], dtype=object)).__abs__()
> > > Traceback (most recent call last):
> > >   File "", line 1, in 
> > > TypeError: bad operand type for abs(): 'str'
> > >
> >  map(abs, [1, 2, 3])
> > > [1, 2, 3]
> >  map(abs, [1, 2, '3'])
> > > Traceback (most recent call last):
> > >   File "", line 1, in 
> > > TypeError: bad operand type for abs(): 'str'
> >
> > or maybe more useful
> >
> > >>> from decimal import Decimal
> > >>> d = [Decimal(str(k)) for k in np.linspace(-1, 1, 5)]
> > >>> map(abs, d)
> > [Decimal('1.0'), Decimal('0.5'), Decimal('0.0'), Decimal('0.5'),
> Decimal('1.0')]
> >
> > >>> np.asarray(d).__abs__()
> > array([1.0, 0.5, 0.0, 0.5, 1.0], dtype=object)
> > >>> np.asarray(d).__abs__()[0]
> > Decimal('1.0')
> >
> > Josef
> >
> > >
> > > I don't see a difference.
> > >
> > > (I don't expect to use max abs on anything else than numbers.)
> > >
>
> The difference is about scalars only. And of course __abs__ is fine, but
> if numpy adds an abs method, its scalars would logically have it too.
> But then you diverge from python scalars. That has exactly the downside
> that you may write code that suddenly stops working for python scalars
> without noticing.
>
> I turned around the abs and max order here, so that the abs works on the
> scalar, not useful but just as an example.
>

But doesn't this also apply to many existing methods?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Adding .abs() method to the array object

[Sebastian Berg]

On Mon, 2013-02-25 at 22:04 -0500, josef.p...@gmail.com wrote:
> On Mon, Feb 25, 2013 at 9:58 PM,   wrote:
> > On Mon, Feb 25, 2013 at 9:20 PM, Sebastian Berg
> >  wrote:
> >> On Mon, 2013-02-25 at 10:50 -0500, Skipper Seabold wrote:
> >>> On Mon, Feb 25, 2013 at 10:43 AM, Till Stensitzki 
> >>> wrote:
> >>> >
> >>> > First, sorry that i didnt search for an old thread, but because i
> >>> disagree with
> >>> > conclusion i would at least address my reason:
> >>> >

> >> Two small things (not sure if it matters much). But first almost all of
> >> these methods are related to the container and not the elements. Second
> >> actually using a method arr.abs() has a tiny pitfall, since abs would
> >> work on numpy types, but not on python types. This means that:
> >>
> >> np.array([1, 2, 3]).max().abs()
> >>
> >> works, but
> >>
> >> np.array([1, 2, 3], dtype=object).max().abs()
> >>
> >> breaks. Python has a safe name for abs already...
> >
>  (np.array([1, 2, 3], dtype=object)).max()
> > 3
>  (np.array([1, 2, 3], dtype=object)).__abs__().max()
> > 3
>  (np.array([1, 2, '3'], dtype=object)).__abs__()
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > TypeError: bad operand type for abs(): 'str'
> >
>  map(abs, [1, 2, 3])
> > [1, 2, 3]
>  map(abs, [1, 2, '3'])
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > TypeError: bad operand type for abs(): 'str'
> 
> or maybe more useful
> 
> >>> from decimal import Decimal
> >>> d = [Decimal(str(k)) for k in np.linspace(-1, 1, 5)]
> >>> map(abs, d)
> [Decimal('1.0'), Decimal('0.5'), Decimal('0.0'), Decimal('0.5'), 
> Decimal('1.0')]
> 
> >>> np.asarray(d).__abs__()
> array([1.0, 0.5, 0.0, 0.5, 1.0], dtype=object)
> >>> np.asarray(d).__abs__()[0]
> Decimal('1.0')
> 
> Josef
> 
> >
> > I don't see a difference.
> >
> > (I don't expect to use max abs on anything else than numbers.)
> >

The difference is about scalars only. And of course __abs__ is fine, but
if numpy adds an abs method, its scalars would logically have it too.
But then you diverge from python scalars. That has exactly the downside
that you may write code that suddenly stops working for python scalars
without noticing.

I turned around the abs and max order here, so that the abs works on the
scalar, not useful but just as an example.

> > Josef
> >>
> >>
> >>> I find myself typing things like
> >>>
> >>> arr.abs()
> >>>
> >>> and
> >>>
> >>> arr.unique()
> >>>
> >>> quite often.
> >>>
> >>> Skipper
> >>> ___
> >>> 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
> 


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

Re: [Numpy-discussion] another discussion on numpy correlate (and convolution)

[Matthew Brett]

Hi,

On Tue, Feb 26, 2013 at 12:20 AM, Pierre Haessig
 wrote:
> Hi,
>
> Le 22/02/2013 17:40, Matthew Brett a écrit :
>> >From complete ignorance, do you think it is an option to allow a
>> (n_left, n_right) tuple as a value for 'mode'?
>>
> That may be an option. Another one would be to add some kind of `bounds`
> option which would be set to None by default but would accept the
> (n_left, n_right) tuple and would override `mode`.
>
> I don't know which one is better.

Personally I try to avoid mutually incompatible arguments.  I guess
you'd have to raise and error if the bounds were defined as well as
mode?

> The only thing I've in mind which may cause confusion is that `mode`
> normally receives a string ('valid', 'same', 'full') but it also accept
> corresponding integer codes (undocumented, but I guess it corresponds to
> a old signature of that function). So I wonder if there could be a
> confusion between :
> * mode = n
> * mode = (n_left, n_right)

Maybe deprecate the integer arguments?   It doesn't seem too bad to me
that the numbers in the tuple are different in meaning from a scalar,
particularly if the scalar argument is undocumented and will soon go
away.

Cheers,

Matthew
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Adding .abs() method to the array object

[Pierre Haessig]

Hi,

Le 23/02/2013 20:25, Nathaniel Smith a écrit :
> My gut feeling is that we have too many methods on ndarray, not too
> few, but in any case, can you elaborate? What's the rationale for why
> np.abs(a) is so much harder than a.abs(), and why this function and
> not other unary functions?
(Just another usecase where I see the x.abs() notation useful)

If x is a complex array, I feel that x.abs() and x.angle() would be
natural complements to x.real and x.imag.

Of course, x.angle() only make much sense for complex arrays while
x.abs() makes sense for any numerical array.

best,
Pierre



signature.asc
Description: OpenPGP digital signature
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Leaking memory problem

[Jaakko Luttinen]

Thanks for all the answers, they were helpful!

I was using 1.7.0 and now installed from git:
https://github.com/numpy/numpy/archive/master.zip

And it looks like the memory leak is gone, so I guess I was hitting that
known memory leak bug. Thanks!

-Jaakko

On 02/26/2013 09:04 AM, Nathaniel Smith wrote:
> Is this with 1.7? There see a few memory leak fixes in 1.7, so if you
> aren't using that you should try it to be sure. And if you are using it,
> then there is one known memory leak bug in 1.7 that you might want to
> check whether you're hitting:
> https://github.com/numpy/numpy/issues/2969
> 
> -n
> 
> On 25 Feb 2013 13:41, "Jaakko Luttinen"  > wrote:
> 
> Hi!
> 
> I was wondering if anyone could help me in finding a memory leak problem
> with NumPy. My project is quite massive and I haven't been able to
> construct a simple example which would reproduce the problem..
> 
> I have an iterative algorithm which should not increase the memory usage
> as the iteration progresses. However, after the first iteration, 1GB of
> memory is used and it steadily increases until at about 100-200
> iterations 8GB is used and the program exits with MemoryError.
> 
> I have a collection of objects which contain large arrays. In each
> iteration, the objects are updated in turns by re-computing the arrays
> they contain. The number of arrays and their sizes are constant (do not
> change during the iteration). So the memory usage should not increase,
> and I'm a bit confused, how can the program run out of memory if it can
> easily compute at least a few iterations..
> 
> I've tried to use Pympler, but I've understood that it doesn't show the
> memory usage of NumPy arrays.. ?
> 
> I also tried gc.set_debug(gc.DEBUG_UNCOLLECTABLE) and then printing
> gc.garbage at each iteration, but that doesn't show anything.
> 
> Does anyone have any ideas how to debug this kind of memory leak bug?
> And how to find out whether the bug is in my code, NumPy or elsewhere?
> 
> Thanks for any help!
> Jaakko
> ___
> 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

Re: [Numpy-discussion] another discussion on numpy correlate (and convolution)

[Pierre Haessig]

Hi,

Le 22/02/2013 17:40, Matthew Brett a écrit :
> >From complete ignorance, do you think it is an option to allow a
> (n_left, n_right) tuple as a value for 'mode'?
>
That may be an option. Another one would be to add some kind of `bounds`
option which would be set to None by default but would accept the
(n_left, n_right) tuple and would override `mode`.

I don't know which one is better.

The only thing I've in mind which may cause confusion is that `mode`
normally receives a string ('valid', 'same', 'full') but it also accept
corresponding integer codes (undocumented, but I guess it corresponds to
a old signature of that function). So I wonder if there could be a
confusion between :
* mode = n
* mode = (n_left, n_right)

What do you think ?

Best,
Pierre



signature.asc
Description: OpenPGP digital signature
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion