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