Get rid of ArborX_DetailsKokkosExtMinMaxOperations.hpp

[aprokop]

KokkosExt functions are a subset of the Kokkos functions.

[dalg24]

Remove the <ArborX_DetailsKokkosExtMinMaxOperations.hpp> header altogether.
All that functionality is available from Kokkos:: since version 3.7

[dalg24]

KokkosExt functions are a subset of the Kokkos functions. Their major limitation is that they break comparing two values of different types. This is particularly problematic. And resolving it in ArborX is challenging, given that this requires correct promotion of the arguments. half_t and bhalf_t would be particularly challenging.

There is nothing special about ArborX (nor Kokkos) implementation of min and max. If you pass two arguments of different types argument template deduction will fail. This is the same as with the standard library, just decorating the function templates with __host__ __device__ annotations.

The mere fact it is available in Kokkos is sufficient to argue for removal.
I don't understand why you are bringing up half types.

[aprokop]

I don't understand why you are bringing up half types.

Maybe I misunderstood what Kokkos does. I was hoping that it would provide min(half_t, float) or similar. I now understand that C++ standard does not provide this. I'm not sure what would be the best way to do this then. The use case in point is having a Box<half_t> expanded by a Point<float>.

[dalg24]

One caveat with the Kokkos implementation is that we need to include <Kokkos_Core.hpp>. It is not obvious to me that it is a good change.

[aprokop]

One caveat with the Kokkos implementation is that we need to include <Kokkos_Core.hpp>. It is not obvious to me that it is a good change.

I partially agree. I don't like that either, and would very much prefer that Kokkos_MinMaxClamp.hpp was a public header in Kokkos. Having said that, I think it's pretty safe to say that Kokkos_Core.hpp is included in almost every file in ArborX, one way or another, and definitely in every example and benchmark, and most tests. So I don't see how this changes the status quo.

[dalg24]

My point is that the maintenance burden for KokkosExt::{min,max} is low and that the current implementation in Kokkos does not provide any other advantage than we not having to define our own.