Den 13.06.2010 18:19, skrev Charles R Harris:
>
> It's the combination of unsigned with signed that causes the
> promotion. The int64 type can't hold the largest values in uint64.
> Strictly speaking, doubles can't hold either of the 64 bit integer
> types without loss of precision but at least
On Sun, Jun 13, 2010 at 9:20 AM, Pearu Peterson wrote:
> On Sun, Jun 13, 2010 at 4:45 PM, Nadav Horesh
> wrote:
> > int can be larger than numpy.int64 therefore it should be coerced to
> float64 (or float96/float128)
>
> Ok, I see. The results type is defined by the types of operands, not
> by th
On Sun, Jun 13, 2010 at 4:45 PM, Nadav Horesh wrote:
> int can be larger than numpy.int64 therefore it should be coerced to float64
> (or float96/float128)
Ok, I see. The results type is defined by the types of operands, not
by their values. I guess
this has been discussed earlier but with small
] Possible bug: uint64 + int gives float64
Hi,
I just noticed some weird behavior in operations with uint64 and int,
heres an example:
>>> numpy.uint64(3)+1
4.0
>>> type(numpy.uint64(3)+1)
Pearu
___
NumPy-Discussion mailing lis
Hi,
I just noticed some weird behavior in operations with uint64 and int,
heres an example:
>>> numpy.uint64(3)+1
4.0
>>> type(numpy.uint64(3)+1)
Pearu
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/l
