Add in place version of findall function

[albertomercurio]

Hello,

I added the in place version of the findall function. This is very useful when it is iteratively called inside a function, maybe with some preallocated cache, avoiding to allocate a lot of memory.

[jakobnissen]

See also #43737 - the lazy version might be able to be copied into a vector.

[albertomercurio]

So you mean something like findall!(out, A)?

[jakobnissen]

What I mean is that the lazy version of findall is more universal, in the sense that both eager findall (the one which allocates a vector), and the in-place version can be easily written in terms of the lazy one.
As an example, let's take the general definition of lazy findall:

julia> lazy_findall(p, it) = (k for (k, v) in pairs(it) if p(v));

julia> collect(lazy_findall(isodd, [8,3,6,1,3,7,8,9])) |> print # eager version
[2, 4, 5, 6, 8]

julia> copyto!(zeros(Int, 5), lazy_findall(isodd, [8,3,6,1,3,7,8,9])) |> print # in-place version
[2, 4, 5, 6, 8]

Here, the eager version is simply lazy_findall + collect, and the in-place version is simply lazy_findall + copyto!.

[albertomercurio]

Has this implementation the same performances of my case? Because in your example this involves Iterators, right?

[Seelengrab]

I'm not quite sure this by itself is a good idea. Overwriting the existing data seems very counterintuitive, especially since the original array is not resized & keeps unrelated data around.

[Seelengrab]

Why count first and then loop over the array again? That's double the work, if you move the @view to after the loop, you can just take the view from begin:(begin+count). In the loop you can still safely write into A, there's no need for I up front.

[Seelengrab]

1-based indexing won't work correctly for e.g. OffsetArrays. Not all AbstractArrays are 1-based.

[albertomercurio]

Ok so I think that this implementation is not an optimal one. Let’s close it, and wait for the Lazy implementation discussed above.

[Keno]

Triage does not like this for a few reasons:

1. The array needing to be of a type compatible with the index type of the array.
2. That could be fixed by having input and output be separate arguments that are allowed to alias, but even then, it's not clear what it should do if output is not large enough.
3. Overall, this feels wrong. It's API with odd corner cases that exists only for performance optimization. This should be done either through the lazy version mentioned or by improving memory optimizations.

[albertomercurio]

Ok let’s close this PR