On Feb 4, 2008 4:39 PM, Robert Cimrman
Robert Cimrman wrote:
Ondrej Certik wrote:
(the exact location of this file may vary on your system), search for the declaration of "npy_int32" and you will see how it depends on the "SIZEOF_LONG".
Well, we can well uses this, but printf( "______%d\n", sizeof( npy_int32 ) ); prints ______4
so I still do not know why swig complains.
Now I am on some track:
out of 'int32 nRow, int32 nCol, int32 nGr', nRow, nCol are of type numpy.int32 (which causes problems), nGr is a regular python long (no problem, automatically converted to my C int32 (=int)). it seems that swig cannot convert numpy.int32 to the C int32 (which is the same), while it _can_ convert numpy.int64 to C int32...
It is easy to fix in my code, but I would like to understand this.
I don't. But I would like to understand this: When running the code I posted above from your compiled sizeof binary, I got the results above. However, I decided to better check it myself, so I tried to compile the sizeof.c (see the code above) and it failed... I had to apply the following patch: $ diff -Naur /home/robert/software/sizeof.c sizeof.c --- /home/robert/software/sizeof.c 2008-02-04 16:04:42.143594058 +0100 +++ sizeof.c 2008-02-04 16:50:28.177622129 +0100 @@ -2,6 +2,7 @@ * 11.09.2000, c */ #include "stdio.h" +#include "Python.h" #include "numpy/arrayobject.h" typedef int int32; Now I can compile it with: $ cat Makefile all: gcc -I/usr/include/python2.4/ -I/usr/include/numpy -c -o sizeof.o sizeof.c gcc sizeof.o -o sizeof -lpython2.4 $ make And now I got a different result (!): $ ./sizeof 2 4 8 4 8 4 4 8 4 8 Maybe you could explain it? :) And here is the result on 32 bits: $ ./sizeof 2 4 4 4 8 4 4 4 4 8 Ondrej