[SciPy-dev] Pre-release fixes

Travis Oliphant oliphant at ee.byu.edu
Fri Oct 1 18:12:53 EDT 2004


Robert Kern wrote:

> Travis Oliphant wrote:
> [snip]
>
>> 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.
>
>
> Check the signatures again. The logical_* functions use 
> divide_safe_signatures which does not output to UInt8.

O.K..

Apparently, the logical_and and logical_or functions cannot be converted 
to have UInt8 output and still have reduce work.

Reduce will only work reliably when the output type is the same as the 
input type.  As logical_and and logical_or are used with reduce quite a 
bit, I think our best option is to do what Robert was doing and keep 
logical_and, logical_or, and logical_xor  as returning the type of their 
inputs.

So, if there are no complaints,  go ahead Robert and submit the changes 
you have made to CVS (I won't get in your way again...) so that 
divide_safe_signatures are O.K. and the logical_XXX functions are 
changed so the output type is the same as the input type.

-Travis






More information about the SciPy-Dev mailing list