A colleague has run into this weird behaviour with NumPy 1.6.1, EPD 7.1-2, on
Linux (Fedora Core 14) 64-bit:
a = numpy.array(numpy.random.randint(256,size=(500,972)),dtype='uint8')
b = numpy.random.randint(500,size=(4993210,))
c = a[b]
It seems c is not getting filled in full,
Den 23.01.2012 10:04, skrev Dag Sverre Seljebotn:
On 01/23/2012 05:35 AM, Jonathan Rocher wrote:
Hi all,
I was reading this while learning about Pytables in more details and the
origin of its efficiency. This sounds like a problem where out of core
computation using pytables would shine
On Mon, Jan 23, 2012 at 12:23 PM, Sturla Molden stu...@molden.no wrote:
Den 23.01.2012 10:04, skrev Dag Sverre Seljebotn:
On 01/23/2012 05:35 AM, Jonathan Rocher wrote:
Hi all,
I was reading this while learning about Pytables in more details and the
origin of its efficiency. This sounds like
On 01/23/2012 12:23 PM, Sturla Molden wrote:
Den 23.01.2012 10:04, skrev Dag Sverre Seljebotn:
On 01/23/2012 05:35 AM, Jonathan Rocher wrote:
Hi all,
I was reading this while learning about Pytables in more details and the
origin of its efficiency. This sounds like a problem where out of
Den 23.01.2012 13:09, skrev Sebastian Haase:
I would think that interactive zooming would be quite nice
(illuminating) and for that 13 secs would not be tolerable
Well... it's not at the top of my priority list ... ;-)
Sure, that comes under the 'fast enough' issue. But even
On 01/23/12 13:51, Sturla Molden wrote:
Den 23.01.2012 13:09, skrev Sebastian Haase:
I would think that interactive zooming would be quite nice
(illuminating) and for that 13 secs would not be tolerable
Well... it's not at the top of my priority list ... ;-)
Sure, that comes
I'd like to add
http://git.tiker.net/pyopencl.git/blob/HEAD:/examples/demo_mandelbrot.py to the
discussion, since I use pyopencl (http://mathema.tician.de/software/pyopencl)
with great success in my daily scientific computing. Install with pip.
PyOpenCL does understand numpy arrays. You write
On Wed, Jan 18, 2012 at 1:26 AM, a...@pdauf.de wrote:
Your ideas are very helpfull and the code is very fast.
I'm curios -- a number of ideas were floated here -- what did you end up using?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR
I've reproduced this (rather serious) bug myself and confirmed that it exists
in master, and as far back as 1.4.1.
I'd really appreciate if someone could reproduce and confirm on another
machine, as so far all my testing has been on our single high-memory machine.
Thanks,
David
On Mon, Jan 23,
Can you determine where the problem is, precisely.In other words, can you
verify that c is not getting filled in correctly?
You are no doubt going to get overflow in the summation as you have a uint8
parameter. But, having that overflow be exactly '0' would be surprising.
Can you
On Mon, Jan 23, 2012 at 7:55 PM, David Warde-Farley
warde...@iro.umontreal.ca wrote:
I've reproduced this (rather serious) bug myself and confirmed that it exists
in master, and as far back as 1.4.1.
I'd really appreciate if someone could reproduce and confirm on another
machine, as so far
Am 23.01.2012 18:17, schrieb Chris Barker:
On Wed, Jan 18, 2012 at 1:26 AM,a...@pdauf.de wrote:
Your ideas are very helpfull and the code is very fast.
I'm curios -- a number of ideas were floated here -- what did you end up
using?
-Chris
I'am sorry but when i see the code of Torgil
On Mon, Jan 23, 2012 at 1:33 PM, Travis Oliphant teoliph...@gmail.comwrote:
Can you determine where the problem is, precisely.In other words, can
you verify that c is not getting filled in correctly?
You are no doubt going to get overflow in the summation as you have a
uint8 parameter.
Is there a way to save a structured array in a text file?
My problem is not so much in the saving procedure, but rather in the
'reloading' procedure.
See below
In [3]: import numpy as np
In [4]: r = np.ones(3,dtype=[('name', '|S5'), ('foo', 'i8'), ('bar', 'f8')])
In [5]:
Hi Travis,
Thanks for your reply.
On Mon, Jan 23, 2012 at 01:33:42PM -0600, Travis Oliphant wrote:
Can you determine where the problem is, precisely.In other words, can you
verify that c is not getting filled in correctly?
You are no doubt going to get overflow in the summation as you
On Mon, Jan 23, 2012 at 08:38:44PM +0100, Robin wrote:
On Mon, Jan 23, 2012 at 7:55 PM, David Warde-Farley
warde...@iro.umontreal.ca wrote:
I've reproduced this (rather serious) bug myself and confirmed that it
exists
in master, and as far back as 1.4.1.
I'd really appreciate if
On 23 Jan 2012, at 21:15, Emmanuel Mayssat wrote:
Is there a way to save a structured array in a text file?
My problem is not so much in the saving procedure, but rather in the
'reloading' procedure.
See below
In [3]: import numpy as np
In [4]: r = np.ones(3,dtype=[('name', '|S5'),
On 1/23/2012 12:33 PM, David Warde-Farley wrote:
On Mon, Jan 23, 2012 at 08:38:44PM +0100, Robin wrote:
On Mon, Jan 23, 2012 at 7:55 PM, David Warde-Farley
warde...@iro.umontreal.ca wrote:
I've reproduced this (rather serious) bug myself and confirmed that it
exists
in master, and as far
On 23 Jan 2012, at 22:07, Derek Homeier wrote:
In [4]: r = np.ones(3,dtype=[('name', '|S5'), ('foo', 'i8'), ('bar',
'f8')])
In [5]: r.tofile('toto.txt',sep='\n')
bash-4.2$ cat toto.txt
('1', 1, 1.0)
('1', 1, 1.0)
('1', 1, 1.0)
cnv = {0: lambda s: s.lstrip('('), -1: lambda s:
After having saved data, I need to know/remember the data dtype to
restore it correctly.
Is there a way to save the dtype with the data?
(I guess the header parameter of savedata could help, but they are
only available in v2.0+ )
I would like to save several related structured array and a
Dear List,
I frequently work with MATLAB and it is necessary for me many a times
to adapt MATLAB codes for NumPy arrays.
While for most practical purposes it works fine, I think there might
be a lot of 'under the hood' things that I might be missing when I
make the translations from MATLAB to
Please ignore my question. I found what I needed on the scipy website.
I asked the question in haste.
I'm sorry.
Thanks
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Note sure if there's a better way, but you can do it with some custom load
and save functions:
with open('f.txt', 'w') as f:
... f.write(str(x.dtype) + '\n')
... numpy.savetxt(f, x)
with open('f.txt') as f:
... dtype = f.readline().strip()
... y = numpy.loadtxt(f).astype(dtype)
On 24 Jan 2012, at 01:45, Olivier Delalleau wrote:
Note sure if there's a better way, but you can do it with some custom load
and save functions:
with open('f.txt', 'w') as f:
... f.write(str(x.dtype) + '\n')
... numpy.savetxt(f, x)
with open('f.txt') as f:
... dtype =
Den 23.01.2012 22:08, skrev Christoph Gohlke:
Maybe this explains the win-amd64 behavior: There are a couple of places
in mtrand where array indices and sizes are C long instead of npy_intp,
for example in the randint function:
Den 23.01.2012 22:08, skrev Christoph Gohlke:
Maybe this explains the win-amd64 behavior: There are a couple of places
in mtrand where array indices and sizes are C long instead of npy_intp,
for example in the randint function:
Den 24.01.2012 06:00, skrev Sturla Molden:
Both i and length could overflow here. It should overflow on
allocation of more than 2 GB. There is also a lot of C longs in the
internal state (line 55-105), as well as the other functions.
The use of C long affects all the C and Pyrex source code
27 matches
Mail list logo
