Thu 27 Apr 2017 07:39:09 PM UTC, comment #7:
What do you think of the included patch? I modified find_nonzero_elem_idx in find.cc in order to manage the DiagArray2 case. Please, revise carefully since these are my first experiments with C++.
(file #40522)
|
Thu 27 Apr 2017 12:24:55 AM UTC, comment #6:
The script shows that that is not always true, it depends on the types of elements of the matrix (compared bool vs double).
Also the complexities do not seem to differ that much.
What I meant is that finding on a diagonal matrices is just finding on the vector of its diagonal, so the "overload" is just calling find on the diag vector, i.e. find (diag(A),...)
|
Wed 26 Apr 2017 11:01:48 PM UTC, comment #5:
I don't think so. Since there is no overload it appears that find converts the matrix to full, and then calls find on that. However, there is something else going on since
is a relatively quick operation.
|
Wed 26 Apr 2017 10:12:16 PM UTC, comment #4:
Isn't the find of diagMatrix A just find(diag(A),...)?
|
Wed 26 Apr 2017 08:57:57 PM UTC, comment #3:
Confirmed. The trouble seems to be that there is no overload of the find function for DiagMatrix. I think any change needs to start in liboctave/array/. But it might also require changes to libinterp/corefcn/find.cc.
|
Sat 15 Apr 2017 02:02:14 PM UTC, comment #2:
I forgot to mention that this was identified on this
stackoverflow question http://stackoverflow.com/a/43393446/1609556
where I mention that find has special cases for several data types and it is missing diagonal matrices. It's just weird that it takes so much more time so maybe there is something else going on.
|
Thu 13 Apr 2017 02:14:23 PM UTC, comment #1:
The attached script produces (using function speed)
So it seems the problem is with doubles, as booleans are close to the optimal. I am puzzled by the negative order of the boolean full case.
(file #40391)
|
Thu 13 Apr 2017 01:19:14 PM UTC, original submission:
I though this was because find converts a diagonal to a full matrix internally, but even if calling full ourselves before find, it's still much faster so I am no longer sure:
|