Equality of dtypes does not imply equality of type kinds
Consider this (on a 64-bit 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 64-bit 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/num...> . Similar issue was raised on Issue 5426 <https://github.com/numpy/numpy/issues/5426#issuecomment-68942373>. 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-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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 64-bit 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/num...> . Similar issue was raised on Issue 5426 <https://github.com/numpy/numpy/issues/5426#issuecomment-68942373>. 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 32-bit integers on 32-bit platforms and 64-bit integers on 64-bit 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 32-bit integers on 32-bit platforms and 64-bit integers on 64-bit 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 32-bit integers on 32-bit platforms and 64-bit integers on 64-bit 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) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
participants (5)
-
Alexander Belopolsky -
Charles R Harris -
Chris Barker -
Maniteja Nandana -
Sebastian Berg