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