shape is (3,4) or (3L,4L) ?
Hello List, I am teaching a Python programming class where students use their own computer. When I create an array with 3 rows and 4 columns, a = zeros((3,4)), and ask for the shape, shape(a), then some students get (3,4), while others get (3L,4L). I guess the 3L and 4L are long integers. I wonder why they don't all get the same thing. They all installed numpy through Canopy Express. Any thoughts? Is this a setting in printoptions maybe? Thanks, Mark
Are they all using the same platform ? I suspect you're seeing the (3L, 4L)
on windows 64 bits, correct ?
FWIW, the numpy provided in Canopy is straight up upstream numpy + few
patches not merged in releases yet, and any divergence from upstream would
be considered as a bug by the canopy packaging people (i.e. me :-) ).
David
On Fri, Sep 13, 2013 at 9:07 AM, Mark Bakker
Hello List,
I am teaching a Python programming class where students use their own computer.
When I create an array with 3 rows and 4 columns, a = zeros((3,4)), and ask for the shape, shape(a), then some students get (3,4), while others get (3L,4L).
I guess the 3L and 4L are long integers. I wonder why they don't all get the same thing. They all installed numpy through Canopy Express. Any thoughts? Is this a setting in printoptions maybe?
Thanks,
Mark
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Now that you mention it, (3L,4L) probably indeed occurs on Windows 64 bit installations. Not sure about Mac 64 bit. I haven't tried that. So, is it desirable that the 32bit returns different integers than the 64bit? I would guess not. Thanks, Mark Are they all using the same platform ? I suspect you're seeing the (3L, 4L)
on windows 64 bits, correct ?
FWIW, the numpy provided in Canopy is straight up upstream numpy + few patches not merged in releases yet, and any divergence from upstream would be considered as a bug by the canopy packaging people (i.e. me :-) ).
David
Hello List,
I am teaching a Python programming class where students use their own computer.
When I create an array with 3 rows and 4 columns, a = zeros((3,4)), and ask for the shape, shape(a), then some students get (3,4), while others get (3L,4L).
I guess the 3L and 4L are long integers. I wonder why they don't all get the same thing. They all installed numpy through Canopy Express. Any thoughts? Is this a setting in printoptions maybe?
Thanks,
Mark
Hi, Le 13/09/2013 10:32, Mark Bakker a écrit :
Now that you mention it, (3L,4L) probably indeed occurs on Windows 64 bit installations. Not sure about Mac 64 bit. I haven't tried that.
So, is it desirable that the 32bit returns different integers than the 64bit? I would guess not. What I find strange is that on my 64 bits Debian I get (3,4) and not (3L,4L)...
Pierre
On Fri, Sep 13, 2013 at 9:51 AM, Pierre Haessig
Hi,
Le 13/09/2013 10:32, Mark Bakker a écrit :
Now that you mention it, (3L,4L) probably indeed occurs on Windows 64 bit installations. Not sure about Mac 64 bit. I haven't tried that.
So, is it desirable that the 32bit returns different integers than the 64bit? I would guess not. What I find strange is that on my 64 bits Debian I get (3,4) and not (3L,4L)...
The Python `int` type represents a C `long` integer. On almost all 32-bit platforms, a C `long` is 32-bits, and memory addresses and offsets are also 32-bits. On 64-bit platforms, memory addresses and offsets are 64-bits, but nothing in the C standard forces the `long` type to be 64-bits. Most UNIXy 64-bit platforms choose to make the `long` type 64-bits, but Win64 decided to keep them 32-bits for binary compatibility with the Windows API. Since ndarray sizes measure things the size of memory offsets, they need to be 64-bit on 64-bit platforms. On most platforms, this fits into a Python `int`. On Win64, they don't, so they get promoted to the unbounded Python `long` types. Is it desirable? Not really, but it is typically harmless. If you have code that is supposed to take ndarray shapes and does not accept either integer type, it is broken even if ndarray.shape always gave out `long` integers on all platforms. The only place this is really a problem is in things like doctest, where the string representation is being compared. But even then, floating point is going to be a *much* bigger problem. -- Robert Kern
Hi Robert, Le 13/09/2013 11:22, Robert Kern a écrit :
The Python `int` type represents a C `long` integer. On almost all 32-bit platforms, a C `long` is 32-bits, and memory addresses and offsets are also 32-bits. On 64-bit platforms, memory addresses and offsets are 64-bits, but nothing in the C standard forces the `long` type to be 64-bits. Most UNIXy 64-bit platforms choose to make the `long` type 64-bits, but Win64 decided to keep them 32-bits for binary compatibility with the Windows API.
[...]
Thanks for the nice explanation ! Pierre
participants (4)
-
David Cournapeau
-
Mark Bakker
-
Pierre Haessig
-
Robert Kern