Clarify that the results of division operations on integer array data types resulting in floating-point outputs is implementation-defined #362
Conversation
|
This is what I wanted to do in #221, but it was rejected. I still think it's a good idea. |
There was a problem hiding this comment.
This should say why, otherwise it leaves the reader guessing. The pow note says:
If self has an integer data type and other has a floating-point data type, behavior is implementation-dependent (type promotion between data type “kinds” (integer versus floating-point) is unspecified).
I'd like to be a little more strict even, because there really are only two outcomes possible: a floating point array with the expected division result, or an exception. Doing Python 2 style division should be forbidden. So how about saying that explicitly in this note?
Also fixes related note wording for `min()` and `max()`
There was a problem hiding this comment.
Leaving two comments below. I guess I find the fix suggested by @rgommers a bit confusing:
I'd like to be a little more strict even, because there really are only two outcomes possible: a floating point array with the expected division result, or an exception. Doing Python 2 style division should be forbidden. So how about saying that explicitly in this note?
If the spec requires the returned array to be of floating-point type if not raising an error, then it is not fully "implementation defined". We should either
- leave it completely implementation defined, or
- remove the ambiguity by saying the implementation must pick a floating point type (but which to pick is up to the implementation)
+1 for this. Isn't that the same as what I said? |
Co-authored-by: Athan <[email protected]>
kgryte
changed the title
|
Thanks, @honno! |
Resolve #361 by noting any instance of int as out-of-scope.