On 30 Oct 2014 03:58, "Sturla Molden" wrote:
[...]
> We cannot bundle NumPy or SciPy binaries with FFTW due to GPL [*], but
> as I understand it we already have permission from Intel to bundle
> binary wheels linked with MKL. Accelerate is a system library, so that
> does not pose a license proble
On 29/10/14 10:48, Eelco Hoogendoorn wrote:
> Id rather have us discuss how to facilitate the integration of
> as many possible fft libraries with numpy behind a maximally uniform
> interface, rather than having us debate which fft library is 'best'.
I am happy with the NumPy interface. There
Hi all,
the newly founded Berkeley Institute for Data Science is hiring researchers
with a focus on open source tools for scientific computing, please see here
for details:
https://aprecruit.berkeley.edu/apply/JPF00590
Cheers,
f
--
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-
On Wed, Oct 29, 2014 at 5:39 AM, Andrew Nelson wrote:
> I have a 4D array, A, that has the shape (NX, NY, 2, 2). I wish to
> perform matrix multiplication of the 'NY' 2x2 matrices, resulting in the
> matrix B. B would have shape (NX, 2, 2).
What you are looking for is dot.reduce and NumPy doe
On Wed, Oct 29, 2014 at 10:39 AM, Andrew Nelson wrote:
> Dear list,
> I have a 4D array, A, that has the shape (NX, NY, 2, 2). I wish to
> perform matrix multiplication of the 'NY' 2x2 matrices, resulting in the
> matrix B. B would have shape (NX, 2, 2). I believe that np.einsum would
> be up
On 29.10.2014 19:40, Henry Gomersall wrote:
> There could be an argument that this sort of capability should be added
> to the pyfftw package, as a package level config.
>
> Something like:
>
> import pyfftw
> pyfftw.default_threads = 4
I think that would be great, though probably slightly off
On 29/10/14 18:23, Alexander Eberspächer wrote:
> Definitely. My attempt at streamlining the use of pyfftw even further
> can be found here:
>
> https://github.com/aeberspaecher/transparent_pyfftw
There could be an argument that this sort of capability should be added
to the pyfftw package, as a
On Wed, Oct 29, 2014 at 6:05 PM, Julian Taylor
wrote:
> On 29.10.2014 05:30, Charles R Harris wrote:
>> Hi All,
>>
>> It is proposed to deprecate, then remove, pkgload and PackageLoader.
>>
>> Complaints? Cries of Anguish?
>
> I don't mind the deprecation, but I have to ask why? is it causing issu
On 29.10.2014 18:03, Pierre-Andre Noel wrote:
>>> Id rather have us discuss how to facilitate the integration of as
> many possible fft libraries with numpy behind a maximally uniform
> interface, rather than having us debate which fft library is 'best'.
>
> I agree with the above.
Absolutely. I
On 29.10.2014 05:30, Charles R Harris wrote:
> Hi All,
>
> It is proposed to deprecate, then remove, pkgload and PackageLoader.
>
> Complaints? Cries of Anguish?
>
I don't mind the deprecation, but I have to ask why? is it causing issues?
it does look like something some people use in their wor
On Wed, Oct 29, 2014 at 2:16 AM, Sebastian Berg
wrote:
> On Di, 2014-10-28 at 14:03 -0400, Alan G Isaac wrote:
> I don't really like flat (it is a pretty old part of numpy), but I
> agree, while you can force nditer to be C-contiguous, nditer has its own
> problems and is also pretty complex. I w
On Tue, Oct 28, 2014 at 10:11 PM, Nathaniel Smith wrote:
> .diagonal has no magic, it just turns out that the diagonal of any strided
> array is also expressible as a strided array. (Specifically, new_strides =
> (sum(old_strides),).)
This is genius! Once you mentioned this, it is obvious how
On Tue, Oct 28, 2014 at 10:11 PM, Nathaniel Smith wrote:
> > I don't think so - I think all the heavy lifting is already done in
> flatiter. The missing parts are mostly trivial things like .size or .shape
> or can be fudged by coercing to true ndarray using existing
> flatiter.__array__ method.
>> Id rather have us discuss how to facilitate the integration of as
many possible fft libraries with numpy behind a maximally uniform
interface, rather than having us debate which fft library is 'best'.
I agree with the above.
> I would agree if it were not already there, but removing it (lik
Hey,
there are several ways how to proceed.
- My proposed solution covers the 80% case quite well (at least I use
it all the time). I'd convert the doctests into unittests and we're
done.
- We could slightly change the interface to leave out the surrounding
square brackets, i.e. turning `stack([
/me looks at pydoc numpy.pkgload
What in the world?!
On Wed, Oct 29, 2014 at 7:12 AM, Robert Kern wrote:
> On Wed, Oct 29, 2014 at 4:30 AM, Charles R Harris
> wrote:
> > Hi All,
> >
> > It is proposed to deprecate, then remove, pkgload and PackageLoader.
> >
> > Complaints? Cries of Anguish?
>
On Mi, 2014-10-29 at 13:05 +0100, Sebastian Berg wrote:
> On Mi, 2014-10-29 at 20:39 +1100, Andrew Nelson wrote:
> > Dear list,
> > I have a 4D array, A, that has the shape (NX, NY, 2, 2). I wish to
> > perform matrix multiplication of the 'NY' 2x2 matrices, resulting in
> > the matrix B. B would
On Mi, 2014-10-29 at 20:39 +1100, Andrew Nelson wrote:
> Dear list,
> I have a 4D array, A, that has the shape (NX, NY, 2, 2). I wish to
> perform matrix multiplication of the 'NY' 2x2 matrices, resulting in
> the matrix B. B would have shape (NX, 2, 2). I believe that
> np.einsum would be up to
On Wed, Oct 29, 2014 at 4:30 AM, Charles R Harris
wrote:
> Hi All,
>
> It is proposed to deprecate, then remove, pkgload and PackageLoader.
>
> Complaints? Cries of Anguish?
Tears of joy.
--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussi
On Wed, Oct 29, 2014 at 9:48 AM, Eelco Hoogendoorn <
hoogendoorn.ee...@gmail.com> wrote:
> My point isn't about speed; its about the scope of numpy. typing
> np.fft.fft isn't more or less convenient than using some other symbol from
> the scientific python stack.
>
> Numerical algorithms should be
On 29 October 2014 10:48, Eelco Hoogendoorn wrote:
> My point isn't about speed; its about the scope of numpy. typing np.fft.fft
> isn't more or less convenient than using some other symbol from the
> scientific python stack.
The problem is in distribution. For many users, installing a new
librar
You need to specify your input format. Also, if your output matrix misses
the NY dimension, that implies you wish to contract (sum) over it, which
contradicts your statement that the 2x2 subblocks form the matrices to
multiply with. In general, I think it would help if you give a little more
backgr
Andrew Nelson writes:
>
> Dear list,I have a 4D array, A, that has the shape (NX, NY, 2, 2). I
wish to perform matrix multiplication of the 'NY' 2x2 matrices, resulting
in the matrix B. B would have shape (NX, 2, 2). I believe that np.einsum
would be up to the task, but I'm not quite sure o
My point isn't about speed; its about the scope of numpy. typing np.fft.fft
isn't more or less convenient than using some other symbol from the
scientific python stack.
Numerical algorithms should be part of the stack, for sure; but should they
be part of numpy? I think its cleaner to have them in
Dear list,
I have a 4D array, A, that has the shape (NX, NY, 2, 2). I wish to perform
matrix multiplication of the 'NY' 2x2 matrices, resulting in the matrix B.
B would have shape (NX, 2, 2). I believe that np.einsum would be up to the
task, but I'm not quite sure of the subscripts I would need t
On Di, 2014-10-28 at 14:03 -0400, Alan G Isaac wrote:
> On 10/28/2014 1:42 PM, Stephan Hoyer wrote:
> > np.nditer is a reasonable alternative to .flat (and it's documented as
> > such), but it's a rather inelegant, kitchen-sink type function.
>
>
> I'm not sure what "reasonable" means here,
> ot
On Di, 2014-10-28 at 20:37 -0400, Alexander Belopolsky wrote:
>
> On Tue, Oct 28, 2014 at 1:42 PM, Stephan Hoyer
> wrote:
> .flat lets you iterate over all elements of a N-dimensional
> array as if it was 1D, without ever needing to make a copy of
> the array. In contrast,
27 matches
Mail list logo
