[Numpy-discussion] Binary ufuncs: minimum

Charles R Harris charlesr.harris at gmail.com
Tue May 27 12:30:42 EDT 2008


On Tue, May 27, 2008 at 10:14 AM, Sebastian Haase <haase at msg.ucsf.edu>
wrote:

> On Tue, May 27, 2008 at 6:06 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> > On Tue, May 27, 2008 at 9:09 AM, Robert Kern <robert.kern at gmail.com>
> wrote:
> >>
> >> On Tue, May 27, 2008 at 2:51 AM, Stéfan van der Walt <stefan at sun.ac.za>
> >> wrote:
> >> > Did this change recently?
> >> >
> >> > In [33]: np.__version__
> >> > Out[33]: '1.1.0.dev5211'
> >> >
> >> > In [34]: np.minimum(np.uint8(164), np.uint64(12807)).dtype
> >> > Out[34]: dtype('uint64')
> >> >
> >> > But yes, that looks like it should return a uint8.
> >>
> >> While it is possible for the result to fit into uint8, that would
> >> break the generic ufunc casting rules.
> >
> > What generic rules? If you look, you will already find exceptions. And
> > should such rules apply to the bitwise operators? The shift operators?
> What
> > are the rules for comparing strings with numbers?
> > I put posted these results for comment and review because they will soon
> be
> > made permanent. I also don't think ufuncs should return object arrays in
> any
> > circumstance that doesn't have an object array as part of the input.
> >
> > Chuck
> >
>
> What do you expect from:
> >>> np.minimum(np.uint8(164), np.uint64(160)).dtype
> ?
> uint64 I guess, right !?
>

Yep, that's what happens -- ('Q','B'). I would argue that ('Q','b') should
return q instead of double, following the 'rule' of preserving the size of
the largest type when possible. It is the mixture of signed with unsigned
types that causes type promotion to occur, the reasoning being that the
unsigned type can't hold negative numbers.

There is a problem with changing this with the current code as the existing
ufuncs don't accept mixed types as input, although it looks to me like the
stored signatures allow this. But returning a double (53 bits precision) vs
'Q' (64 bits), doesn't solve the precision problem and may misleadingly
imply that it does. And in this case there is a solution.

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


More information about the NumPy-Discussion mailing list