true_pos

[Beliavsky]

In a Fortran Discourse thread Indexing arrays by an array of logicals I mentioned a true_pos function I had written to simulate logical indexing, and @ivan-pi suggested that it be considered for stdlib. To deal with the case of a lbound /= 1 mentioned by mecej4, I have added an optional lower_bound argument. If tf(:) has the same size as x(:), one can write x(true_pos(tf)) to refer to elements of x where tf is .true. One can also write pack(x,tf), but that cannot appear on the LHS of an assignment. I have used true_pos hundreds of times in my codes -- maybe it would be generally useful. Since Fortran has minloc, maxloc, and findloc, maybe true_pos should be renamed trueloc.

pure function true_pos(tf, lower_bound) result(ipos)
! return in ipos the positions of the true elements in tf(:)
logical, intent(in)           :: tf(:)
integer, intent(in), optional :: lower_bound 
integer                       :: ipos(count(tf))
integer                       :: i,j
j = 0
do i=1,size(tf)
   if (tf(i)) then
      j = j + 1
      ipos(j) = i
   end if
end do
if (present(lower_bound)) ipos = ipos + lower_bound - 1
end function true_pos

[milancurcic]

I think it would be useful. I like the name trueloc better than true_pos.

Perhaps controversial, but consider calling this function where. I think it looks very nice in use:

a(where(b > 0)) = 0

which is similar to

where(b > 0) a = 0

A more concise form could be

a(at(b > 0)) = 0

Where would this function belong? Should we introduce a module for array helper functions, e.g. stdlib_array?

[ivan-pi]

I also like trueloc better than true_pos. In MATLAB the function is called find, and also has an optional argument for the number of elements to find.

If trueloc were to be the name, would it make sense to have falseloc too, or does the form:

trueloc(A > B) ! find indexes of true values
trueloc(.not. (A > B)) ! find indexes of false values

suffice?

[arjenmarkus]

Having both might be useful indeed, it is sometimes easier to formulate the condition in a negative way. Op wo 17 nov. 2021 om 16:30 schreef Ivan Pribec ***@***.***>:

…

I also like trueloc better than true_pos. In MATLAB the function is called find <https://de.mathworks.com/help/matlab/ref/find.html>, and also has an optional argument for the number of elements to find. If trueloc were to be the name, would it make sense to have falseloc too, or does the form: trueloc(A > B) ! find indexes of true values trueloc(.not. (A > B)) ! find indexes of false values suffice? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#568 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YRZ2S5RAZQWFKL75EJ3UMPDBJANCNFSM5IFL7KEA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[awvwgk]

A quick test with GFortran 11 shows the following difference in timings for 1200 invocations of trueloc, where and merge (longest array tested is 120000 elements). Timings in seconds.

trueloc	where	merge
2.02	0.39	0.46

[jvdp1]

A quick test with GFortran 11 shows the following difference in timings for 1200 invocations of trueloc, where and merge (longest array tested is 120000 elements). Timings in seconds.

trueloc where merge
2.02 0.39 0.46

Could you provide the details of your test prog, please? I wonder how would compare something like pack( [ (i, i = 1, size(array))], array > 1.0)?

[jvdp1]

A quick test with GFortran 11 shows the following difference in timings for 1200 invocations of trueloc, where and merge (longest array tested is 120000 elements). Timings in seconds.

trueloc where merge
2.02 0.39 0.46

I don't know the details of the program, but trueloc has IMO a different goal than where and merge because it can returns a index vector that could be used for other purposes (which is not always possible with where and merge).

[awvwgk]

Could you provide the details of your test prog, please? I wonder how would compare something like pack( [ (i, i = 1, size(array))], array > 1.0)?

Added the timing routines in #603 as well as a comparison with pack. trueloc is a factor 2 slower than pack.

Also, included a pack based implementation in the statistic there (it gets slower).

[jvdp1]

Actually, with the flags -O3 -fopenmp and GCC11, I got a ratio around 1 with where, ~3- with merge and <1 with pack.

[ivan-pi]

A quick test with GFortran 11 shows the following difference in timings for 1200 invocations of trueloc, where and merge (longest array tested is 120000 elements). Timings in seconds.
trueloc where merge
2.02 0.39 0.46

I don't know the details of the program, but trueloc has IMO a different goal than where and merge because it can returns a index vector that could be used for other purposes (which is not always possible with where and merge).

I agree that trueloc has a different goal from the intrinsics. I can't recall the specifics now, but I think it was related to discretization in a PDE solver (e.g. boundary points require different handling the points in the bulk region). In this case I had to construct the index array so I could reference the right positions in the storage for a sparse matrix.

Therefore I wouldn't be too concerned with the performance penalty. For the case of "simple" assignment depending upon a condition, the specs could contain a note suggesting where or pack as the canonical way of doing this.