Equality of dtypes does not imply equality of type kinds
Consider this (on a 64bit platform):
numpy.dtype('q') == numpy.dtype('l') True
but
numpy.dtype('q').char == numpy.dtype('l').char False
Is that intended? Shouldn't dtype constructor "normalize" 'l' to 'q' (or 'i')?
Hi, On Tue, Jan 13, 2015 at 12:03 AM, Alexander Belopolsky <ndarray@mac.com> wrote:
Consider this (on a 64bit platform):
numpy.dtype('q') == numpy.dtype('l') True
numpy.dtype('q').char == numpy.dtype('l').char False
Is that intended? Shouldn't dtype constructor "normalize" 'l' to 'q' (or 'i')?
'q' is defined as NPY_LONGLONGLTR, while 'l' is NPY_LONGLTR [here] <https://github.com/numpy/numpy/blob/maintenance/1.9.x/numpy/core/include/numpy/ndarraytypes.h#L102> . Similar issue was raised on Issue 5426 <https://github.com/numpy/numpy/issues/5426#issuecomment68942373>. Even I am not aware of the exact reason, but hope it helps. Also,
numpy.dtype('q').num 9 numpy.dtype('l').char 7
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion _______________________________________________
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Mon, Jan 12, 2015 at 12:14 PM, Maniteja Nandana < maniteja.modesty067@gmail.com> wrote:
Hi,
On Tue, Jan 13, 2015 at 12:03 AM, Alexander Belopolsky <ndarray@mac.com> wrote:
Consider this (on a 64bit platform):
numpy.dtype('q') == numpy.dtype('l') True
numpy.dtype('q').char == numpy.dtype('l').char False
Is that intended? Shouldn't dtype constructor "normalize" 'l' to 'q' (or 'i')?
'q' is defined as NPY_LONGLONGLTR, while 'l' is NPY_LONGLTR [here] <https://github.com/numpy/numpy/blob/maintenance/1.9.x/numpy/core/include/numpy/ndarraytypes.h#L102> . Similar issue was raised on Issue 5426 <https://github.com/numpy/numpy/issues/5426#issuecomment68942373>. Even I am not aware of the exact reason, but hope it helps. Also,
numpy.dtype('q').num 9 numpy.dtype('l').char 7
Numpy basically has two different type systems. The basic system is based on C types  int, long, etc.  and on top of that there is a precision based system. The letters and number versions are C, while the dtype equality is precision. That is to say, in this case C long has the same precision as C long long. That varies depending on the platform, which is one reason the precision nomenclature came in. It can be confusing, and I've often fantasized getting rid of the long type altogether ;) So it isn't exactly intended, but there is a reason... Chuck
On Mon, Jan 12, 2015 at 8:48 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
That is to say, in this case C long has the same precision as C long
long. That varies depending on the platform, which is one reason the precision nomenclature came in. It can be confusing, and I've often fantasized getting rid of the long type altogether ;) So it isn't exactly intended, but there is a reason... It is also confusing that numpy has two constructors that produce 32bit integers on 32bit platforms and 64bit integers on 64bit platforms, but neither of these constructors is called "long". Instead, they are called numpy.int_ and numpy.intp.
On Tue Jan 13 04:23:22 2015 GMT+0100, Alexander Belopolsky wrote:
On Mon, Jan 12, 2015 at 8:48 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
That is to say, in this case C long has the same precision as C long
long. That varies depending on the platform, which is one reason the precision nomenclature came in. It can be confusing, and I've often fantasized getting rid of the long type altogether ;) So it isn't exactly intended, but there is a reason...
It is also confusing that numpy has two constructors that produce 32bit integers on 32bit platforms and 64bit integers on 64bit platforms, but neither of these constructors is called "long". Instead, they are called numpy.int_ and numpy.intp.
There is np.long. int_ is python int which is long. intp is actually ssizet.  Sebastian
On Mon, Jan 12, 2015 at 7:23 PM, Alexander Belopolsky <ndarray@mac.com> wrote:
On Mon, Jan 12, 2015 at 8:48 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
I've often fantasized getting rid of the long type altogether ;) So it isn't exactly intended, but there is a reason...
It is also confusing that numpy has two constructors that produce 32bit integers on 32bit platforms and 64bit integers on 64bit platforms, but neither of these constructors is called "long". Instead, they are called numpy.int_ and numpy.intp.
I'm pretty sure that numpy.int_ will produce a 32 bit type in Windows64  because a long on Windows64 is 32 bit (at least with the MS compiler). Which sucks, I'm pretty amazed that python went with "platformlong" for it's int, rather than "32 bit int" or "64 bit int". Sigh. CHB  Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 5266959 voice 7600 Sand Point Way NE (206) 5266329 fax Seattle, WA 98115 (206) 5266317 main reception Chris.Barker@noaa.gov
participants (5)

Alexander Belopolsky

Charles R Harris

Chris Barker

Maniteja Nandana

Sebastian Berg