Add a New Comment (Rich Markup)

Comment Type & Canned Response: None None > Multiple Canned Responses Fixed in development Crash with no stack trace Already fixed in newer version Fixed in stable Bad description Bad description and crash Bad stack trace Obsolete version Duplicate and not fixed Duplicate and needs more info Duplicate and fixed Need info and old

( Jump to the original submission )

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)

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),...)

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

find (full (diag))

is a relatively quick operation.

Isn't the find of diagMatrix A just find(diag(A),...)?

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.

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.

The attached script produces (using function speed)

> find_timeit Order, time per operation (ones) Full: 1.7, 3.2e-08 Diag: 2.1, 1.4e-09 Opt: 0.28, 2.4e-06 Order, time per operation (bool) Full: -0.0084, 1.4e-05 Diag: 0.056, 8.6e-06 Opt: 0.4, 9.8e-07

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)

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:

octave> d = eye (10000); octave> f = full (eye (10000)); octave> for i=1:10, find (d); endfor, t = cputime (); for i=1:100, find (d); endfor, cputime () -t ans = 104.37 octave> for i=1:10, find (f); endfor, t = cputime (); for i=1:100, find (f); endfor, cputime () -t ans = 57.920 octave> for i=1:10, find (full (d)); endfor, t = cputime (); for i=1:100, find (full (d)); endfor, cputime () -t ans = 58.280

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files: Comment:

Depends on the following items: None found

Items that depend on this one: None found

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only project members can vote.

Please enter the title of George Orwell's famous dystopian book (it's a date):

Follow 4 latest changes.

Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code

Powered by Savane 3.10