Marten van Kerkwijk gmail.com> writes:
> I did a few simple timing tests (see comment in PR), which suggests it is
hardly worth having the cache. Indeed, if one really worries about speed,
one should probably use pyFFTW (scipy.fft is a bit faster too, but at least
for me the way real FFT values a
> > For a 1D array a of shape (N,), I expect a.T2 to be of shape (N, 1),
>
> Why not (1,N)? -- it is not well defined, though I suppose it's not so
> bad to establish a convention that a 1-D array is a "row vector"
> rather than a "column vector".
I like Todd's simple proposal: a.T2 should be equi
Alan Isaac gmail.com> writes:
> But underlying the proposal is apparently the
> idea that there be an attribute equivalent to
> `atleast_2d`. Then call it `d2p`.
> You can now have `a.d2p.T` which is a lot
> more explicit and general than say `a.T2`,
> while requiring only 3 more keystrokes.
H
Nathaniel Smith pobox.com> writes:
> An alternative that was mentioned in the bug tracker
> (https://github.com/numpy/numpy/issues/7495), possibly by me, would be
> to have arr.T2 act as a stacked-transpose operator, i.e. treat an arr
> with shape (..., n, m) as being a (...)-shaped stack of (n,
Le 08/04/2015 21:19, Yuxiang Wang a écrit :
> I think spyder supports code highlighting in C and that's all...
> There's no way to compile in Spyder, is there?
>
Well, you could write a compilation script using Scons and run it from
spyder ! :)
But no, spyder is very python-oriented and there is
Le 08/09/2014 15:29, Stefan Otte a écrit :
> Hey,
>
> quite often I work with block matrices. Matlab offers the convenient notation
>
> [ a b; c d ]
>
> to stack matrices. The numpy equivalent is kinda clumsy:
>
> vstack([hstack([a,b]), hstack([c,d])])
>
> I wrote the little function `stack` t
Le 08/09/2014 16:41, Sturla Molden a écrit :
> Stefan Otte wrote:
>
>> stack([[a, b], [c, d]])
>>
>> In my case `stack` replaced `hstack` and `vstack` almost completely.
>>
>> If you're interested in including it in numpy I created a pull request
>> [1]. I'm looking forward to getting some fe
loadtxt currently has a keyword to change the comment token. The PR
#4612 [1] enables to define multiple comment token for a file. It is
motivated by #2633 [2]
What is your position on this one ?
Joseph
[1] https://github.com/numpy/numpy/pull/4612
[2] https://github.com/numpy/numpy/i
I have an old PR [1] to fix #2142 [2]. The idea is to have a new keyword
for all fft functions to define the normalisation of the fft:
- if 'norm' is None (the default), the normalisation is the current one:
fft() is not normalized ans ifft is normalized by 1/n.
- if norm is "ortho", the direct and
Le 24/07/2014 12:55, Thomas Unterthiner a écrit :
> I don't agree. The problem is that I expect `mean` to do something
> reasonable. The documentation mentions that the results can be
> "inaccurate", which is a huge understatement: the results can be utterly
> wrong. That is not reasonable. At the
Le 18/07/2014 22:46, Chris Barker a écrit :
> On Fri, Jul 18, 2014 at 1:15 PM, Joseph Martinot-Lagarde
> <mailto:joseph.martinot-laga...@m4x.org>> wrote:
>
> In addition,
> you have to use AltGr on some keyboards to get the brackets.
>
>
> If it's
Le 18/07/2014 20:42, Charles G. Waldman a écrit :
> Well, if the goal is "shorthand", typing numpy.array(numpy.mat())
> won't please many users.
>
> But the more I think about it, the less I think Numpy should support
> this (non-Pythonic) input mode. Too much molly-coddling of new users!
> When d
Le 15/07/2014 18:18, Chris Barker a écrit :
> (or does HDF support var-length
> elements?)
>
It does: http://www.hdfgroup.org/HDF5/doc/TechNotes/VLTypes.html
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/list
Le 22/03/2014 19:13, Nathaniel Smith a écrit :
> Hi all,
>
> After 88 emails we don't have a conclusion in the other thread (see
> [1] for background). But we have to come to some conclusion or another
> if we want @ to exist :-). So I'll summarize where the discussion
> stands and let's see if we
Le 16/03/2014 15:39, Eelco Hoogendoorn a écrit :
> Note that I am not opposed to extra operators in python, and only mildly
> opposed to a matrix multiplication operator in numpy; but let me lay out
> the case against, for your consideration.
>
> First of all, the use of matrix semantics relative t
15 matches
Mail list logo
