<div dir="ltr"><span style="font-family:arial;font-size:small">On Fri, Sep 13, 2013 at 9:51 AM, Pierre Haessig <<a href="mailto:pierre.haessig@crans.org">pierre.haessig@crans.org</a>> wrote:</span><br>><br>> Hi,<br>

><br>> Le 13/09/2013 10:32, Mark Bakker a écrit :<br>> > Now that you mention it, (3L,4L) probably indeed occurs on Windows 64<br>> > bit installations.<br>> > Not sure about Mac 64 bit. I haven't tried that.<br>

> ><br>> > So, is it desirable that the 32bit returns different integers than the<br>> > 64bit? I would guess not.<br>> What I find strange is that on my 64 bits Debian I get (3,4) and not<br>> (3L,4L)...<br>

<br>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.<div>

<br></div><div>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.</div>

<div><br></div><div>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.<br>

<br>--<br>Robert Kern<br></div></div>