[SciPy-dev] Pre-release fixes
rkern at ucsd.edu
Fri Oct 1 14:47:09 CDT 2004
Travis Oliphant wrote:
> 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.
CVS on Athlon/Linux:
>>> from scipy import *
>>> a = array([0,1])
>>> b = array([1,1])
array([ 0.00000000e+000, 4.94065646e-324])
array([ 0.00000000e+000 1.40129846e-45],'f')
array([ 0., 1.])
>>> import struct
>>> struct.unpack('f', '\x01\x00\x00\x00')
>>> struct.unpack('d', '\x01\x00\x00\x00\x00\x00\x00\x00')
> 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?
Yes, just changing the signatures to correctly output to UInt8 solves
the logical_and(a, b) problem just fine with either endianness. The
logical_and.reduce(b) problem needs more work. Even changing the
signatures still makes logical_and.reduce(b) return an array the same
type as b.
> Darn, this seems like a pretty serious problem.
rkern at ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
More information about the Scipy-dev