On Sun, Mar 31, 2013 at 12:14 AM, Ivan Oseledets
wrote:
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 submatrices from a matrix is a
On Sun, Mar 31, 2013 at 6:14 AM, Ivan Oseledets
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 c[[0,1],:200,[0,1]].shape
>>
On Sun, Mar 31, 2013 at 6:14 AM, Ivan Oseledets
wrote:
> Message: 2
> Date: Sat, 30 Mar 2013 11:13:35 -0700
> From: Jaime Fern?ndez del R?o
> Subject: Re: [Numpy-discussion] Indexing bug?
> To: Discussion of Numerical Python
> Message-ID:
>
> Content-Type: text/
Message: 2
Date: Sat, 30 Mar 2013 11:13:35 -0700
From: Jaime Fern?ndez del R?o
Subject: Re: [Numpy-discussion] Indexing bug?
To: Discussion of Numerical Python
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
On Sat, Mar 30, 2013 at 11:01 AM, Ivan Oseledets
wrot
On Sat, Mar 30, 2013 at 11:01 AM, Ivan Oseledets
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 c[[0,1],:200,[0,1]].shape
> (2, 200)
>
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
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
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), ('deg_day_south',
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
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
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
>> This should return an error and not silently truncate to int.
>
>Why do you say that?
I see now this was a Friday afternoon lack of imagination :)
The current behaviour is consistent and well
>defined:
>
>On a somewhat related note, you may also be interested in the PEP at
>
>http://docs.
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
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 approx
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 approximate
representations for many rational numbers. Stick with
integers, IMHO.
--- Nadia Dencheva
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
22 matches
Mail list logo
