<br><br><div class="gmail_quote">On Wed, May 16, 2012 at 9:55 AM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Tue, May 15, 2012 at 2:49 PM, Frédéric Bastien <<a href="mailto:nouiz@nouiz.org">nouiz@nouiz.org</a>> wrote:<br>
> Hi,<br>
><br>
> In fact, I would arg to never change the current behavior, but add the<br>
> flag for people that want to use it.<br>
><br>
> Why?<br>
><br>
> 1) There is probably >10k script that use it that will need to be<br>
> checked for correctness. There won't be easy to see crash or error<br>
> that allow user to see it.<br>
<br>
</div>My suggestion is that we follow the scheme, which I think gives ample<br>
opportunity for people to notice problems:<br>
<br>
1.7: works like 1.6, except that a DeprecationWarning is produced if<br>
(and only if) someone writes to an array returned by np.diagonal (or<br>
friends). This gives a pleasant heads-up for those who pay attention<br>
to DeprecationWarnings.<br>
<br>
1.8: return a view, but mark this view read-only. This causes crashes<br>
for anyone who ignored the DeprecationWarnings, guaranteeing that<br>
they'll notice the issue.<br>
<br>
1.9: return a writeable view, transition complete.<br>
<br>
I've written a pull request implementing the first part of this; I<br>
hope everyone interested will take a look:<br>
  <a href="https://github.com/numpy/numpy/pull/280" target="_blank">https://github.com/numpy/numpy/pull/280</a><br>
<div class="im"><br>
> 2) This is a globally not significant speed up by this change. Due to<br>
> 1), i think it is not work it. Why this is not a significant speed up?<br>
> First, the user already create and use the original tensor. Suppose a<br>
> matrix of size n x n. If it don't fit in the cache, creating it will<br>
> cost n * n. But coping it will cost cst * n. The cst is the price of<br>
> loading a full cache line. But if you return a view, you will pay this<br>
> cst price later when you do the computation. But it all case, this is<br>
> cheap compared to the cost of creating the matrix. Also, you will do<br>
> work on the matrix and this work will be much more costly then the<br>
> price of the copy.<br>
><br>
> In the case the matrix fix in the cache, the price of the copy is even lower.<br>
><br>
> So in conclusion, optimizing the diagonal won't give speed up in the<br>
> global user script, but will break many of them.<br>
<br>
</div>I agree that the speed difference is small. I'm more worried about the<br>
cost to users of having to remember odd inconsistencies like this, and<br>
to think about whether there actually is a speed difference or not,<br>
etc. (If we do add a copy=False option, then I guarantee many people<br>
will use it religiously "just in case" the speed difference is enough<br>
to matter! And that would suck for them.)<br>
<br>
Returning a view makes the API slightly nicer, cleaner, more<br>
consistent, more useful. (I believe the reason this was implemented in<br>
the first place was that providing a convenient way to *write* to the<br>
diagonal of an arbitrary array made it easier to implement numpy.eye<br>
for masked arrays.) And the whole point of numpy is to trade off a<br>
little speed in favor of having a simple, easy-to-work with high-level<br>
API :-).<br>
<div class="HOEnZb"><div class="h5"><br>
-- Nathaniel<br></div></div></blockquote><div><br>Just as a sanity check, do the scipy tests run without producing any such messages?<br><br>Cheers!<br>Ben Root<br><br></div></div>