[Numpy-discussion] Equality of dtypes does not imply equality of type kinds

[Charles R Harris]

On Mon, Jan 12, 2015 at 12:14 PM, Maniteja Nandana <
maniteja.modesty067 at gmail.com> wrote:

> Hi,
>
> On Tue, Jan 13, 2015 at 12:03 AM, Alexander Belopolsky <ndarray at 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/numpy/ndarraytypes.h#L102> .
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150112/7359e65c/attachment.html>