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 http://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
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 http://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
On Tue, Aug 4, 2015 at 4:39 AM, Sebastian Berg sebast...@sipsolutions.net
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 http://np.int is the python integer type, which
is
a C long in all the implemtations of
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
sebast...@sipsolutions.net wrote:
On Mo, 2015-08-03 at 21:32 +0200, Sturla Molden wrote:
On 03/08/15 20:51, Chris Barker wrote:
well, IIUC,
On Sun, Aug 2, 2015 at 5:13 AM, Sturla Molden sturla.mol...@gmail.com
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
On Mon, Aug 3, 2015 at 11:05 AM, Sturla Molden sturla.mol...@gmail.com
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
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...
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,
On 03/08/15 20:51, Chris Barker wrote:
well, IIUC, np.int http://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
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
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 between
Chris Barker - NOAA Federal chris.bar...@noaa.gov 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
Chris Barker - NOAA Federal chris.bar...@noaa.gov 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
--
Kind regards Nick Papior
On 31 Jul 2015 17:53, Chris Barker chris.bar...@noaa.gov wrote:
On Thu, Jul 30, 2015 at 11:24 PM, Jason Newton nev...@gmail.com wrote:
This really needs changing though. scientific researchers don't catch
this subtlety and expect it to be just like the c and
On Fri, Jul 31, 2015 at 5:19 PM, Nick Papior nickpap...@gmail.com wrote:
--
Kind regards Nick Papior
On 31 Jul 2015 17:53, Chris Barker chris.bar...@noaa.gov wrote:
On Thu, Jul 30, 2015 at 11:24 PM, Jason Newton nev...@gmail.com wrote:
This really needs changing though. scientific
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
On Jul 24, 2015 08:55, Julian Taylor jtaylor.deb...@googlemail.com
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
On Thu, Jul 30, 2015 at 11:24 PM, Jason Newton nev...@gmail.com 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
Chris Barker chris.bar...@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
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 time,
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
Chris Barker chris.bar...@noaa.gov 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
On Sun, Jul 26, 2015 at 11:19 AM, Sturla Molden sturla.mol...@gmail.com
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*,
Chris Barker chris.bar...@noaa.gov 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
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 request
Julian Taylor jtaylor.deb...@googlemail.com 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.
On Fri, Jul 24, 2015 at 10:03 AM, Sturla Molden sturla.mol...@gmail.com
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,
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
28 matches
Mail list logo
