Replace the call to sort by select in stdlib_stats_median

[jvdp1]

Based on the performance tests reported in stdlib_selection.md, I replaced all calls to sort by select in stdlib_stats_median.fypp.

[gareth-nx]

Thanks very much!

[gareth-nx]

I just realised that it will also be necessary to update the specs.

At the moment the specs indicated that after a call to median, the input array is sorted. Whereas now it will only be partially sorted.

[jvdp1]

I just realised that it will also be necessary to update the specs.

At the moment the specs indicated that after a call to median, the input array is sorted. Whereas now it will only be partially sorted.

Indeed, I forgot it. It is now done. Note that the input array is an intent(in) and it is therefore not modified. A copy of the array is always done.

[leonfoks]

The side effect of having a modified input array is actually beneficial to the speed of KdTrees once those are implemented or any other recursive partitioning that uses the median.
Can an optional argument be added like “in-place” (like a lot of numpy methods) so a user can specifically request in place memory manipulation?

[gareth-nx]

The side effect of having a modified input array is actually beneficial to the speed of KdTrees once those are implemented or any other recursive partitioning that uses the median. Can an optional argument be added like “in-place” (like a lot of numpy methods) so a user can specifically request in place memory manipulation?

@leonfoks In this case, one could just use select or arg_select directly -- and the in-place partial sort will happen.

However that is not exactly the same as computing the median (if there are an even number of elements). Does the KdTree application need this variant of the median, or does the result of select or arg_select alone suffice?

[leonfoks]

Good point @gareth-nx ! I forgot that median was wrapping the select methods... Ignore my last comment!

[gareth-nx]

LGTM, thanks

[milancurcic]

Looks good, thank you!