[Numpy-discussion] On Numexpr and uint64 type

[Charles R Harris]

On Mon, Mar 10, 2008 at 11:08 AM, Francesc Altet <faltet at carabos.com> wrote:

> Hi,
>
> In order to allow in-kernel queries in PyTables (www.pytables.org) work
> with unsigned 64-bit integers, we would like to see uint64 support in
> Numexpr (http://code.google.com/p/numexpr/).
>
> To do this, we have to decide first how uint64 interacts with other
> types.  For example, which should be the outcome of:
>
> numpy.array([1], 'int64') / numpy.array([2], 'uint64')
>
> Basically, there are a couple of possibilities:
>
> 1) To follow the behaviour of NumPy and upcast both operands to float64
> and do the operation.  That is:
>
> In [21]: numpy.array([1], 'int64') / numpy.array([2], 'uint64')
> Out[21]: array([ 0.5])
>
> 2) Implement support for uint64 as a non-upcastable type, so that one
> cannot merge uint64 operands with other types.  That is:
>
> In [21]: numpy.array([1], 'int64') / numpy.array([2], 'uint64')
> Out[21]: TypeError: unsupported operand type(s) for /: 'int64'
> and 'uint64'
>
> Solution 1) is appealing because is how NumPy works, but I don't
> personally like the upcasting to float64.  First of all, because you
> transparently convert numbers potentially loosing the least significant
> digits.  Second, because an operation between integers gives a float as
> a result, and this is different for typical programming languages.
>

I don't like the up(down)casting either. I suspect the original
justification was preserving precision, but it doesn't do that. Addition of
signed and unsinged numbers are the same in modular arithmetic, so simply
treating everything as uint64 would, IMHO, be the best option there and for
multiplication. Not everything has a modular inverse, but truncation is the
C solution in that case. The question seems to be whether to return a signed
or unsigned integer. Hmm. I would go for unsigned, which could be converted
to signed by casting. The sign of the remainder might be a problem, though,
which would give unusual truncation behavior.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080310/e5c94514/attachment.html>