feat: add ndarray/base/find

[headlessNode]

Progresses #2656 .

Description

What is the purpose of this pull request?

This pull request:

• add ndarray/base/find

Related Issues

Does this pull request have any related issues?

This pull request:

• progresses [RFC]: achieve ndarray API parity with built-in JavaScript arrays  #2656

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

---

@stdlib-js/reviewers

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
ndarray/base/find	$\color{green}4221/4221$ $\color{green}+100.00\%$	$\color{green}303/303$ $\color{green}+100.00\%$	$\color{green}25/25$ $\color{green}+100.00\%$	$\color{green}4221/4221$ $\color{green}+100.00\%$

The above coverage report was generated for the changes in this PR.

[headlessNode]

@kgryte Ready for initial review.

[headlessNode]

Benchmarks CI failure expected due to time-out.

[headlessNode]

@kgryte refactored the tests, please check 🤞🏻

[kgryte]

Took another look at this. The updated tests seem okay in terms of using isSameValue. I think my main concern is whether it is even appropriate using blocked iteration in this package.

Why? Because otherwise the first element which satisfies a predicate function could be different depending on whether an array is backed by a contiguous or a non-contiguous buffer, despite the view being the same. My guess is that a user would expect that a contiguous array and a non-contiguous array view should return the same value. Otherwise, a user could call find on a non-contiguous ndarray and then copy the data to a contiguous array and despite the arrays have the same values and being equivalent in every respect from the user's POV, they could get different values, simply because, under-the-hood, we use blocked iteration for one and contiguous iteration for the other.

In which case, I am tempted to say that we should avoid supporting blocked iteration at all in this package. This would have performance implications (due to cache abuse), but only in the case where we have mixed sign strides (e.g., if a user creates a view in which elements along a dimension are reversed), but this isn't likely to be the dominant case. In most instances, users should have contiguous arrays with all positive/negative strides and small enough datasets. When this is not the case, my guess is that datasets will be small enough that most users won't notice a significant perf difference due to this implementation not using cache-optimal iteration.