[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