Menu
▾
▴
numpy-discussion
|
From: Larry D. <la...@pa...> - 2002-05-28 17:13:22
|
Hello, I recently discovered the following behavior when fetching values from a Numeric array. Can somebody offer some insight? #1) import Numeric a = Numeric.zeros((2, 2), 'i') n = a[1, 1] # fetch interesting value from array print n a[1, 1] = 10 # change array print n # blam print type(n) # huh [bash]$ python 1.py 0 10 <type 'array'> but #2) import Numeric a = Numeric.zeros((2,), 'i') n = a[1] print n a[1] = 10 print n print type(n) [bash]$ python 2.py 0 0 <type 'int'> #2 works the way one would expect, and #1 does not (n changes). They should at least both behave the same. :-) At a minimum, naive use of arrays can lead to confusing or disastrous results, since a single value fetched from an array can change behind your back. It appears n is aliased into a, but preserves its value when a is deleted (with del(a)). What happens to the "rest of" a? I'm using Python 2.2, Numeric-21.0, on both Unix and Win32. Thanks, Larry |
|
From: Pearu P. <pe...@ce...> - 2002-05-28 19:40:17
|
On Tue, 28 May 2002, Larry Denneau wrote:
> Hello,
>
> I recently discovered the following behavior when fetching values
> from a Numeric array. Can somebody offer some insight?
>
> #1)
>
> import Numeric
>
> a = Numeric.zeros((2, 2), 'i')
> n = a[1, 1] # fetch interesting value from array
> print n
> a[1, 1] = 10 # change array
> print n # blam
> print type(n) # huh
>
> [bash]$ python 1.py
> 0
> 10
> <type 'array'>
>
> but
>
> #2)
>
> import Numeric
>
> a = Numeric.zeros((2,), 'i')
> n = a[1]
> print n
> a[1] = 10
> print n
> print type(n)
>
> [bash]$ python 2.py
> 0
> 0
> <type 'int'>
>
> #2 works the way one would expect, and #1 does not (n changes).
> They should at least both behave the same. :-) At a minimum, naive
> use of arrays can lead to confusing or disastrous results, since
> a single value fetched from an array can change behind your back.
Use
a[1][1] = 10
and the output will be
0
0
<type 'int'>
I find it is an useful feature in Numeric to have both behaviours of
either using a[1,1] or a[1][1]. You may want to dig into Numeric's
userguide to get a more detailed explanation of the differences.
Regards,
Pearu
|
|
From: Pearu P. <pe...@ce...> - 2002-05-28 19:52:31
|
On Tue, 28 May 2002, Pearu Peterson wrote: <snip> > Use > > a[1][1] = 10 > Oops, I meant n = a[1][1] Pearu |
|
From: Larry D. <la...@pa...> - 2002-05-28 20:03:28
|
Pearu Peterson said: > > On Tue, 28 May 2002, Larry Denneau wrote: > > > Hello, > > > > I recently discovered the following behavior when fetching values > > from a Numeric array. Can somebody offer some insight? > > > > #1) > > > > import Numeric > > > > a = Numeric.zeros((2, 2), 'i') > > n = a[1, 1] # fetch interesting value from array > > print n > > a[1, 1] = 10 # change array > > print n # blam > > print type(n) # huh > > > > [bash]$ python 1.py > > 0 > > 10 > > <type 'array'> [ deleted] > Use > > a[1][1] = 10 > > and the output will be > > 0 > 0 > <type 'int'> > > I find it is an useful feature in Numeric to have both behaviours of > either using a[1,1] or a[1][1]. You may want to dig into Numeric's > userguide to get a more detailed explanation of the differences. > > Regards, > Pearu Hi Pearu, I assume you mean n = a[1][1] which produces the expected behavior. All the Numpy documentation examples (see http://pfdubois.com/numpy/html2/numpy-6.html#pgfId-36033, "Getting and Stting Array Values") use the [x, y] notation instead of [x][y], so I would consider this a bug in the documentation, since the [x, y] method leads to unexpected behavior. I'm still curious what happens to the original array when n=a[1, 1] del(a) but that may have to wait until I have time to peruse the Numeric source. Thanks, Larry |
|
From: Pearu P. <pe...@ce...> - 2002-05-28 20:31:09
|
Hi Larry, On Tue, 28 May 2002, Larry Denneau wrote: > All the Numpy documentation examples (see > http://pfdubois.com/numpy/html2/numpy-6.html#pgfId-36033, "Getting and > Stting Array Values") use the [x, y] notation instead of [x][y], so I > would consider this a bug in the documentation, since the [x, y] > method leads to unexpected behavior. If you look the section "Slicing Arrays" then a[1] is actually a[1,:], that is, an one dimensional array. From your description, a[1,1] must be an array with 0 rank. It seems that the Numeric documentation is missing (though, I didn't look too hard) the following rules of thumb: If `a' is rank 1 array, then a[i] is Python scalar or object. [MISSING] If `a' is rank > 1 array, then a[i] is a sub-array a[i,...] > I'm still curious what happens to the original array when > > n=a[1, 1] > del(a) I think the original array `a' is not actually deleted until `n' gets deleted. If I recall correctly, then `n' is a sub-array of `a' so that internally it contains only a reference to `a' in the sense that a.data==n.data but strides and dimension arrays differ. Pearu |
|
From: Konrad H. <hi...@cn...> - 2002-05-29 08:12:40
|
Pearu Peterson <pe...@ce...> writes: > an array with 0 rank. It seems that the Numeric documentation is missing > (though, I didn't look too hard) the following rules of thumb: > > If `a' is rank 1 array, then a[i] is Python scalar or object. [MISSING] Or rather: - If `a' is rank 1 array with elements of type Int, Float, or Complex, then a[i] is Python scalar or object. [MISSING] - If `a' is rank 1 array with elements of type Int16, Int32, Float32, or Complex32, then a[i] is a rank 0 array. [MISSING] - If `a' is rank > 1 array, then a[i] is a sub-array a[i,...] The rank-0 arrays are the #1 question topic for users of my netCDF interface (for portability reasons, netCDF integer arrays map to Int32, not Int, so scalar integers read from a netCDF array are always rank-0 arrays), and almost everybody initially claims that it's a bug, so some education seems necessary. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hi...@cn... Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- |
|
From: eric <er...@en...> - 2002-06-01 20:46:03
|
----- Original Message ----- From: "Konrad Hinsen" <hi...@cn...> To: "Pearu Peterson" <pe...@ce...> Cc: <num...@li...> Sent: Wednesday, May 29, 2002 4:08 AM Subject: Re: [Numpy-discussion] Bug: extremely misleading array behavior > Pearu Peterson <pe...@ce...> writes: > > > an array with 0 rank. It seems that the Numeric documentation is missing > > (though, I didn't look too hard) the following rules of thumb: > > > > If `a' is rank 1 array, then a[i] is Python scalar or object. [MISSING] > > Or rather: > > - If `a' is rank 1 array with elements of type Int, Float, or Complex, > then a[i] is Python scalar or object. [MISSING] > > - If `a' is rank 1 array with elements of type Int16, Int32, Float32, or > Complex32, then a[i] is a rank 0 array. [MISSING] > > - If `a' is rank > 1 array, then a[i] is a sub-array a[i,...] > > The rank-0 arrays are the #1 question topic for users of my netCDF > interface (for portability reasons, netCDF integer arrays map to > Int32, not Int, so scalar integers read from a netCDF array are always > rank-0 arrays), and almost everybody initially claims that it's a bug, > so some education seems necessary. I don't think education is the answer here. We need to change Numeric to have uniform behavior across all typecodes. Having alternative behaviors for indexing based on the typecode can lead to very difficult to find bugs. Generic routines meant to work with any Numeric type can brake a year later when someone passes in an array with a seemingly compatible type. Also, because coersion can silently change typecodes during arithmetic operations, code written expecting one behavior can all the sudden exihibit the other. That is very dangerous and hard to test. eric |
|
From: Konrad H. <hi...@cn...> - 2002-06-03 16:33:47
|
> I don't think education is the answer here. We need to change > Numeric to have uniform behavior across all typecodes. I agree that this would be the better solution. But until this is done... > Having alternative behaviors for indexing based on the typecode can > lead to very difficult to find bugs. Generic routines meant to work The differences are not that important, in most circumstances rank-0 arrays and scalars behave in the same way. The problems occur mostly with code that does explicit type checking. The best solution, in my opinion, is to provide scalar objects corresponding to low-precision ints and floats, as part of NumPy. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hi...@cn... Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- |
|
From: eric <er...@en...> - 2002-05-29 06:37:12
|
Hey Larry,
I actually thought, as you did, that indexing the array returns an element
converted to a scalar -- and it does in the "default" cases when you don't
specify a non-standard typecode.
After testing, it looks like values that are representable as native Python
types ('l', 'd', and 'D') are returned as actual values while non-standard types
are returned as views into the array. Is this intentional? It is dangerous to
have the behavior change based on the type. It seems they should all be views
or they should all be converted to a scalar.
Here is your test code modified to test all Numeric types:
import Numeric
def test_index(typecode):
print 'typcode:', typecode
a = Numeric.zeros((2, 2), typecode)
n = a[1, 1] # fetch interesting value from array
print n
a[1, 1] = 10 # change array
print n # blam
print type(n) # huh
print
print 'Numeric version:', Numeric.__version__
for t in ['i','1','s','l','f','d','F','D']:
test_index(t)
And here is the output. Look at the types returned.
C:\home\ej\wrk\junk>python num_index.py
Numeric version: 21.0
typcode: i
0
10
<type 'array'>
typcode: 1
0
10
<type 'array'>
typcode: s
0
10
<type 'array'>
typcode: l
0
0
<type 'int'>
typcode: f
0.0
10.0
<type 'array'>
typcode: d
0.0
0.0
<type 'float'>
typcode: F
0j
(10+0j)
<type 'array'>
typcode: D
0j
0j
<type 'complex'>
eric
----- Original Message -----
From: "Larry Denneau" <la...@pa...>
To: <num...@li...>
Sent: Tuesday, May 28, 2002 1:13 PM
Subject: [Numpy-discussion] Bug: extremely misleading array behavior
> Hello,
>
> I recently discovered the following behavior when fetching values
> from a Numeric array. Can somebody offer some insight?
>
> #1)
>
> import Numeric
>
> a = Numeric.zeros((2, 2), 'i')
> n = a[1, 1] # fetch interesting value from array
> print n
> a[1, 1] = 10 # change array
> print n # blam
> print type(n) # huh
>
> [bash]$ python 1.py
> 0
> 10
> <type 'array'>
>
> but
>
> #2)
>
> import Numeric
>
> a = Numeric.zeros((2,), 'i')
> n = a[1]
> print n
> a[1] = 10
> print n
> print type(n)
>
> [bash]$ python 2.py
> 0
> 0
> <type 'int'>
>
> #2 works the way one would expect, and #1 does not (n changes).
> They should at least both behave the same. :-) At a minimum, naive
> use of arrays can lead to confusing or disastrous results, since
> a single value fetched from an array can change behind your back.
>
> It appears n is aliased into a, but preserves its value when a is
> deleted (with del(a)). What happens to the "rest of" a?
>
> I'm using Python 2.2, Numeric-21.0, on both Unix and Win32.
>
> Thanks,
> Larry
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X