[Numpy-discussion] numpy type mismatch

[Benjamin Root]

On Fri, Jun 10, 2011 at 8:51 PM, Keith Goodman <kwgoodman at gmail.com> wrote:

> On Fri, Jun 10, 2011 at 6:35 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> > On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau <shish at keba.be>
> wrote:
>
> >> But isn't it a bug if numpy.dtype('i') != numpy.dtype('l') on a 32 bit
> >> computer where both are int32?
> >>
> >
> > Maybe yes, maybe no ;) They have different descriptors, so from numpy's
> > perspective they are different, but at the hardware/precision level they
> are
> > the same. It's more of a decision as to what  != means in this case.
> Since
> > numpy started as Numeric with only the c types the current behavior is
> > consistent, but that doesn't mean it shouldn't change at some point.
>
> Maybe this is the same question, but are you maybe yes, maybe no on this
> too:
>
>    >>> type(np.sum([1, 2, 3], dtype=np.int32)) == np.int32
>    False
>
> Ben, what happens if you put an axis in there? Like
>
>    >>> np.sum([[1, 2, 3], [4,5,6]], axis=0).dtype == np.int32
>

The same thing happens as before.


>
> Just wondering if this is another different-dtype-for-different-axis case.
>

No, I think Chuck has it right and that this is the result of the recent
cleanup work for ufunc casting rules.  However, I am so entirely unfamiliar
with ufuncs that I really don't know how to investigate this.  Can we get
Mark Wiebe's opinion on this?  I suspect he might recognize the problem
right away.

Ben Root
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110610/191e9e92/attachment.html>