[Numpy-discussion] Proposal: Deprecate np.int, np.float, etc.?

[Chris Barker - NOAA Federal]

So one more bit of anecdotal evidence:

I just today revived some Cython code I wrote a couple years ago and
haven't tested since.

It wraps a C library that uses a lot of "int" typed values.

Turns out I was passing in numpy arrays that I had typed as "np.int".
It worked OK two years ago when I was testing only on 32 bit pythons,
but today I got a bunch of failed tests on 64 bit OS-X -- a np.int is
now a C long!

I really thought I knew better, even a couple years ago, but I guess
it's just too easy to slip up there.

Yeah to Cython for keeping types straight (I got a run-time error).
And Yeah to me for having at least some basic tests.

But Boo to numpy for a very easy to confuse type API.

-Chris


Sent from my iPhone

> On Jul 31, 2015, at 10:45 AM, Sturla Molden <sturla.molden at gmail.com> wrote:
>
> Chris Barker <chris.barker at noaa.gov> wrote:
>
>> What about Fortan -- I've been out of that loop for ages -- does
>> semi-modern Fortran use well defined integer types?
>
> Modern Fortran is completely sane.
>
> INTEGER without kind number (Fortran 77) is the fastest integer on the CPU.
> On AMD64 that is 32 bit, because it is designed to use a 64 bit pointer
> with a 32 bit offset. (That is also why Microsoft decided to use a 32 bit
> long, because it by definition is the fastest integer of at least 32 bits.
> One can actually claim that the C standard is violated with a 64 bit long
> on AMD64.) Because of this we use a 32 bit interger in BLAS and LAPACK
> linked to NumPy and SciPy.
>
> The function KIND (Fortran 90) allows us to query the kind number of a
> given variable, e.g. to find out the size of INTEGER and REAL.
>
> The function SELECTED_INT_KIND (Fortran 90) returns the kind number of
> smallest integer with a specified range.
>
> The function SELECTED_REAL_KIND (Fortran 90) returns the kind number of
> smallest float with a given range and precision. THe returned kind number
> can be used for REAL and COMPLEX.
>
> KIND, SELECTED_INT_KIND and SELECTED_REAL_KIND will all return compile-time
> constants, and can be used to declare other variables if the return value
> is stored in a variable with the attribute PARAMETER. This allows te
> programmer to get the REAL, COMPLEX or INTEGER the algorithm needs
> numerically, without thinking about how big they need to be in bits.
>
> ISO_C_BINDING is a Fortran 2003 module which contains kind numbers
> corresponding to all C types, including size_t and void*, C structs, an
> attribute for using pass-by-value semantics, controlling the C name to
> avoid name mangling, as well as functions for converting between C and
> Fortran pointers. It allows portable interop between C and Fortran (either
> calling C from Fortran or calling Fortran from C).
>
> ISO_FORTRAN_ENV is a Fortran 2003 and 2008 module. In F2003 it contain kind
> numbers for integers with specified size: INT8, INT16, INT32, and INT64. In
> F2008 it also contains kind numbers for IEEE floating point types: REAL32,
> REAL64, and REAL128. The kind numbers for floating point types can also be
> used to declare complex numbers.
>
> So with modern Fortran we have a completely portable and unambiguous type
> system.
>
> C11/C++11 is sane as well, but not quite as sane as that of modern Fortran.
>
>
> Sturla
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion