numpy-discussion

[Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux

[Sebastian H. <ha...@ms...>]

Hi,
I just ran into more problems with my SWIG
typemaps.
In the C api the current enum for 
NPY_INT is 5 
NPY_LONG is 7

to match overloaded function I need to check these type values.

On 64bit all works fine: 
my 32bit int  function matches NPY_INT  - which is "int" in C/C++
my 64bit int  function matches NPY_LONG  - which is "long" in C/C++

but on 32bit Linux
the 32bit int  function matches NPY_LONG 
there is no  NPY_INT  on 32bit

that is: if I have a non overloaded C/C++ function that expects a C "int"
 - i.e. a 32bit int - I have write different function matching rules  !!!

REQUEST:
Can a 32bit int array get the typenumber code NPY_INT
on 32bit Linux !?
Then it would work for both 32bit Linux and 64bit Linux the same !

(I don't know about 64bit windows - I have heard that both C int and C long 
are 64bit - so that is screwed in any case .... )

Thanks,
Sebastian Haase

 

Re: [Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux

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

Sebastian Haase wrote:
> Hi,
> I just ran into more problems with my SWIG
> typemaps.
> In the C api the current enum for 
> NPY_INT is 5 
> NPY_LONG is 7
>
> to match overloaded function I need to check these type values.
>
> On 64bit all works fine: 
> my 32bit int  function matches NPY_INT  - which is "int" in C/C++
> my 64bit int  function matches NPY_LONG  - which is "long" in C/C++
>
> but on 32bit Linux
> the 32bit int  function matches NPY_LONG 
> there is no  NPY_INT  on 32bit
>   
Yes there is.  Both NPY_INT and NPY_LONG are always there.  One matches 
the int and one matches the long. 

Perhaps you are confused about what the special defines NPY_INT32 match to?

The behavior is that the 'long' type gets "first-dibs" then the 
'longlong' type gets a crack.  Finally, the 'int' type is chosen.  The 
first one that matches the bit-type is used.
> that is: if I have a non overloaded C/C++ function that expects a C "int"
>  - i.e. a 32bit int - I have write different function matching rules  !!!
>   

What you need to do is stop trying to match bit-widths and instead match 
c-types.  That's why NPY_INT and NPY_LONG are both there.

Let me know if you have further questions.  I don't really understand 
what the issue is.

-Travis

Re: [Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux

[Sebastian H. <ha...@ms...>]

Thanks for the reply, see question below...
On Tuesday 22 August 2006 12:30, Travis Oliphant wrote:
> Sebastian Haase wrote:
> > Hi,
> > I just ran into more problems with my SWIG
> > typemaps.
> > In the C api the current enum for
> > NPY_INT is 5
> > NPY_LONG is 7
> >
> > to match overloaded function I need to check these type values.
> >
> > On 64bit all works fine:
> > my 32bit int  function matches NPY_INT  - which is "int" in C/C++
> > my 64bit int  function matches NPY_LONG  - which is "long" in C/C++
> >
> > but on 32bit Linux
> > the 32bit int  function matches NPY_LONG
> > there is no  NPY_INT  on 32bit
>
> Yes there is.  Both NPY_INT and NPY_LONG are always there.  One matches
> the int and one matches the long.
>
> Perhaps you are confused about what the special defines NPY_INT32 match to?
>
> The behavior is that the 'long' type gets "first-dibs" then the
> 'longlong' type gets a crack.  Finally, the 'int' type is chosen.  The
> first one that matches the bit-type is used.
>
This explains it - my specific function overloads only one of its two array 
arguments (i.e. allow many different types)  - the second one must be a 
C "int".    [(a 32bit int) - but SWIG  matches the "C signature" ] 
But what is the type number of "<i4" ? It is: on 64bit I get NPY_INT.
But on 32bitLinux I get NPY_LONG because of that rule.

My SWIG typemaps want to "double check" that a C function expecting c-type 
"int" gets a NPY_INT  - (a "long" needs a "NPY_LONG") 

I don't know what the solution should be  - but maybe the rule should be 
changed based on the assumption that "int" in more common !?


> > that is: if I have a non overloaded C/C++ function that expects a C "int"
> >  - i.e. a 32bit int - I have write different function matching rules  !!!
>
> What you need to do is stop trying to match bit-widths and instead match
> c-types.  That's why NPY_INT and NPY_LONG are both there.
If you are referring to use of the sizeof() operator - I'm not doing that.

Thanks as always for your quick and careful replies.
- Sebastian

Re: [Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux

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

Sebastian Haase wrote:
> This explains it - my specific function overloads only one of its two array 
> arguments (i.e. allow many different types)  - the second one must be a 
> C "int".    
> [(a 32bit int) - but SWIG  matches the "C signature" ] 
> But what is the type number of "<i4" ? It is: on 64bit I get NPY_INT.
> But on 32bitLinux I get NPY_LONG because of that rule.
>
> My SWIG typemaps want to "double check" that a C function expecting c-type 
> "int" gets a NPY_INT  - (a "long" needs a "NPY_LONG") 
>   
Perhaps I can help you do what you want without making assumptions about 
the platform.   I'll assume you are matching on an int* signature and 
want to "translate" that to an integer array of the correct bit-width.  
So, you have a PyArrayObject as input I'll call self

Just check:

(PyArray_ISSIGNED(self) && PyArray_ITEMSIZE(self)==SIZEOF_INT)

For your type-map check.  This will work on all platforms and allow 
signed integers of the right type.

> I don't know what the solution should be  - but maybe the rule should be 
> changed based on the assumption that "int" in more common !?
>   
That's not going to happen at this point.  Besides in the Python world, 
the fact that Python integers are "long" means that the "long" is the 
more common 32-bit integer on 32-bit machines.

-Travis

Re: [Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux

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

Sebastian Haase wrote:
> Hi,
> I just ran into more problems with my SWIG
> typemaps.
> In the C api the current enum for 
> NPY_INT is 5 
> NPY_LONG is 7
>
> to match overloaded function I need to check these type values.
>
> On 64bit all works fine: 
> my 32bit int  function matches NPY_INT  - which is "int" in C/C++
> my 64bit int  function matches NPY_LONG  - which is "long" in C/C++
>   
As you noted below, this is not always the case.  You can't assume that 
64-bit means "long"

Let me assume that you are trying to write functions for each of the 
"data-types".  You can proceed in a couple of ways:

1) Use the basic c-types
2) Use "bit-width" types (npy_int32, npy_int64, etc...)

The advantage of the former is that it avoids any confusion in terms of 
what kind of c-type it matches.  This is really only important if you 
are trying to interface with external code that uses basic c-types.

The advantage of the latter is that you don't have to write a redundant 
routine (i.e. on 32-bit linux the int and long routines should be 
identical machine code), but you will have to be careful in matching to 
a c-type should you need to call some external routine.

The current system gives you as many choices as possible (you can either 
match external code using the c-types) or you can write to a particular 
bit-width.  This is accomplished through comprehensive checks defined in 
the arrayobject.h file.

-Travis