[Numpy-discussion] Should arr.diagonal() return a copy or a view? (1.7 compatibility issue)
nouiz at nouiz.org
Tue May 15 09:49:05 EDT 2012
In fact, I would arg to never change the current behavior, but add the
flag for people that want to use it.
1) There is probably >10k script that use it that will need to be
checked for correctness. There won't be easy to see crash or error
that allow user to see it.
2) This is a globally not significant speed up by this change. Due to
1), i think it is not work it. Why this is not a significant speed up?
First, the user already create and use the original tensor. Suppose a
matrix of size n x n. If it don't fit in the cache, creating it will
cost n * n. But coping it will cost cst * n. The cst is the price of
loading a full cache line. But if you return a view, you will pay this
cst price later when you do the computation. But it all case, this is
cheap compared to the cost of creating the matrix. Also, you will do
work on the matrix and this work will be much more costly then the
price of the copy.
In the case the matrix fix in the cache, the price of the copy is even lower.
So in conclusion, optimizing the diagonal won't give speed up in the
global user script, but will break many of them.
I'm sure there is corner case where speed up of diag will be
significant, but I don't think they happen in real code. And if they
happen, asking them to add a keyword is better then breaking make
script I my opinion.
On Sun, May 13, 2012 at 4:11 AM, Nathaniel Smith <njs at pobox.com> wrote:
> On Sun, May 13, 2012 at 3:28 AM, Travis Oliphant <travis at continuum.io> wrote:
>> Another approach would be to introduce a method:
>> and leave a.diagonal() alone. Then, a.diagonal() could be deprecated over
>> 2-3 releases.
> This would be a good idea if we didn't already have both
> np.diagonal(a) (which is an alias for a.diagonal()) *and* np.diag(a),
> which do different things. And the new a.diag() would be different
> from the existing np.diag(a)...
> -- Nathaniel
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
More information about the NumPy-Discussion