docs: clarify clip behavior when arguments have different data types
#896
Conversation
kgryte
added
API change
| @@ -836,10 +836,12 @@ def clip( | |||
| Notes | |||
| ----- | |||
|
|
|||
| - This function is conceptually equivalent to ``maximum(minimum(x, max), min)`` when ``x``, ``min``, and ``max`` have the same data type. | |||
| - For scalar ``min`` and/or ``max``, the scalar values must be converted to zero-dimensional arrays having the same data type as ``x`` prior to broadcasting. | |||
There was a problem hiding this comment.
This sounds a bit like an implementation requirement, rather than only clarifying the intended semantics. It's also not what implementations do for mixed-kind dtypes:
>>> np.clip(np.arange(3, dtype=np.int32), -1, 1.5).dtype
dtype('float64')I suggest saying instead that for scalars regular type promotion rules have to be followed (and hence mixed-kind is undefined).
There was a problem hiding this comment.
Yeah, but wouldn't that be functionally the same? According to type promotion rules involving scalars and arrays, the first step is to convert the scalar to the same dtype as the array. When I included the line about conversion, that was what I had in mind.
There was a problem hiding this comment.
Okay. I've updated the text to hopefully address your concerns regarding outside-the-standard behavior.
There was a problem hiding this comment.
...and I needed to relax the output array data type requirement.
This PR
clipbehavior is undefined whenminormaxis outside the bounds ofx#814 (comment) and Python scalars in elementwise functions #807 and supersedes feat!: allow clip to have int min or max when x is floating-point #811 to indicate that behavior is only defined whenminandmaxhave the same data type asx. After reviewing SciPy and scikit-learn usage ofxp.clipandnp.clip, the overwhelming usage was using scalarminandmax. For all instances that I found with arrayminandmax, type promotion behavior was not expected. Given the various edge cases whenminandmaxare not the same type asx, it seems prudent to limit portable behavior to the scenario which avoids edge cases altogether.clampas suggested in docs: clarify thatclipbehavior is undefined whenminormaxis outside the bounds ofx#814 (comment).minand/ormaxare scalar values.