numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] bug triggered by array.astype()

[Travis O. <oli...@ie...>]

Gerard Vermeulen wrote:

>>>>from numpy import *
>>>>core.__version__
>>>>        
>>>>
>'0.9.5.2019'
>  
>
>>>>v = linspace(0, 2*pi)
>>>>c = (255<<24)*cos(v) + (255<<16)*cos(v+2*pi/3) + (255<<8)*cos(v+4*pi/3) + 255
>>>>c.astype(UInt32)
>>>>        
>>>>
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>SystemError: Objects/longobject.c:257: bad argument to internal function
>  
>
>
>  
>
In SVN, now a Overflow error is raised instead in this example because 
negative long integer objects are trying to be converted to unsigned 
integers (this is a Python error being raised).  We could check for this 
and instead do what the c-compiler would do in converting from signed to 
unsigned objects. 

Is that preferrable?

-Travis

Re: [Numpy-discussion] bug triggered by array.astype()

[Travis O. <oli...@ie...>]

Gerard Vermeulen wrote:

>>>>from numpy import *
>>>>core.__version__
>>>>        
>>>>
>'0.9.5.2019'
>  
>
>>>>v = linspace(0, 2*pi)
>>>>c = (255<<24)*cos(v) + (255<<16)*cos(v+2*pi/3) + (255<<8)*cos(v+4*pi/3) + 255
>>>>c.astype(UInt32)
>>>>        
>>>>
>Traceback (most recent call last):
>  File "<stdin>", line 1, in ?
>SystemError: Objects/longobject.c:257: bad argument to internal function
>  
>
>
>  
>
Thanks for this test.  The problem stems from the (255<<24) which (on 
32-bit platform) generates a long-integer object.   Currently, 
long-integers are converted to object arrays, thus this operation causes 
your entire calculation to be done using Python objects.

Then, you try to convert the whole thing to UInt32 which is giving the 
error.  I'll look into the error.

In the meantime, you can avoid going through object arrays using an 
int64 scalar:

int64(255<24)*cos(v) + ...


-Travis

[Numpy-discussion] bug triggered by array.astype()

[Gerard V. <ger...@gr...>]

>>> from numpy import *
>>> core.__version__
'0.9.5.2019'
>>> v = linspace(0, 2*pi)
>>> c = (255<<24)*cos(v) + (255<<16)*cos(v+2*pi/3) + (255<<8)*cos(v+4*pi/3) + 255
>>> c.astype(UInt32)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: Objects/longobject.c:257: bad argument to internal function
>>>

Gerard

Re: [Numpy-discussion] numpy.dot behavior with column vector and length 1 vector

[Brendan S. <bre...@ya...>]

>
> --__--__--
>
> Message: 7
> Date: Sat, 28 Jan 2006 20:52:04 -0700
> From: Travis Oliphant <oli...@ie...>
> To: Brendan Simons <bre...@ya...>,
>  numpy-discussion <num...@li...>
> Subject: Re: [Numpy-discussion] numpy.dot behavior with column  
> vector and
>  length 1 vector
>
> Brendan Simons wrote:
>
>> Is this behavior expected?  If so, why am I wrong in assuming these
>> statements should all return the same result?
>
>
> This is now fixed in SVN.
>
> -Travis

Works for me now.  Thanks!
    Brendan
--
Brendan Simons
__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Numpy-discussion] numpy.dot behavior with column vector and length 1 vector

[Travis O. <oli...@ie...>]

Brendan Simons wrote:

> Is this behavior expected?  If so, why am I wrong in assuming these  
> statements should all return the same result?


This is now fixed in SVN. 

-Travis

Re: [Numpy-discussion] numpy.dot behavior with column vector and length 1 vector

[Travis O. <oli...@ie...>]

Brendan Simons wrote:

> Is this behavior expected?  If so, why am I wrong in assuming these  
> statements should all return the same result?
>
> PyCrust 0.9.5 - The Flakiest Python Shell
> Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numpy
> >>> colVect = numpy.ones((3, 1))
> >>> colVect * 5.3
> array([[ 5.3],
>        [ 5.3],
>        [ 5.3]])
> >>> numpy.dot(colVect, 5.3)
> array([[ 5.3],
>        [ 5.3],
>        [ 5.3]])
> >>> colVect * [5.3]
> array([[ 5.3],
>        [ 5.3],
>        [ 5.3]])
> >>> numpy.dot(colVect, [5.3])
> array([ 5.3,  0. ,  0. ])


This is a dotblas bug.  You can always tell by testing out the original 
dot function:

from numpy.core.multiarray import dot as dot_

dot_(colVect, [5.3])

does not give this result.


-Travis

[Numpy-discussion] numpy.dot behavior with column vector and length 1 vector

[Brendan S. <bre...@ya...>]

Is this behavior expected?  If so, why am I wrong in assuming these  
statements should all return the same result?

PyCrust 0.9.5 - The Flakiest Python Shell
Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import numpy
 >>> colVect = numpy.ones((3, 1))
 >>> colVect * 5.3
array([[ 5.3],
        [ 5.3],
        [ 5.3]])
 >>> numpy.dot(colVect, 5.3)
array([[ 5.3],
        [ 5.3],
        [ 5.3]])
 >>> colVect * [5.3]
array([[ 5.3],
        [ 5.3],
        [ 5.3]])
 >>> numpy.dot(colVect, [5.3])
array([ 5.3,  0. ,  0. ])


   Brendan
--
Brendan Simons
__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Numpy-discussion] numpy can't use ACML

[Piotr L. <lus...@cs...>]

On Saturday 28 January 2006 19:36, George Nurser wrote:
> I'm sure this is well known, but I just realized that numpy cannot
> use the _dotblas.so that it makes when it is compiled with ACML.
> This is because ACML only has the fortran blas libraries, not cblas.
>
> numpy will find the acml libraries and use them to make a _dotblas.so
> without complaining, if you have
>
> [blas]
> blas_libs = acml
> language = f77
>   in your site.cfg.
>
> But attempting to import this _dotblas.so gives errors .... so numpy
> never actually uses it.
>
>  >>> import _dotblas.so
>
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
> ImportError: ./_dotblas.so: undefined symbol: cblas_zaxpy
>
> nm _dotblas.so gives a whole stream of undefined cblas_xxxx symbols.
>
> So what are the options? Forget about ACML? Find an optimized cblas
> for numpy _dotblas but use the ACML flapack for scipy? Persuade
> somebody to write a scipy-style ?f2py interface to generate
> _dotblas.so using the fblas?
>
> George Nurser.


There is code for that on netlib:
http://www.netlib.org/blas/blast-forum/cblas.tgz

I used it myself for my C code before and it worked just fine.

Piotr

[Numpy-discussion] numpy can't use ACML

[George N. <ag...@no...>]

I'm sure this is well known, but I just realized that numpy cannot  
use the _dotblas.so that it makes when it is compiled with ACML.
This is because ACML only has the fortran blas libraries, not cblas.

numpy will find the acml libraries and use them to make a _dotblas.so  
without complaining, if you have

[blas]
blas_libs = acml
language = f77
  in your site.cfg.

But attempting to import this _dotblas.so gives errors .... so numpy  
never actually uses it.
 >>> import _dotblas.so
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
ImportError: ./_dotblas.so: undefined symbol: cblas_zaxpy

nm _dotblas.so gives a whole stream of undefined cblas_xxxx symbols.

So what are the options? Forget about ACML? Find an optimized cblas  
for numpy _dotblas but use the ACML flapack for scipy? Persuade  
somebody to write a scipy-style ?f2py interface to generate   
_dotblas.so using the fblas?

George Nurser.

Re: [Numpy-discussion] a virtual work party: help migrate scipy.org to new wiki

[Andrew S. <str...@as...>]

I'm happy with going live now, too. So, Enthought, I humbly ask you
unleash the new site! :)

Cheers!
Andrew

Travis Oliphant wrote:

> Andrew Straw wrote:
>
>> As many of you know, a number of us have been busy migrating the
>> scipy.org website to a new, more user-friendly wiki system. The new wiki
>> is up-and-running, is more-up-to-date, and prettier-to-look at than the
>> old site.
>>  
>>
> Andrew has done an amazing job on this.  I think the time has come to
> move forward with the new site.  The most important pages have been
> moved over in my mind.  There is *a lot* of outdated material on the
> old SciPy site.  I think the best strategy is to just start using the
> new site with a link to the old stuff should someone realize that
> something is missing.
> My vote is to go "live" now.
> -Travis
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] a virtual work party: help migrate scipy.org to new wiki

[Travis O. <oli...@ie...>]

Andrew Straw wrote:

>As many of you know, a number of us have been busy migrating the
>scipy.org website to a new, more user-friendly wiki system. The new wiki
>is up-and-running, is more-up-to-date, and prettier-to-look at than the
>old site.
>  
>
Andrew has done an amazing job on this.  I think the time has come to 
move forward with the new site.  The most important pages have been 
moved over in my mind.  There is *a lot* of outdated material on the old 
SciPy site.  I think the best strategy is to just start using the new 
site with a link to the old stuff should someone realize that something 
is missing. 

My vote is to go "live" now. 

-Travis

Re: [Numpy-discussion] array dtype=object problem

[Travis O. <oli...@ie...>]

Christopher Fonnesbeck wrote:

> I am having trouble with numpy arrays that have (for some reason) an  
> "object" dtype. All that happens in my code is that float values are  
> appended to a multidimensional array, this array is transposed, and  
> the transposed array is sent to matplotlib. Unfortunately, the array  
> ends up being of type "object", which is not recognized by matplotlib:

I'm not sure why that is, but I seem to recall from code that you've 
sent me before that you intentionally use object arrays from time to 
time.   Object arrays stay object arrays unless you request 
differently.   But, object arrays will usually run more slowly than 
fixed-precision arrays.

>
> (Pdb) scatter(x,y)
> *** TypeError: function not supported for these types, and can't  
> coerce safely to supported types
>
> Moreover, this array, which clearly contains nothing but floats  
> cannot be cast to a float array:
>
> (Pdb) array(y,float)
> *** TypeError: array cannot be safely cast to required type
>
> Can anyone shed some light on this? I am utterly confused.
>

When using the array constructor to cast to another type, there is a 
check that is equivalent to the numpy command can_cast(from_dtype, 
to_dtype) that is run to see if the conversion is "safe".  Of course 
casting from an object (which could have infinite precision) to a 
fixed-precision floating-point data-type is not safe and you get this 
error.

The .astype(to_dtype) method of numpy arrays will always convert 
(force-cast) to the request type.

So,

y.astype(float) 

will work as you want.

-Travis

[Numpy-discussion] Re: [SciPy-user] Linux Installation Instructions

[Ryan K. <rya...@gm...>]

I can't access it either right now.

On 1/28/06, John Byrnes <by...@bu...> wrote:
> Is anyone else unable to access the Linux install instructions at
> http://pong.tamu.edu/tiki/tiki-view_blog_post.php?blogId=3D6&postId=3D97
>
> I get a 403 - Forbidden Page.
>
> Regards,
> John
>
> --
> Well done is better than well said.
>                 -- Benjamin Franklin
>
> _______________________________________________
> SciPy-user mailing list
> Sci...@sc...
> http://www.scipy.net/mailman/listinfo/scipy-user
>

[Numpy-discussion] array dtype=object problem

[Christopher F. <ch...@tr...>]

I am having trouble with numpy arrays that have (for some reason) an  
"object" dtype. All that happens in my code is that float values are  
appended to a multidimensional array, this array is transposed, and  
the transposed array is sent to matplotlib. Unfortunately, the array  
ends up being of type "object", which is not recognized by matplotlib:

(Pdb) y[:5]
array([575.060695363, 618.395159954, 817.767177867, 601.659726372,
        978.607427424], dtype=object)

(Pdb) scatter(x,y)
*** TypeError: function not supported for these types, and can't  
coerce safely to supported types

Moreover, this array, which clearly contains nothing but floats  
cannot be cast to a float array:

(Pdb) array(y,float)
*** TypeError: array cannot be safely cast to required type

Can anyone shed some light on this? I am utterly confused.

Thanks,
C.

--
Christopher J. Fonnesbeck

Population Ecologist, Marine Mammal Section
Fish & Wildlife Research Institute (FWC)
St. Petersburg, FL

Adjunct Assistant Professor
Warnell School of Forest Resources
University of Georgia
Athens, GA

T: 727.235.5570
E: chris at trichech.us

[Numpy-discussion] Linux Installation Instructions

[John B. <by...@bu...>]

Is anyone else unable to access the Linux install instructions at 
http://pong.tamu.edu/tiki/tiki-view_blog_post.php?blogId=6&postId=97

I get a 403 - Forbidden Page.

Regards,
John

--
Well done is better than well said.
		-- Benjamin Franklin

[Numpy-discussion] a virtual work party: help migrate scipy.org to new wiki

[Andrew S. <str...@as...>]

As many of you know, a number of us have been busy migrating the
scipy.org website to a new, more user-friendly wiki system. The new wiki
is up-and-running, is more-up-to-date, and prettier-to-look at than the
old site.

We are working to make scipy.org a portal website for all scientific
software written in Python, and not just for the packages numpy and
scipy, which happen to have their natural homes there. This wiki
structure allows peer-review-by-wiki, so please do not feel bashful
about updating any aspect of the wiki to suit your opinions.

The current address of the new site is http://new.scipy.org/Wiki Once we
go "live", we'll point http://scipy.org to this wiki.

Before we make the switch, however, there are a few things that need to
be done and a few things that should be done. This is a request for two
things:

1) Review the page http://new.scipy.org/Wiki/MigratingFromPlone and make
sure you can live with what it says. If you can't edit it.
2) Please undertake any of the tasks listed at that page. Update the
page that you're working on the task, and again when you're done.
3) (Optional) Bask in the glory of our shiny new website which will
allow NumPy/ SciPy/ Matplotlib/ IPython/ whateverelse to rule the
scientific computing world!

I'd like to ask that we try and complete these tasks as quickly as
possible. I know I'm asking a busy group of people to pitch in, but I
hope you'll agree the results will be worth it.

Thank you,
Andrew Straw

PS Sorry for the cross postings. I thought it would be important to get
as many hands involved as possible.

[Numpy-discussion] RPy with NumPy

[Sasha <nd...@ma...>]

I have succesfully (according to testall.py :-) converted RPy to use
numpy instead of Numeric.  Attached patch was tested on Linux only. I
did not attempt to create a package that would support both numpy and
Numeric, but it is easy to do. Please let me know if you are
interested.

For numpy-discussion readers: "RPy is a very simple, yet robust,
Python interface to the R Programming Language."
<http://rpy.sourceforge.net/>

For rpy-list readers: "Development for Numeric has ceased, and users
should transisition to NumPy as quickly as possible."
<http://numeric.scipy.org/>

For readers of both lists: Sorry for cross-posting.

-- sasha

Re: Fwd: [Numpy-discussion] Numpy does not compile with PY_ARRAY_TYPES_PREFIX

[Sasha <nd...@ma...>]

Sorry, I did not clean up an old build properly.  It's hard to keep up
with numpy's pace these days!

-- sasha

On 1/27/06, Andrew Straw <str...@as...> wrote:
> That's strange. In your 2nd email, you said you were using revision
> 2006, which made me think this couldn't be the issue...

Re: Fwd: [Numpy-discussion] Numpy does not compile with PY_ARRAY_TYPES_PREFIX

[Andrew S. <str...@as...>]

Sasha wrote:

>Thanks for your advise.  With the help of -E option, I've found the
>problem. I was using  the version of the header that used uint in the
>C-API.  the problem was fixed in svn r1983: 
>http://projects.scipy.org/scipy/numpy/changeset/1983 .
>
>-- sasha
>  
>
That's strange. In your 2nd email, you said you were using revision
2006, which made me think this couldn't be the issue...

Re: Fwd: [Numpy-discussion] Numpy does not compile with PY_ARRAY_TYPES_PREFIX

[Sasha <nd...@ma...>]

Thanks for your advise.  With the help of -E option, I've found the
problem. I was using  the version of the header that used uint in the
C-API.  the problem was fixed in svn r1983:=20
http://projects.scipy.org/scipy/numpy/changeset/1983 .

-- sasha




On 1/27/06, Travis Oliphant <oli...@ee...> wrote:
> Travis Oliphant wrote:
>
> > Sasha wrote:
> >
> >> On 1/27/06, David M. Cooke <co...@ph...> wrote:
> >>
> >>
> >>> You need to add #include "Python.h" as the first include (and add a
> >>> -I<python include directory> to your gcc line, of course).
> >>>
> >>
> >>
> >> Still does not work
> >>
> >>
> > It works for me.   Try the attached file.
> >
> > gcc -I /usr/include/python2.4 -I
> > /usr/lib/python2.4/site-packages/numpy/core/include -c test.c
> >
> > Worked fine.
> >
> > Maybe Python.h has to come *before* the special #define.
>
> On my system, it didn't seem to matter.  All incarnations worked.
> Perhaps there is something wrong with your installation.   Could you
> show the very first errors you are getting.  Is the wrong header being
> picked up from somewhere.
>
> Also perhaps you could look at the output of the compilation using the
> -E (pre-processor only) flag.  This might help nail down the problem.
>
> -Travis
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: Fwd: [Numpy-discussion] Numpy does not compile with PY_ARRAY_TYPES_PREFIX

[<co...@ph...>]

Sasha <nd...@ma...> writes:

> On 1/27/06, David M. Cooke <co...@ph...> wrote:
>> You need to add #include "Python.h" as the first include (and add a
>> -I<python include directory> to your gcc line, of course).
>
> Still does not work
>
>> cat test.c
> #define PY_ARRAY_TYPES_PREFIX XYZ_
> #include <Python.h>
> #include <numpy/arrayobject.h>
>
>> gcc -I Python-2.4.1/include/python2.4 -I lib/python2.4/site-packages/numpy/core/include -c test.c
> In file included from
> lib/python2.4/site-packages/numpy/core/include/numpy/arrayobject.h:1346,
>                  from test.c:3:
> lib/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:
> In function `import_array':
> lib/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:765:
> parse error before ')' token
> lib/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:765:
> parse error before ')' token
> lib/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:
> At top level:
> lib/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:771:
> parse error before "return"

Hmm, the location of that error would seem to imply it's something to
do with NDARRAY_VERSION not being defined. Maybe for some reason
you've got an old arrayobject.h, but a newer __multiarray_api.h? I'd
try blowing away your lib/python2.4/site-packages/numpy directory, and
installing again.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: Fwd: [Numpy-discussion] Numpy does not compile with PY_ARRAY_TYPES_PREFIX

[Travis O. <oli...@ee...>]

Travis Oliphant wrote:

> Sasha wrote:
>
>> On 1/27/06, David M. Cooke <co...@ph...> wrote:
>>  
>>
>>> You need to add #include "Python.h" as the first include (and add a
>>> -I<python include directory> to your gcc line, of course).
>>>   
>>
>>
>> Still does not work
>>  
>>
> It works for me.   Try the attached file.
>
> gcc -I /usr/include/python2.4 -I 
> /usr/lib/python2.4/site-packages/numpy/core/include -c test.c
>
> Worked fine.
>
> Maybe Python.h has to come *before* the special #define.

On my system, it didn't seem to matter.  All incarnations worked.  
Perhaps there is something wrong with your installation.   Could you 
show the very first errors you are getting.  Is the wrong header being 
picked up from somewhere.

Also perhaps you could look at the output of the compilation using the 
-E (pre-processor only) flag.  This might help nail down the problem.

-Travis

Re: Fwd: [Numpy-discussion] Numpy does not compile with PY_ARRAY_TYPES_PREFIX

[Travis O. <oli...@ee...>]

Sasha wrote:

>On 1/27/06, David M. Cooke <co...@ph...> wrote:
>  
>
>>You need to add #include "Python.h" as the first include (and add a
>>-I<python include directory> to your gcc line, of course).
>>    
>>
>
>Still does not work
>  
>
It works for me.   Try the attached file.

gcc -I /usr/include/python2.4 -I 
/usr/lib/python2.4/site-packages/numpy/core/include -c test.c

Worked fine.

Maybe Python.h has to come *before* the special #define.

-Travis

Re: Fwd: [Numpy-discussion] Numpy does not compile with PY_ARRAY_TYPES_PREFIX

[Sasha <nd...@ma...>]

On 1/27/06, David M. Cooke <co...@ph...> wrote:
> You need to add #include "Python.h" as the first include (and add a
> -I<python include directory> to your gcc line, of course).

Still does not work

> cat test.c
#define PY_ARRAY_TYPES_PREFIX XYZ_
#include <Python.h>
#include <numpy/arrayobject.h>

> gcc -I Python-2.4.1/include/python2.4 -I lib/python2.4/site-packages/nump=
y/core/include -c test.c
In file included from
lib/python2.4/site-packages/numpy/core/include/numpy/arrayobject.h:1346,
                 from test.c:3:
lib/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:
In function `import_array':
lib/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:765=
:
parse error before ')' token
lib/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:765=
:
parse error before ')' token
lib/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:
At top level:
lib/python2.4/site-packages/numpy/core/include/numpy/__multiarray_api.h:771=
:
parse error before "return"


If I remove #define PY_ARRAY_TYPES_PREFIX or define it as nothing,
compilation works.

The RPy.h header I was trying to compile in the first plase includes
numpy/arrayobject.h after
Python.h .

Re: Fwd: [Numpy-discussion] Numpy does not compile with PY_ARRAY_TYPES_PREFIX

[<co...@ph...>]

Sasha <nd...@ma...> writes:

> On 1/27/06, Travis Oliphant <oli...@ee...> wrote:
>
>> Show an example of using it in a file before you include the numpy
>> header.  Because that *should* work.  I know, I just tested it a few
>> days ago...
>
> I've tried to put just two lines in "test.c":
>
> #define PY_ARRAY_TYPES_PREFIX XYZ_
> #include <numpy/arrayobject.h>
>
> and compile it with
>
> $ gcc -I$NUMPYINCLUDE -c test.c
>
> Where NUMPYINCLUDE points to the location of numpy/arrayobject.h

You need to add #include "Python.h" as the first include (and add a
-I<python include directory> to your gcc line, of course).

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...