On Fri, Jun 10, 2011 at 8:51 PM, Keith Goodman <kwgood...@gmail.com> wrote:
> On Fri, Jun 10, 2011 at 6:35 PM, Charles R Harris
> <charlesr.har...@gmail.com> wrote:
> > On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau <sh...@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
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
