[SciPy-dev] Pre-release fixes

[Travis Oliphant]

Robert Kern wrote:

> Travis Oliphant wrote:
>
>> Robert Kern wrote:
>>
>>> I've just checked in a fix for fastumath's logical functions. They 
>>> used to give wrong answers on OSX and caused some tests to fail. I 
>>> believe this to be an endianness issue, but I don't have another 
>>> big-endian machine to test on. All tests still pass on Athlon/Linux.
>>>
>>> The changes made largely track what Numeric did, so I'm not sure if 
>>> these were conscious deviations to speed up fastumath or just a 
>>> failure to keep up with the bugfixes in Numeric.
>>>
>>> I have only implemented fastumath_unsigned.inc as yet. I will make 
>>> similar changes in fastumath_nounsigned.inc as I accumulate tuits.
>>>
>>> Travis, could you check my changes to make sure I didn't revert 
>>> differences you deliberately made? If they were deliberate, then we 
>>> need to figure a way to revert to the correct, if slower, Numeric 
>>> implementations on the Mac.
>>
>>
>>
>> I'm not sure what the problem is here.  But I think you undid 
>> deliberate changes that have implications for alter_numeric() and 
>> need to be discussed. I had intentially made the results of all 
>> logical operations be unsigned bytes.  What was broken about this on 
>> the Mac?
>
>
> Here are the tests that fail. The first two are what led me to the 
> "fix" in the first place. The CDF failures are newer (I haven't seen 
> them until today because I always used my version of 
> fastumath_unsigned.inc for some months now), but all tests pass with 
> my version.
>

I think I know what is wrong.  Apparently, the reduce method expects the 
output type to be the same as the input type.  So, when the underlying 
code is called in that context, what actually gets passed in is not an 
unsigned byte array.  Thus, when the code casts the pointer to an 
unsigned byte pointer, it is filling in only a portion of the memory.  
On little-endian machines this is working fine, but on big-endian 
machines it's the wrong portion to be filling in.   Robert's fix will 
correct the problem for reduce on MacOS but then I'm not sure that 
logical_and will work correctly on two arrays still as in that context 
the output array should be a UInt8 and so you will be filling a UInt8 
array assuming it is IntXX. 

Bottom line is I don't think the fixes will work on all platforms but 
will fix one at the expense of another?  Can you comment on this Robert?

Darn,  this seems like a pretty serious problem.

-Travis