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

On Di, 2015-08-04 at 05:57 -0400, josef.p...@gmail.com wrote: > > > On Tue, Aug 4, 2015 at 4:39 AM, Sebastian Berg > wrote: > On Mo, 2015-08-03 at 21:32 +0200, Sturla Molden wrote: > > On 03/08/15 20:51, Chris Barker wrote: > > > > > well, IIUC, np.int

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

On Tue, Aug 4, 2015 at 4:39 AM, Sebastian Berg wrote: > On Mo, 2015-08-03 at 21:32 +0200, Sturla Molden wrote: > > On 03/08/15 20:51, Chris Barker wrote: > > > > > well, IIUC, np.int is the python integer type, which > is > > > a C long in all the implemtations of cPython that I k

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

On Mo, 2015-08-03 at 21:32 +0200, Sturla Molden wrote: > On 03/08/15 20:51, Chris Barker wrote: > > > well, IIUC, np.int is the python integer type, which is > > a C long in all the implemtations of cPython that I know about -- but is > > that a guarantee?in the future as well? >

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

On Mo, 2015-08-03 at 21:32 +0200, Sturla Molden wrote: > On 03/08/15 20:51, Chris Barker wrote: > > > well, IIUC, np.int is the python integer type, which is > > a C long in all the implemtations of cPython that I know about -- but is > > that a guarantee?in the future as well? >

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

On 03/08/15 20:51, Chris Barker wrote: > well, IIUC, np.int is the python integer type, which is > a C long in all the implemtations of cPython that I know about -- but is > that a guarantee?in the future as well? It is a Python int on Python 2. On Python 3 dtype=np.int means the

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

On Mon, Aug 3, 2015 at 11:05 AM, Sturla Molden wrote: > On 03/08/15 18:25, Chris Barker wrote: > > > [NOTE: is there a C long dtype? I can't find it at the moment...] > > There is, it is called np.int. well, IIUC, np.int is the python integer type, which is a C long in all the implemtat

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

On 03/08/15 18:25, Chris Barker wrote: > 2) The vagaries of the standard C types: int, long, etc (spelled > np.intc, which is a int32 on my machine, anyway) > [NOTE: is there a C long dtype? I can't find it at the moment...] There is, it is called np.int. This just illustrates the problem..

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

On 08/03/2015 12:25 PM, Chris Barker wrote: > 2) The vagaries of the standard C types: int, long, etc (spelled > np.intc, which is a int32 on my machine, anyway) > [NOTE: is there a C long dtype? I can't find it at the moment...] Numpy does define "the platform dependent C integer types short

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

On Sun, Aug 2, 2015 at 5:13 AM, Sturla Molden wrote: > > A long is only machine word wide on posix, in windows its not. > > Actually it is the opposite. A pointer is 64 bit on AMD64, but the > native integer and pointer offset is only 32 bit. But it does not matter > because it is int that should

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

On 31/07/15 09:38, Julian Taylor wrote: > A long is only machine word wide on posix, in windows its not. Actually it is the opposite. A pointer is 64 bit on AMD64, but the native integer and pointer offset is only 32 bit. But it does not matter because it is int that should be machine word size

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

Chris Barker - NOAA Federal wrote: > Which is part of the problem with C -- if two types happen to be the > same, the compiler is perfectly happy. That int and long int be the same is not more problematic than int and signed int be the same. Sturla _

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

>> 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! > > It has always been C long. It is the C long that varies bet

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

Chris Barker - NOAA Federal wrote: > 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! It has always been C long. It

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

On Jul 24, 2015 08:55, "Julian Taylor" wrote: > > On 07/23/2015 04:29 AM, Nathaniel Smith wrote: > > Hi all, > > > > So one of the things exposed in the numpy namespace are objects called > >np.int > >np.float > >np.bool > > etc. > > > > These are commonly used -- in fact, just yesterd

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

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 wa

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

On Fri, Jul 31, 2015 at 5:19 PM, Nick Papior wrote: > -- > > Kind regards Nick Papior > On 31 Jul 2015 17:53, "Chris Barker" wrote: > > > > On Thu, Jul 30, 2015 at 11:24 PM, Jason Newton wrote: > >> > >> This really needs changing though. scientific researchers don't catch > this subtlety and

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

-- Kind regards Nick Papior On 31 Jul 2015 17:53, "Chris Barker" wrote: > > On Thu, Jul 30, 2015 at 11:24 PM, Jason Newton wrote: >> >> This really needs changing though. scientific researchers don't catch this subtlety and expect it to be just like the c and matlab types they know a little abo

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

Chris Barker 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 desi

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

On Thu, Jul 30, 2015 at 11:24 PM, Jason Newton wrote: > This really needs changing though. scientific researchers don't catch > this subtlety and expect it to be just like the c and matlab types they > know a little about. > well, C types are a %&$ nightmare as well! In fact, one of the biggest

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

On 31.07.2015 08:24, Jason Newton wrote: > Been using numpy in it's various forms since like 2005. burned on int, > int_ just today with boost.python / ndarray conversions and a number of > times before that. intc being C's int!? Didn't even know it existed > till today. This isn't the first tim

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

Been using numpy in it's various forms since like 2005. burned on int, int_ just today with boost.python / ndarray conversions and a number of times before that. intc being C's int!? Didn't even know it existed till today. This isn't the first time, esp with float. Bool is actually expected for

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

Chris Barker wrote: > 32 bits on all (most) 32 bit platforms > 64 bits on 64 bit Linux and OS-X > 32 bits on 64 bit Windows (also if compiled by cygwin??) sizeof(long) is 8 on 64-bit Cygwin. This is to make sure it is inconsistent with MSVC and MinGW-w64, and make sure there will always be ABI m

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

On Sun, Jul 26, 2015 at 11:19 AM, Sturla Molden wrote: > > we get away with np.float, because every OS/compiler that gets any > regular > > use has np.float == a c double, which is always 64 bit. > > Not if we are passing an array of np.float to a ac routine that expects > float*, e.g. in OpenGL,

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

Chris Barker wrote: > we get away with np.float, because every OS/compiler that gets any regular > use has np.float == a c double, which is always 64 bit. Not if we are passing an array of np.float to a ac routine that expects float*, e.g. in OpenGL, BLAS or LAPACK. That will for sure give crazy

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

On Fri, Jul 24, 2015 at 10:03 AM, Sturla Molden wrote: > > I don't see the issue. They are just aliases so how is np.float worse > > than just float? > > I have burned my fingers on it. > I must have too -- but I don't recall, because I am VERY careful about not using np.float, no.int, etc... bu

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

Julian Taylor wrote: > I don't see the issue. They are just aliases so how is np.float worse > than just float? I have burned my fingers on it. Since np.double is a C double I assumed np.float is a C float. It is not. np.int has the same problem by being a C long. Pure evil. Most users of Num

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

On 07/23/2015 04:29 AM, Nathaniel Smith wrote: > Hi all, > > So one of the things exposed in the numpy namespace are objects called >np.int >np.float >np.bool > etc. > > These are commonly used -- in fact, just yesterday on another project > I saw a senior person reviewing a pull reques

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

Hi all, So one of the things exposed in the numpy namespace are objects called np.int np.float np.bool etc. These are commonly used -- in fact, just yesterday on another project I saw a senior person reviewing a pull request instruct a more junior person that they should use np.float instea