[Numpy-discussion] shape is (3,4) or (3L,4L) ?

[Robert Kern]

On Fri, Sep 13, 2013 at 9:51 AM, Pierre Haessig <pierre.haessig at crans.org>
wrote:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130913/1dff6a2c/attachment.html>