Thanks Aaron. This categorization makes sense, and I agree with "must" -> "should".

I made all transcendental functions require floating-point inputs (i.e., no integers). This is because they say the output must use type promotion, but integer dtypes do not type promote to floating-point dtypes according to the type promotion rules.

This seems correct to me. Most libraries will happily accept integer dtypes and upcast to float, but IIRC at least TensorFlow raises an exception instead.

+1 for the pow proposal and listing the special case.

divide should not be limited I believe. It's different from transcendental functions, because it's more important that it matches / (which in Python 3 does int / int -> float) than that there's no casting rules for int to float.

The special case of pow(0,0) is already addressed in the spec by:

If x2_i is +0, the result is 1, even if x1_i is NaN.
If x2_i is -0, the result is 1, even if x1_i is NaN.

Re: divide. If integer dtypes are to be explicitly permitted in the spec, we should state explicitly something to the effect of

If x1 has an integer dtype, the array must be cast to the default floating-point data type prior to computing results.

Ditto for x2.

If the goal is to match Python 3 / behavior exactly, then we'd need to recommend casting to float64, but this does not seem desirable.

I made pow and divide only defined for floating-point inputs.

I will also update the array methods as per #98 (comment) in another PR once this is merged.

Can you do this follow-up @asmeurer?