On Mon, Oct 27, 2008 at 12:27 PM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> I just got back from some travel and will try to update the doc later
> this evening with all the feedback and will post again, so that we can
> converge on a final doc, which I'll then pitch over the fence to the
> pyth
Hi numpy group,
I have a problem I know there is an elegant solution to, but I can't
wrap my head around the right way to do the indexing.
The problem:
I have a 2D array that has been chopped up into 3 dimensions - it was [ time
X detectors ], it is now [ scans X time X detectors ]. During th
On 28-Oct-08, at 5:57 PM, Fabrice Silva wrote:
> Are there some parts of the code that may be used only once to
> calculate
> both the gradient and the second derivative (isn't it called the
> hessian, at least in the N-d case) ?
Probably. I'd imagine depends on your differencing scheme; centr
Le mardi 28 octobre 2008 à 15:28 -0600, Andrew Hawryluk a écrit :
> I agree that the gradient functions should be combined, especially
> considering how much redundant code would be added by keeping them
> separate. Here is one possible implementation, but I don't like the
> signature yet as it dep
On Tue, Oct 28, 2008 at 16:28, Andrew Hawryluk <[EMAIL PROTECTED]> wrote:
> I agree that the gradient functions should be combined, especially
> considering how much redundant code would be added by keeping them separate.
> Here is one possible implementation, but I don't like the signature yet a
I agree that the gradient functions should be combined, especially considering
how much redundant code would be added by keeping them separate. Here is one
possible implementation, but I don't like the signature yet as it departs from
the current behaviour. At the risk of demonstrating my ignora
On Mon, Oct 27, 2008 at 5:28 PM, Robin <[EMAIL PROTECTED]> wrote:
[...]
>
> Similarly with the GOTO blas, but I'm not sure if numpy builds with
> that, so maybe we should take that reference out.
>
I'd like to let it their, as it is at the same performance level then
MKL. ATLAS don't have the same
Hi,
I looked at this ticket and whipped up two alternative patches, like mentioned
in
the description: in-memory or temporary dir on disk. On my computer
the second one is slightly faster.
I think it is important to merge some version of this fix. In it's current form,
someone using numpy.io.sav
Hi Andrew
We should discuss different options for the implementation. The
namespace is fairly cluttered, and it may be that we want to implement
gradient3 some time in the future as well. Maybe something like
gradient(f, 1, 2, 3, order=2)
would work -- then we can combine gradient and gradient
