Behavior is always clear since the user must specify the type of comparison

this is the most compelling argument for me

We need to develop kernels that

1. Perform a intuitive function and
2. Can benefit from fast hw acceleration.
3. Are compatible with Numpy. I don't think anybody uses np.clip() for complex numbers.

@n-west had some really good ideas about making min/max different from clamp for complex numbers.

Clamp

• Re-interpret the complex number as a float[2] and clamp the real/image components separately. This is not a comparison op because it produces two outputs (real/imag)

clamp(c, c_min, c_max) = complex(clamp(c.real, c_min.real, c_max.real),
                                 clamp(c.imag, c_min.imag, c_max.imag))

• Intuitive: It performs the same clamp as a real number for both real and imag.
• Fast: The fastest possible solution. Also faster than np.clip().

Min/Max

For Now: No default complex comparison. Nothing would currently benefit from hw acceleration.
In the Future: Absolute value comparison.

• Intuitive: I think more people would vote for this comparison.
• Fast: AVX512 has a hypot() command that accelerates abs() enabling the hw acceleration of min/max.

This problem seems similar to how nans are compared in floating point, i.e. there are some reasonable choices but no perfect definition.

@rgommers (or others who are familiar with NumPy) -- I wonder why NumPy decided to make the different choices here different functions as opposed to an optional argument, i.e. why define both amax and nanmax instead of amax(..., nans=ignore|max|min)?

It seems like we have consensus on disabling complex comparison ops (and the ops which logically rely on them) for now.

@dylanbespalko Your idea for a complex clamp is interesting, but maybe we can find a new name for it?

The proposed API from @dylanbespalko would work great for my applications! I like the idea of naming the complex clamp something else just to 100% prevent people from thinking np.clip and torch.clamp would do that same thing even though they are named differently (because for other datatypes they are the same operation AFAIK). No very clear operator name comes to mind though

@rgommers (or others who are familiar with NumPy) -- I wonder why NumPy decided to make the different choices here different functions as opposed to an optional argument, i.e. why define both amax and nanmax instead of amax(..., nans=ignore|max|min)?

NumPy added nanmax and co in 2002 (numpy/numpy@cf5c05a45d571). At that point there really wasn't much thought about API design. I can't remember a discussion on changing this.