On Tue, Jun 15, 2010 at 01:56, Vishal Rana wrote:
> Robert,
> As you said, I was able to get the results, but I now got a question as
> np.load('np.npz') returns me a object so does
> that mean the data is read directly from the from the npz file and not all
> the data is loaded to the memory?
C
On Jun 10, 2010, at 7:16 PM, Bevan Jenkins wrote:
> Hello,
>
> I have posted previously about dates prior to 1900 but this seems to be a
> seperate issue. The error message is definitley different.
> I can not seem to convert a timseseries from one frequency ('D') to another
> ('H') when i use
Hi,
Sorry if y'all had already seen this, but a friend just picked up the
latest sphinx with
easy_install -U sphinx
- got version 1.0b2 - and then hit this problem with numpydoc:
http://projects.scipy.org/numpy/ticket/1489
I just point it out in the hope that someone with more sphinx
knowledge
Paul Northug wrote:
> I have a computation bounded by one step and I have always wondered
> how to make it fast enough to be useable. I suspect that I have to use
> an approximation, but I was hoping someone would spot a major
> inefficiency in my implementation.
>
> The calculation is a kind of o
I have a computation bounded by one step and I have always wondered
how to make it fast enough to be useable. I suspect that I have to use
an approximation, but I was hoping someone would spot a major
inefficiency in my implementation.
The calculation is a kind of outer product of two sets of time
ti, 2010-06-15 kello 11:35 -0400, Anne Archibald kirjoitti:
[clip: Numpy ufunc inner loops are slow]
> This is a bit strange. I think I'd still vote for including this
> optimization, since one hopes the inner loop will get faster at some
> point. (If nothing else, the code generator can probably
Den 15.06.2010 18:30, skrev Sturla Molden:
> A very radical solution would be to get rid of all C, and go for a
> "pure Python" solution. NumPy could build up a text string with OpenCL
> code on the fly, and use the OpenCL driver as a "JIT compiler" for
> fast array expressions. Most GPUs and CP
A very radical solution would be to get rid of all C, and go for a "pure
Python" solution. NumPy could build up a text string with OpenCL code on
the fly, and use the OpenCL driver as a "JIT compiler" for fast array
expressions. Most GPUs and CPUs will support OpenCL, and thus there will
be no
On Tue, Jun 15, 2010 at 9:37 AM, David Cournapeau wrote:
> On Wed, Jun 16, 2010 at 12:16 AM, Pauli Virtanen wrote:
> > ti, 2010-06-15 kello 10:10 -0400, Anne Archibald kirjoitti:
> >> Correct me if I'm wrong, but this code still doesn't seem to make the
> >> optimization of flattening arrays as m
On Wed, Jun 16, 2010 at 12:16 AM, Pauli Virtanen wrote:
> ti, 2010-06-15 kello 10:10 -0400, Anne Archibald kirjoitti:
>> Correct me if I'm wrong, but this code still doesn't seem to make the
>> optimization of flattening arrays as much as possible. The array you
>> get out of np.zeros((100,100)) c
On 15 June 2010 11:16, Pauli Virtanen wrote:
> ti, 2010-06-15 kello 10:10 -0400, Anne Archibald kirjoitti:
>> Correct me if I'm wrong, but this code still doesn't seem to make the
>> optimization of flattening arrays as much as possible. The array you
>> get out of np.zeros((100,100)) can be itera
Hi, all! The scipy doc marathon has gotten off to a very slow start this
summer. We are producing less than 1000 words a week, perhaps because
many universities are still finishing up spring classes. So, this is
a second appeal to everyone to pitch in and help get scipy documented
so that it's e
ti, 2010-06-15 kello 10:10 -0400, Anne Archibald kirjoitti:
> Correct me if I'm wrong, but this code still doesn't seem to make the
> optimization of flattening arrays as much as possible. The array you
> get out of np.zeros((100,100)) can be iterated over as an array of
> shape (1,), which sho
Correct me if I'm wrong, but this code still doesn't seem to make the
optimization of flattening arrays as much as possible. The array you
get out of np.zeros((100,100)) can be iterated over as an array of
shape (1,), which should yield very substantial speedups. Since
most arrays one operates
pe, 2010-06-11 kello 10:52 +0200, Hans Meine kirjoitti:
> On Friday 11 June 2010 10:38:28 Pauli Virtanen wrote:
[clip]
> > I think I there was some code ready to implement this shuffling. I'll try
> > to dig it out and implement the shuffling.
>
> That would be great!
>
> Ullrich Köthe has implem
ti, 2010-06-15 kello 13:18 +0900, David kirjoitti:
> On 06/15/2010 12:15 PM, Vincent Davis wrote:
> > Is this http://github.com/cournape/numpy going to become the git repo?
>
> No, this is just a mirror of the svn repo, and used by various
> developers to do their own stuff.
That's a mirror of a
Alan Bromborsky wrote:
> Dag Sverre Seljebotn wrote:
>
>> Did you have a look at the tensors in Theano? They seem to merge tensor
>> algebra, SymPy, NumPy and (optional) GPU computing etc. Even if it
>> doesn't fill your needs it could perhaps be a better starting point?
>>
>> http://deeplearn
17 matches
Mail list logo
