On Wed, Jul 23, 2014 at 9:57 PM, Robert Kern <robert.k...@gmail.com> wrote:
> That's what I'm suggesting that we change: make
> `type(ndarray.shape[i])` be `np.intp` instead of `long`.
>
> However, I'm not sure that this is an issue with numpy 1.8.0 at least.
> I can't reproduce the reported problem on Win64:
>
> In [12]: import numpy as np
>
> In [13]: from numpy.lib import stride_tricks
>
> In [14]: import sys
>
> In [15]: b = stride_tricks.as_strided(np.zeros(1), shape=(100000,
> 200000, 400000), strides=(0, 0, 0))
>
> In [16]: b.shape
> Out[16]: (100000L, 200000L, 400000L)
>
> In [17]: np.product(b.shape)
> Out[17]: 8000000000000000
>
> In [18]: np.product(b.shape).dtype
> Out[18]: dtype('int64')
>
> In [19]: sys.maxint
> Out[19]: 2147483647
>
> In [20]: np.__version__
> Out[20]: '1.8.0'
>
> In [21]: np.array(b.shape)
> Out[21]: array([100000, 200000, 400000], dtype=int64)
>
>
> This is on Python 2.7, so maybe something got weird in the Python 3
> version that Chris Gohlke tested?
Ah yes, naturally. Because there is no separate `long` type in Python
3, np.asarray() can't use the type to distinguish what type to build
the array. Returning np.intp objects in the tuple would resolve the
problem in much the same way the problem is currently resolved in
Python 2. This would also have the effect of unifying API on all
platforms: currently, win64 is the only platform where the `.shape`
tuple and related attribute returns Python longs instead of Python
ints.
--
Robert Kern
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
