Possible errors in type promotion in binary ufuncs
Attached as a zip file. The mailing list is still stuck in the microzone, 40kb limit. Chuck
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. 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. 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). -Travis
On Tue, May 27, 2008 at 2:02 PM, Travis E. Oliphant <oliphant@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
participants (2)
-
Charles R Harris
-
Travis E. Oliphant