[Numpy-discussion] Possible errors in type promotion in binary ufuncs

[Charles R Harris]

On Tue, May 27, 2008 at 2:02 PM, Travis E. Oliphant <oliphant at enthought.com>
wrote:

> Charles R Harris wrote:
> > Attached as a zip file. The mailing list is still stuck in the
> > microzone, 40kb limit.
>
> The type promotion rules are the same for all the ufuncs.   I'm not sure
> what the value is in going over each binary ufunc one-by-one.    The
> behavior is based on how ufuncs are found and the casting rules.
>
> In other words, these are not independently coded,  so why are you going
> over each one separately.
>

Because they aren't all the same. That's why I picked out samples of
different sorts rather than post the whole thing. And yes, it is needed to
review everything also because checking what you say the code does against
what it actually does is the whole point of writing unit tests.


> Your symmetry concern is minor in my mind.  You are worried about the
> difference between 'i' and 'l' for the output types.   These are the
> same type on 32-bit platforms and which one is selected is a function of
> how the ufuncs are found.
>

Well, it does indicate an asymmetry in the code. Also, I have yet to check
these on a 64 bit platform to see what happens there when i is still 32 bits
and l is 64 bits. Speaking of which, might it be better to make  long the
default accumulator type rather than int? That way it would be 64 bits on 64
bit systems.


> It is true that we have over-registered ufuncs on some platforms (i.e.
> we don't need an 'i' and an 'l' ufunc inner loop when they are the same
> type).
>

That doesn't bother me, it costs little.

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