On 7/22/2013 3:10 PM, Nathaniel Smith wrote:
> Having .T but not .H is an example of this split.
Hate to do this but ...
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
How much is the split a rule or "just" a convention, and
On the other hand, the most salient quality an unavoidable copy is that it is
unavoidable. For people for whom using Hermitian conjugates is common, it's not
like they won't do it just because they can't avoid a copy that can't be
avoided. Given that if a problem dictates a Hermitian conjugate
What if .H is not an attribute, but a method? Is this enough of a warning about
copying?
Eugene
-Original Message-
From: numpy-discussion-boun...@scipy.org
[mailto:numpy-discussion-boun...@scipy.org] On Behalf Of Nathaniel Smith
Sent: Monday, July 22, 2013 3:11 PM
To: Discussion of Nume
On Thu, Jul 18, 2013 at 3:18 PM, Stéfan van der Walt wrote:
> On Sat, Jul 13, 2013 at 7:46 PM, Nathaniel Smith wrote:
>> Why not just write
>>
>> def H(a):
>> return a.conj().T
>
> It's hard to convince students that this is the Best Way of doing
> things in NumPy. Why, they ask, can you do
On Mon, Jul 22, 2013 at 10:55 AM, Yaroslav Halchenko
wrote:
> At some point I hope to tune up the report with an option of viewing the
> plot using e.g. nvd3 JS so it could be easier to pin point/analyze
> interactively.
>
>
shameless plug... the soon-to-be-finalized matplotlib-1.3 has a WebAgg
ba
At some point I hope to tune up the report with an option of viewing the
plot using e.g. nvd3 JS so it could be easier to pin point/analyze
interactively.
On Sat, 20 Jul 2013, Pauli Virtanen wrote:
> 20.07.2013 01:38, Nathaniel Smith kirjoitti:
> > The biggest ~recent change in master's linalg wa
On Fri, 19 Jul 2013, Warren Weckesser wrote:
> Well, this is embarrassing: https://github.com/numpy/numpy/pull/3539
> Thanks for benchmarks! I'm now an even bigger fan. :)
Great to see that those came of help! I thought to provide a detailed
details (benchmarking all recent commits) to provid
On Sat, Jul 20, 2013 at 7:44 AM, wrote:
> related: is there any advantage to np.add.reduce?
> I find it more difficult to read than sum() and still see it used sometimes.
I think ``np.add.reduce`` just falls out of the ufunc
implementation--there's no "per ufunc" choice to remove certain parts
o
