On Mon, Oct 29, 2012 at 6:29 AM, Radek Machulka
wrote:
> Hi,
>
> is there a way how to save more arrays into single npy (npz if possible) file
> in loop? Something like:
>
> fw = open('foo.bar', 'wb')
> while foo:
> arr = np.array(bar)
> np.savez_compressed(fw, arr)
> fw.close()
>
doh! thanks
On Mon, Oct 29, 2012 at 2:36 AM, Pauli Virtanen wrote:
> Larry Paltrow gmail.com> writes:
> [clip]
> > np.all(~np.isnan(data))
> > >>> False
> >
> > Seems to be all non-nan
>
> No, it means you have NaNs in your data.
>
> --
> Pauli Virtanen
>
> _
On Mon, Oct 29, 2012 at 11:53 AM, Henry Gomersall wrote:
> On Mon, 2012-10-29 at 11:49 -0400, Frédéric Bastien wrote:
>> That is possible.
>>
> Great!
Just to be clear, I mean this is possible to make it work. We do not
do that for now. Also, sharing the memory on the CPU and GPU is not
trivial i
On Mon, 2012-10-29 at 11:49 -0400, Frédéric Bastien wrote:
> That is possible.
>
Great!
> The gpu nd array project I talked above work on the CPU and the GPU in
> OpenCL and with CUDA. But there is much stuff that is in numpy that we
> didn't ported.
This is: https://github.com/inducer/compyte/w
That is possible.
The gpu nd array project I talked above work on the CPU and the GPU in
OpenCL and with CUDA. But there is much stuff that is in numpy that we
didn't ported.
We started integrating it into Theano. So this mean the GPU code from
Theano will be ported to this project, so there will
On Mon, 2012-10-29 at 11:11 -0400, Frédéric Bastien wrote:
> > Assuming of course all the relevant backends are up to scratch.
> >
> > Is there a fundamental reason why targetting a CPU through OpenCL is
> > worse than doing it exclusively through C or C++?
>
> First, opencl do not allow us to do
Thanks a lot! I feared it would have something to do with those changes,
turns out I tried with the wrong numpy version. But at least its not in
1.7. for sure so nothing to worry about :).
I will have a look at it.
On Mon, 2012-10-29 at 10:15 -0500, Patrick Marsh wrote:
> I've tracked down the pr
I went ahead and filed a ticket (https://github.com/numpy/numpy/issues/2700)
for historical purposes…and so those on the MPL list can follow up.
PTM
---
Patrick Marsh
Ph.D. Candidate / Liaison to the HWT
School of Meteorology / University of Oklahoma
Cooperative Institute for Mesoscale Meteoro
On Mon, Oct 29, 2012 at 11:04 AM, Patrick Marsh wrote:
> Turns out it isn't the commit I thought it was. I'm currently going
> through a git bisect to track down the actual commit that introduced this
> bug. I'll post back when I've found it.
>
>
> PTM
> ---
> Patrick Marsh
> Ph.D. Candidate / Li
I've tracked down the problem to this commit:
https://github.com/numpy/numpy/commit/c48156dfdc408f0a1e59ef54ac490cccbd6b8d73
Patrick.Marsh@buxton numpy> git bisect good
c48156dfdc408f0a1e59ef54ac490cccbd6b8d73 is the first bad commit
commit c48156dfdc408f0a1e59ef54ac490cccbd6b8d73
Author: Sebast
On Tue, Oct 23, 2012 at 11:48 AM, Henry Gomersall wrote:
> On Tue, 2012-10-23 at 11:41 -0400, Frédéric Bastien wrote:
>> Did you saw the gpu nd array project? We try to do something similar
>> but only for the GPU.
>>
> Out of interest, is there a reason why the backend for Numpy could not
> be wr
Turns out it isn't the commit I thought it was. I'm currently going through
a git bisect to track down the actual commit that introduced this bug. I'll
post back when I've found it.
PTM
---
Patrick Marsh
Ph.D. Candidate / Liaison to the HWT
School of Meteorology / University of Oklahoma
Cooperati
On Mon, Oct 29, 2012 at 10:33 AM, Sebastian Berg wrote:
> Hey,
>
> On Mon, 2012-10-29 at 09:54 -0400, Benjamin Root wrote:
> > This error started showing up in the test suite for mpl when using
> > numpy master.
> >
> > AttributeError: incompatible shape for a non-contiguous array
> >
> > The tra
Hey,
On Mon, 2012-10-29 at 09:54 -0400, Benjamin Root wrote:
> This error started showing up in the test suite for mpl when using
> numpy master.
>
> AttributeError: incompatible shape for a non-contiguous array
>
> The tracebacks all point back to various code points where we are
> trying to se
This error started showing up in the test suite for mpl when using numpy
master.
AttributeError: incompatible shape for a non-contiguous array
The tracebacks all point back to various code points where we are trying to
set the shape of an array, e.g.,
offsets.shape = (-1, 2)
Those lines haven't
Larry Paltrow gmail.com> writes:
[clip]
> np.all(~np.isnan(data))
> >>> False
>
> Seems to be all non-nan
No, it means you have NaNs in your data.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/m
Ok thanks, I figured np.isnan(data) is True is what we want but wasn't
certain. I think it should describe the same thing.
np.all(~np.isnan(data))
>>> False
Seems to be all non-nan
On Mon, Oct 29, 2012 at 2:12 AM, eat wrote:
> Hi,
>
> On Mon, Oct 29, 2012 at 11:01 AM, Larry Paltrow
> wrote:
>
Hi,
On Mon, Oct 29, 2012 at 11:01 AM, Larry Paltrow wrote:
> np.isnan(data) is True
> >>> False
>
Check with:
np.all(~np.isnan(x))
My 2 cents,
-eat
>
>
> On Mon, Oct 29, 2012 at 1:50 AM, Pauli Virtanen wrote:
>
>> Larry Paltrow gmail.com> writes:
>> > I'm having some trouble using the linalg.
np.isnan(data) is True
>>> False
On Mon, Oct 29, 2012 at 1:50 AM, Pauli Virtanen wrote:
> Larry Paltrow gmail.com> writes:
> > I'm having some trouble using the linalg.lstsq() function
> > with certain data and trying to understand why. It's
> > always returning nans when I feed it this numpy
Larry Paltrow gmail.com> writes:
> I'm having some trouble using the linalg.lstsq() function
> with certain data and trying to understand why. It's
> always returning nans when I feed it this numpy array of float64 data:
>
> data = df.close.values #coming from a pandas dataframe
>
> type(data)
>
Radek Machulka gmail.com> writes:
> is there a way how to save more arrays into single npy (npz if possible) file
> in loop? Something like:
>
> fw = open('foo.bar', 'wb')
> while foo:
> arr = np.array(bar)
> np.savez_compressed(fw, arr)
> fw.close()
>
> Or some workaround maybe? I
I'm having some trouble using the linalg.lstsq() function with certain data
and trying to understand why. It's always returning nans when I feed it
this numpy array of float64 data:
data = df.close.values #coming from a pandas dataframe
type(data)
>>> numpy.ndarray
data.dtype
>>> dtype('float64')
Hi,
is there a way how to save more arrays into single npy (npz if possible) file
in loop? Something like:
fw = open('foo.bar', 'wb')
while foo:
arr = np.array(bar)
np.savez_compressed(fw, arr)
fw.close()
Or some workaround maybe? I go through hundreds of thousands arrays and ca
23 matches
Mail list logo
