As of 1.5.1 this worked:
>>> numpy.__version__
1.5.1
>>> numpy.uint64(5) & 3
1L
So, this is a regression and a bug. It should be fixed so that it doesn't
raise an error. I believe the scalars were special cased so that a raw 3 would
not be interpreted as a signed int when it is clearly unsigned. The
casting rules were well established over a long period. They had issues, but
they should not have been changed like this in a 1.X release.
Fortunately there are work-arounds and these issues arise only in corner cases,
but we should strive to do better.
-Travis
On Apr 6, 2012, at 12:45 AM, Charles R Harris wrote:
>
>
> On Thu, Apr 5, 2012 at 11:39 PM, Charles R Harris <charlesr.har...@gmail.com>
> wrote:
>
>
> On Thu, Apr 5, 2012 at 11:16 PM, Travis Oliphant <tra...@continuum.io> wrote:
> Which version of NumPy are you using. This could be an artefact of the new
> casting rules.
>
> This used to work. So, yes, this is definitely a bug.
>
>
> It's because the '3' is treated as signed, so the uint64 needs to be cast to
> something of higher precision, of which there is none. You can either use
> uint64(3) or just stick to int64. I don't know if this used to work or not,
> mixing signed and unsigned has always led to higher precision in arithmetic
> operations, even (mistakenly in my opinion) promoting uint64(5) + 3 to lower
> precision float64.
>
>
> In particular, in this case it is because two scalars are used. It works fine
> for arrays
>
> In [11]: ones(3, uint64) & 3
> Out[11]: array([1, 1, 1], dtype=uint64)
>
> Chuck
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
