[SciPy-dev] [SciPy-user] linspace

Travis Oliphant oliphant.travis at ieee.org
Tue Dec 6 02:39:41 CST 2005


David M. Cooke wrote:

>Travis Oliphant <oliphant.travis at ieee.org> writes:
>
>  
>
>>David M. Cooke wrote:
>>
>>    
>>
>>>Isn't compiling for me:
>>>
>>>[snip]
>>>building 'scipy.base.multiarray' extension
>>>      
>>>
>>>scipy/base/src/arrayobject.c:3325: error: conflicting types for
>>>‘PyArray_NewFromDescr’
>>>build/src/scipy/base/__multiarray_api.h:135: error: previous
>>>declaration of ‘PyArray_NewFromDescr’ was here
>>>      
>>>
>>My bad, the new function had the wrong type-signature. There weren't a
>>lot of 64-bit changes but I would like more 64-bit testing to find
>>any more issues like this.
>>    
>>
>
>Ok, works now (almost). I get two failures for MA functions:
>
>======================================================================
>ERROR: Test of put
>----------------------------------------------------------------------
>Traceback (most recent call last):
>  File "/home/cookedm/usr/lib/python2.4/site-packages/scipy/base/tests/test_ma.py", line 277, in check_testPut
>    x[[1,4]] = [10,40]
>  File "/home/cookedm/usr/lib/python2.4/site-packages/scipy/base/ma.py", line 798, in __setitem__
>    d[index] = value
>IndexError: index (1) out of range (0<=index<=4) in dimension 0
>
>======================================================================
>ERROR: check_simple (scipy.base.shape_base.test_shape_base.test_apply_along_axis)
>----------------------------------------------------------------------
>Traceback (most recent call last):
>  File "/home/cookedm/usr/lib/python2.4/site-packages/scipy/base/tests/test_shape_base.py", line 13, in check_simple
>    assert_array_equal(apply_along_axis(len,0,a),len(a)*ones(shape(a)[1]))
>  File "/home/cookedm/usr/lib/python2.4/site-packages/scipy/base/shape_base.py", line 36, in apply_along_axis
>    outarr[ind] = res
>IndexError: index (0) out of range (0<=index<=9) in dimension 0
>
>----------------------------------------------------------------------
>Ran 157 tests in 0.819s
>  
>
O.K. Thanks... I saw these on Arnd's list as well. I'm not getting them 
on 32-bit, but I think I know where to look.

>  
>
>>>(and more)
>>>
>>>I think the declarations in
>>>scipy/base/code_generators/generate_array_api.py are out of sync with
>>>current reality.
>>>      
>>>
>>Not the probelm but your solution would be nice anyway.
>>    
>>
>
>Here's what I'm planning: Functions that are part of the API will look
>like this in the scipy/base/src/files:
>
>/*OBJECT_API
> A documentation string.
>*/
>static PyObject *
>PyArray_SomeAPIFunction(...and it's arguments)
>{
>
>generate_array_api.py will scan the source files, and generate the
>appropiate objectapi_list and multiapi_list that are (right now)
>assigned by hand in that file. To get the order, api functions will be
>listed in files array_api_order.txt and multiarray_api_order.txt.
>(The tag MULTIARRAY_API will be used for the multiarray API.)
>
>So, to add a new function: change the source file (in
>scipy/base/src/whatever), and add the function name to the appropiate
>place in the appropiate *_api_order.txt inside scipy/base/code_generators.
>
>Another thing I'm thinking about is using this to compute a hash of
>the API, so extension modules can check that they're using the same
>API as scipy. Putting this check into the import_array() macro would
>mean that it'd be easier to track down those problems where the API's
>changed, without the extension module being recompiled to match. It
>could throw a warning much like Python when it tries to run something
>compiled for an older C API.
>
>  
>
This sounds very, very good.

>[Depending how much mondo magic you'd want, it'd be possible to store
>a string representation of the API, and pinpoint precisely _where_ the
>API changed between the extension module and scipy_core -- but I'll
>leave that for another day.]
>  
>
With an extra very if you can pull that off...

-Travis





More information about the Scipy-dev mailing list