@colesbury Depressingly, there's not a good precedent to follow here.

• IEEE 754-201X defines operators maximum and maximumNumber which respectively propagate NaNs and squash NaNs.

• std::max uses a ternary operator (a > b) ? a : b which does not match either of the defined IEEE 754 operations, and is not commutative.

• C differs from C++, with fmax matching IEEE 754 maximumNumber

• NumPy defines max which matches IEEE 754 maximum and maxnan which matches maximumNumber

• X86: SSE MAXPS matches std::max definition, with the same issues. AVX-512 VRANGE can implement the IEEE 754 operators.

• ARMv8: NEON provides fmax which matches IEEE 754 maximum and fmaxnm which matches maximumNumber

Based on prior discussion, my understanding is that we want to follow the NumPy example in PyTorch of propagating NaNs by default. In my opinion the best option, if we don't want to keep the existing name, is to standardize on the IEEE 754 operator names, since all of the others are overloaded across architectures and languages.

@resistor yeah, minimum and maximum seem like reasonable names as they propagate NaNs in IEEE draft and also NumPy.

Mostly, I'm thinking of operations that need to be written for both scalar types (e.g. float) and the vector types:

Along these lines, it may also be worth adding a implementation for scalar types. Something like:

template <class T> 
inline T minimum(const T& a, const T& b) { ... }

With the idea being that one could call vec256::minimum(float, float) and vec256::minimum(Vec256, Vec256) and it would perform the same operation.

An example of this is fmadd

@colesbury ping