<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Another approach would be to introduce a method: <div><br></div><div>a.diag(copy=False)</div><div><br></div><div>and leave a.diagonal() alone. Then, a.diagonal() could be deprecated over 2-3 releases. </div><div><br></div><div>-Travis</div><div><br></div><div><br></div><div><div><div>On May 12, 2012, at 8:31 AM, Ralf Gommers wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Sat, May 12, 2012 at 1:54 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="HOEnZb"><div class="h5">On Fri, May 11, 2012 at 9:26 PM, T J <<a href="mailto:tjhnson@gmail.com">tjhnson@gmail.com</a>> wrote:<br>
> On Fri, May 11, 2012 at 1:12 PM, Mark Wiebe <<a href="mailto:mwwiebe@gmail.com">mwwiebe@gmail.com</a>> wrote:<br>
>><br>
>> On Fri, May 11, 2012 at 2:18 PM, Pauli Virtanen <<a href="mailto:pav@iki.fi">pav@iki.fi</a>> wrote:<br>
>>><br>
>>> 11.05.2012 17:54, Frédéric Bastien kirjoitti:<br>
>>> > In Theano we use a view, but that is not relevant as it is the<br>
>>> > compiler that tell what is inplace. So this is invisible to the user.<br>
>>> ><br>
>>> > What about a parameter to diagonal() that default to return a view not<br>
>>> > writable as you said. The user can then choose what it want and this<br>
>>> > don't break the inferface.<br>
>>> [clip]<br>
>>><br>
>>> Agreed, it seems this is the appropriate way to go on here<br>
>>> `diagonal(copy=True)`. A more obscure alternative would be to add a<br>
>>> separate method that returns a view.<br>
>><br>
>><br>
>> This looks like the best way to deal with it, yes.<br>
>><br>
>> Cheers,<br>
>> Mark<br>
>><br>
>>><br>
>>><br>
>>> I don't think changing the default behavior in a later release is a good<br>
>>> idea. It's a sort of an API wart, but IMHO better that than subtle code<br>
>>> breakage.<br>
>>><br>
>>><br>
><br>
> copy=True seems fine, but is this the final plan? What about long term,<br>
> should diag() eventually be brought in line with transpose() and reshape()<br>
> so that it is a view by default? Changing default behavior is certainly not<br>
> something that should be done all the time, but it *can* be done if<br>
> deprecated appropriately. A more consistent API is better than one with<br>
> warts (if this particular issue is actually seen as a wart).<br>
<br>
</div></div>This is my question as well. Adding copy=True default argument is<br>
certainly a fine solution for 1.7, but IMHO in the long run it would<br>
be better for diagonal() to return a view by default.</blockquote><div><br>If you want to get to a situation where the behavior is changed, adding a temporary new keyword is not a good solution in general. Because this forces you to make the change over 3 different releases:<br>
1. introduce copy=True<br> 2. change to copy=False<br> 3. remove copy kw<br>and step 3 is still breaking existing code, because people started using "copy=False". <br><br>See the histogram new_behavior keyword as an example of this.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> (Aside from it<br>
seeming generally more "numpythonic", I see from auditing the code I<br>
have lying around my homedir that it would generally be a free speed<br>
win, and having to remember to type a.diagonal(copy=False) all the<br>
time in order to get full performance seems a bit annoying.)<br>
<br>
I mean, I'm all for conservatism in these things, which is why I<br>
raised the issue in the first place :-). But it also seems like there<br>
should be *some* mechanism for getting there from here (assuming<br>
others agree we want to). There's been grumblings about trying to do<br>
more evolving of numpy in-place instead of putting everything off to<br>
the legendary 2.0, right?<br>
<br>
Unfortunately just putting a deprecation warning on everyone who calls<br>
diagonal() without an explicit copy= argument seems like it would be<br>
*really* obnoxious, though. If necessary we could get more creative...<br>
add a special-purpose ndarray flag like WARN_ON_WRITE so that code<br>
which writes to the returned array continues to work like now, but<br>
also triggers a deprecation warning? I dunno.</blockquote><div><br>Something like this could be a solution. Otherwise, just living with the copy is imho much better than introducing a copy kw.<br><br>Ralf<br><br></div></div>
_______________________________________________<br>NumPy-Discussion mailing list<br><a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>http://mail.scipy.org/mailman/listinfo/numpy-discussion<br></blockquote></div><br></div></body></html>