What is a numpy.long type?
Hi folks, I had thought that maybe a numpy.long dtype was a system (compiler)-native C long. But on both 32 and 64 bit python on OS-X, it seems to be 64 bit. I'm pretty sure that on OS-X 32 bit, a C long is 32 bits. (gdd, of course) I don't have other machines to test on , but as the MS compilers and gcc do different things with a C long on 64 bit platforms, I"m curious how numpy defines it. In general, I prefer the "explicit is better than implicit" approach and use, e.g. int32 and int64. However, in this case, we are using Cython, and calling C code that used "long" -- so what I want is "whatever the compiler thinks is a long" -- is there a way to do that without my own kludgy platform-dependent code? I note that the Cython numpy.pxd assigns: ctypedef signed long npy_long Is that a bug? (or maybe npy_long is not supposed to match np.long.... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Fri, Aug 23, 2013 at 6:02 AM, Chris Barker - NOAA Federal < chris.barker@noaa.gov> wrote:
Hi folks,
I had thought that maybe a numpy.long dtype was a system (compiler)-native C long.
But on both 32 and 64 bit python on OS-X, it seems to be 64 bit. I'm pretty sure that on OS-X 32 bit, a C long is 32 bits. (gdd, of course)
I don't have other machines to test on , but as the MS compilers and gcc do different things with a C long on 64 bit platforms, I"m curious how numpy defines it.
In general, I prefer the "explicit is better than implicit" approach and use, e.g. int32 and int64. However, in this case, we are using Cython, and calling C code that used "long" -- so what I want is "whatever the compiler thinks is a long" -- is there a way to do that without my own kludgy platform-dependent code?
I note that the Cython numpy.pxd assigns:
ctypedef signed long npy_long
Is that a bug? (or maybe npy_long is not supposed to match np.long....
npy_long is indeed just an alias to C long, np.long is an alias to python's long: arch -32 python -c "import numpy as np; print np.dtype(np.int); print np.dtype(np.long)" int32 int64 arch -64 python -c "import numpy as np; print np.dtype(np.int); print np.dtype(np.long)" int64 int64 and python -c "import numpy as np; print np.long is long" will print True All this is on python 2.7, I am not sure how/if that changes on python 3 (that consolidated python int/long). David
-Chris
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Aug 22, 2013, at 11:57 PM, David Cournapeau <cournape@gmail.com> wrote: npy_long is indeed just an alias to C long, Which means it's likely broken on 32 bit platforms and 64 bit MSVC. np.long is an alias to python's long: But python's long is an unlimited type--it can't be mapped to a c type at all. arch -32 python -c "import numpy as np; print np.dtype(np.int); print np.dtype(np.long)" int32 int64 So this is giving us a 64 bit int--not a bad compromise, but not a python long--I've got to wonder why the alias is there at all. arch -64 python -c "import numpy as np; print np.dtype(np.int); print np.dtype(np.long)" int64 int64 Same thing on 64 bit. So while np.long is an alias to python long--it apparently is translated internally as 64 bit -- everywhere? So apparently there is no way to get a "platform long". ( or, for that matter, a platform anything else, it's just that there is more consistancy among common platforms for the others) -Chris All this is on python 2.7, I am not sure how/if that changes on python 3 (that consolidated python int/long). David
-Chris
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, 2013-08-23 at 07:59 -0700, Chris Barker - NOAA Federal wrote:
On Aug 22, 2013, at 11:57 PM, David Cournapeau <cournape@gmail.com> wrote:
<snip>
arch -32 python -c "import numpy as np; print np.dtype(np.int); print np.dtype(np.long)" int32 int64
So this is giving us a 64 bit int--not a bad compromise, but not a python long--I've got to wonder why the alias is there at all.
It is there because you can't remove it :).
arch -64 python -c "import numpy as np; print np.dtype(np.int); print np.dtype(np.long)" int64 int64
Same thing on 64 bit.
So while np.long is an alias to python long--it apparently is translated internally as 64 bit -- everywhere?
Not sure how a python long is translated...
So apparently there is no way to get a "platform long". ( or, for that matter, a platform anything else, it's just that there is more consistancy among common platforms for the others)
An np.int_ is a platform long, since the python ints are C longs. It is a bit weird naming, but it is transparent. Check http://docs.scipy.org/doc/numpy-dev/reference/arrays.scalars.html#built-in-s... you got everything platform dependend there really. `intc` is an int, `int_` is a long, and you got `longlong`, as well as `intp` which is an ssize_t, etc. - Sebastian
-Chris
All this is on python 2.7, I am not sure how/if that changes on python 3 (that consolidated python int/long).
David
-Chris
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Aug 23, 2013 at 8:11 AM, Sebastian Berg <sebastian@sipsolutions.net> wrote:
So this is giving us a 64 bit int--not a bad compromise, but not a python long--I've got to wonder why the alias is there at all.
It is there because you can't remove it :).
sure we could -- not that we'd want to....
So while np.long is an alias to python long--it apparently is translated internally as 64 bit -- everywhere?
Not sure how a python long is translated...
The big mystery!
An np.int_ is a platform long, since the python ints are C longs. It is a bit weird naming, but it is transparent. Check http://docs.scipy.org/doc/numpy-dev/reference/arrays.scalars.html#built-in-s...
cool, thanks.
you got everything platform dependend there really. `intc` is an int, `int_` is a long, and you got `longlong`, as well as `intp` which is an ssize_t, etc.
great, thanks. That's helpful. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Fri, Aug 23, 2013 at 8:59 AM, Chris Barker - NOAA Federal < chris.barker@noaa.gov> wrote:
On Aug 22, 2013, at 11:57 PM, David Cournapeau <cournape@gmail.com> wrote:
npy_long is indeed just an alias to C long,
Which means it's likely broken on 32 bit platforms and 64 bit MSVC.
np.long is an alias to python's long:
But python's long is an unlimited type--it can't be mapped to a c type at all.
arch -32 python -c "import numpy as np; print np.dtype(np.int); print np.dtype(np.long)" int32 int64
So this is giving us a 64 bit int--not a bad compromise, but not a python long--I've got to wonder why the alias is there at all.
arch -64 python -c "import numpy as np; print np.dtype(np.int); print np.dtype(np.long)" int64 int64
Same thing on 64 bit.
So while np.long is an alias to python long--it apparently is translated internally as 64 bit -- everywhere?
So apparently there is no way to get a "platform long". ( or, for that matter, a platform anything else, it's just that there is more consistancy among common platforms for the others)
I use 'bBhHiIlLqQ' for the C types. Long varies between 32 & 64 bit, depending on the platform and 64 bit convention chosen. The C int is always 32 bits as far as I know. Chuck
On Fri, Aug 23, 2013 at 8:15 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
I use 'bBhHiIlLqQ' for the C types. Long varies between 32 & 64 bit, depending on the platform and 64 bit convention chosen. The C int is always 32 bits as far as I know.
Well, not in the spec, but in practice, probably. Maybe not on some embedded platfroms? not my issue... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
participants (4)
-
Charles R Harris -
Chris Barker - NOAA Federal -
David Cournapeau -
Sebastian Berg