[Numpy-discussion] Numpy on Mac OS X python 2.6

Pierre GM pgmdevlist@gmail....
Tue Nov 25 05:26:54 CST 2008


FYI,
I can't reproduce David's failures on my machine (intel core2 duo w/  
10.5.5)
* python 2.6 from macports
* numpy svn 6098
* GCC 4.0.1 (Apple Inc. build 5488)

I have only 1 failure:
FAIL: test_umath.TestComplexFunctions.test_against_cmath
----------------------------------------------------------------------
Traceback (most recent call last):
   File "/opt/local/lib/python2.6/site-packages/nose-0.10.4-py2.6.egg/ 
nose/case.py", line 182, in runTest
     self.test(*self.arg)
   File "/Users/pierregm/Computing/.pythonenvs/default26/lib/python2.6/ 
site-packages/numpy/core/tests/test_umath.py", line 423, in  
test_against_cmath
     assert abs(a - b) < atol, "%s %s: %s; cmath: %s"%(fname,p,a,b)
AssertionError: arcsin 2: (1.57079632679-1.31695789692j); cmath:  
(1.57079632679+1.31695789692j)

----------------------------------------------------------------------

(Well, there's another one in numpy.ma.min, but that's a different  
matter).



On Nov 25, 2008, at 2:19 AM, David Cournapeau wrote:

> On Mon, 2008-11-24 at 22:06 -0700, Charles R Harris wrote:
>>
>>
>> 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
>>
>
> Hm, interesting: just by grepping, I do have WORDS_BIGENDIAN defined  
> to
> 1 on *both* python 2.5 and python 2.6 on Mac OS X (running Intel).
> Looking closer, I do have the above code (conditional) in 2.5, but not
> in 2.6: it is inconditionally defined to BIGENDIAN on 2.6 !! That's
> actually part of something I have wondered for quite some time about  
> fat
> binaries: how do you handle config headers, since they are generated
> only once for every fat binary, but they should really be generated  
> for
> each arch.
>
>> 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.
>
> Hm, actually, it is a bug in numpy as much as in python: python should
> NOT include any config.h in their public namespace, and we should not
> rely on it.
>
> But with this info, it should be relatively easy to fix (by setting  
> the
> correct endianness by ourselves with some detection code)
>
> David
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion



More information about the Numpy-discussion mailing list