On Mon, Nov 24, 2008 at 9:58 PM, Charles R Harris <[EMAIL PROTECTED]
> wrote:
>
>
> On Mon, Nov 24, 2008 at 9:38 PM, Charles R Harris <
> [EMAIL PROTECTED]> wrote:
>
>>
>>
>> On Mon, Nov 24, 2008 at 9:02 PM, David Cournapeau <[EMAIL PROTECTED]>wrote:
>>
>>> On Tue, Nov 25, 2008 at 12:41 PM, Charles R Harris
>>> <[EMAIL PROTECTED]> wrote:
>>> >
>>>
>>> > 1) This problem is specific to 2.6 and 2.5 works.
>>>
>>> Yes
>>>
>>> > 2) It's on Intel hardware?
>>>
>>> Yes.
>>>
>>> Here is a minimal test which shows the problem:
>>>
>>> import numpy as np
>>> assert np.dtype('<f4').isnative
>>>
>>
>> So what does dtype(float32).descr and dtype(float32).byteorder show?
>>
>
> Numpy gets it's byte order from the macro WORDS_BIGENDIAN defined by
> Python. Try
>
> [EMAIL PROTECTED] numpy.git]$ grep -r -n WORDS_BIGENDIAN
> /usr/include/python2.5/*
> /usr/include/python2.5/pyconfig-32.h:902:#define WORDS_BIGENDIAN 1
> /usr/include/python2.5/pyconfig-32.h:905:/* #undef WORDS_BIGENDIAN */
>
> or the OS X equivalent.
>
Well, it may not be that easy to figure. The (generated) pyconfig-32.h has
/* Define to 1 if your processor stores words with the most significant byte
first (like Motorola and SPARC, unlike Intel and VAX).
The block below does compile-time checking for endianness on platforms
that use GCC and therefore allows compiling fat binaries on OSX by using
'-arch ppc -arch i386' as the compile flags. The phrasing was choosen
such that the configure-result is used on systems that don't use GCC.
*/
#ifdef __BIG_ENDIAN__
#define WORDS_BIGENDIAN 1
#else
#ifndef __LITTLE_ENDIAN__
/* #undef WORDS_BIGENDIAN */
#endif
#endif
And I guess that __BIG_ENDIAN__ is a compiler flag, it isn't in any of the
include files. In any case, this looks like a Python bug or the Python folks
have switched their API on us.
Chuck
>
>
_______________________________________________
Numpy-discussion mailing list
[email protected]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
