On Sun, Mar 31, 2013 at 12:14 AM, Ivan Oseledets
ivan.oseled...@gmail.comwrote:
snip
Oh! So it is not a bug, it is a feature, which is completely
incompatible with other array based languages (MATLAB and Fortran). To
me, I can not find a single explanation why it is so in numpy.
Taking
On Sun, Mar 31, 2013 at 6:14 AM, Ivan Oseledets
ivan.oseled...@gmail.com wrote:
I am using numpy 1.6.1,
and encountered a wierd fancy indexing bug:
import numpy as np
c = np.random.randn(10,200,10);
In [29]: print c[[0,1],:200,:2].shape
(2, 200, 2)
In [30]: print
On Sun, Mar 31, 2013 at 6:14 AM, Ivan Oseledets
ivan.oseled...@gmail.com wrote:
Message: 2
Date: Sat, 30 Mar 2013 11:13:35 -0700
From: Jaime Fern?ndez del R?o jaime.f...@gmail.com
Subject: Re: [Numpy-discussion] Indexing bug?
To: Discussion of Numerical Python numpy-discussion@scipy.org
I am using numpy 1.6.1,
and encountered a wierd fancy indexing bug:
import numpy as np
c = np.random.randn(10,200,10);
In [29]: print c[[0,1],:200,:2].shape
(2, 200, 2)
In [30]: print c[[0,1],:200,[0,1]].shape
(2, 200)
It means, that here fancy indexing is not working right for a 3d array.
Is
On Sat, Mar 30, 2013 at 11:01 AM, Ivan Oseledets
ivan.oseled...@gmail.comwrote:
I am using numpy 1.6.1,
and encountered a wierd fancy indexing bug:
import numpy as np
c = np.random.randn(10,200,10);
In [29]: print c[[0,1],:200,:2].shape
(2, 200, 2)
In [30]: print
I am either getting a nasty bug when indexing structured arrays, or I
don't really understand how they work. I have imported some data using
genfromtxt and an associated list of dtypes:
ndtype=[('include', int), ('year', int), ('month', int), ('day', int),
('deg_day_north', int),
Figured out why this does not work. Sorry and thanks.
cf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 behaviour is
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 current behaviour
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
consistent with
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 method)
for
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
objects can be passed
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 for
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 be
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
Is indexing with floats really allowed in numpy?
a=numpy.array([1,2,3,4])
a[2.99]
3
Nadia Dencheva
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
This should return an error and not silently truncate to int.
Nadia
Lou Pecora wrote:
Looks like it truncates to an int. But I wouldn't do
it especially if you use floating operations (+,*,/,
etc.) since what you get may not truncate to the
integer you expect. Remember floats are
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)]
We certainly can't change it now (just imagine all the code out there
that
18 matches
Mail list logo
