It appears that something peculiar is going on with the numpy function
trace(). The docs say that trace(A,...) is identical to A.trace(...).
Here is a test:
A = arange(8).reshape((2,2,2))
A.trace(0,1,2)
#[Out]# array([ 3, 11])
# which is correct
trace(A,0,1,2)
#[Out]# array([6, 8])
#which is wrong
APL 2007 in Montreal (only 2 1/2 weeks away, Oct 20-22).
Summary program information is now available
on the APL2007 home page
http://www.sigapl.org/apl2007.html
with a link to the comprehensive program description at
http://www.sigapl.org/apl2007-program.html#a2
Registration
To help me understand, might someone offer some examples of
NumPy names that really should be changed?
Thank you,
Alan Isaac
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On 10/3/07, Perry Greenfield <[EMAIL PROTECTED]> wrote:
>
> On Oct 3, 2007, at 2:26 PM, Jarrod Millman wrote:
>
> >
> >> 3) Greater time should be provided to accommodate the transition. For
> >> example, there should not be deprecation warnings in the first
> >> version that this API appears in. T
On Oct 3, 2007, at 2:26 PM, Jarrod Millman wrote:
>
>> 3) Greater time should be provided to accommodate the transition. For
>> example, there should not be deprecation warnings in the first
>> version that this API appears in. The first release of this should
>> not lead to nuisance messages for
On Wed, Oct 03, 2007 at 01:50:01PM -0400, Perry Greenfield wrote:
> > Let me rephrase: we cannot change the API until 1.1, unless this is
> > seen as a bug. To which other API changes are you referring? The
> > style changes is a different matter entirely.
>
> The recent numpy and scipy threads
On 10/3/07, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
> As I understand it, the whole point of PEP-357 was to allow the coercion of
> int-like things (numpy.int32 say, or your own private integerish class) to
> be used as indices without also allowing things that aren't integers, but
> that can b
On 10/3/07, Perry Greenfield <[EMAIL PROTECTED]> wrote:
> 2) API changes should only be made in major releases, not minor
> releases (IMHO).
+1
> 3) Greater time should be provided to accommodate the transition. For
> example, there should not be deprecation warnings in the first
> version that t
Timothy Hochberg wrote:
> As I understand it, the whole point of PEP-357 was to allow the coercion
> of int-like things (numpy.int32 say, or your own private integerish
> class) to be used as indices without also allowing things that aren't
> integers, but that can be coerced to integers (floats f
On 10/3/07, Christopher Barker <[EMAIL PROTECTED]> wrote:
>
> Stefan van der Walt wrote:
> >> The current behavior is consistent and well
> >>> defined:
> >>> a[x] == a[int(x)]
>
> This is all possible because of PEP 357:
I think that the current behavior has always been possible; arbitrary
objec
Stefan van der Walt wrote:
>> The current behavior is consistent and well
>>> defined:
>>> a[x] == a[int(x)]
This is all possible because of PEP 357:
http://www.python.org/dev/peps/pep-0357/
However, when I read this from the PEP:
"""
It is not possible to use the nb_int (and __int__ special me
On Oct 3, 2007, at 1:35 PM, Stefan van der Walt wrote:
>
>>> We certainly can't change it now (just imagine all the code out
>>> there
>>> that will break); but I personally don't think it is a big problem.
>>>
>> I disagree. If people are willing to change the Class API of numpy
>> to be
>>
On Wed, Oct 03, 2007 at 11:12:07AM -0400, Perry Greenfield wrote:
>
> On Sep 28, 2007, at 4:23 PM, Stefan van der Walt wrote:
>
>> On Fri, Sep 28, 2007 at 03:07:30PM -0400, Nadia Dencheva wrote:
>>> This should return an error and not silently truncate to int.
>>
>> Why do you say that? The curren
Shouldn't x**0 be boolean for a boolean matrix?
Cheers,
Alan Isaac
>>> import numpy
>>> numpy.__version__
'1.0.3.1'
>>> x = numpy.mat('1 1;1 0',dtype='bool')
>>> x**0
matrix([[ 1., 0.],
[ 0., 1.]])
>>> x**1
matrix([[ True, True],
[ True, False]], dtype=bool)
>>> x**2
matrix([[
To follow on to my previous posting on this topic given Robert's
response.
As I said previously, I was never strongly committed to one approach
or the other. But since the v1 release has been made, I think more
care needs to be given to consideration of proposals like this before
actually
On 10/3/07, Perry Greenfield <[EMAIL PROTECTED]> wrote:
>
>
> On Sep 28, 2007, at 4:23 PM, Stefan van der Walt wrote:
>
> > On Fri, Sep 28, 2007 at 03:07:30PM -0400, Nadia Dencheva wrote:
> >> This should return an error and not silently truncate to int.
> >
> > Why do you say that? The current be
On Sep 28, 2007, at 4:23 PM, Stefan van der Walt wrote:
> On Fri, Sep 28, 2007 at 03:07:30PM -0400, Nadia Dencheva wrote:
>> This should return an error and not silently truncate to int.
>
> Why do you say that? The current behaviour is consistent and well
> defined:
>
> a[x] == a[int(x)]
>
I di
17 matches
Mail list logo
