DOC: fix median docstrings around float16/float32 inputs#31560
DOC: fix median docstrings around float16/float32 inputs#31560Atharva2012 wants to merge 6 commits into
Conversation
|
@seberg This is my first PR for this project. Could use your opinion. |
|
Sorry, but this is the wrong approach. You should make sure that |
Atharva2012
force-pushed
the
fix-ma-median-dtype-promotion
branch
from
8c4d18f to
ec80318
Compare
|
@seberg Thank you for the feedback! After checking, both np.median and np.ma.median return the same dtype as the input consistently, so this is a documentation issue. I've updated the docstring to accurately reflect the actual behavior. |
seberg
changed the title
seberg
changed the title
|
@seberg Following the discussion here, and all the related pull request, I've went ahead and modified the percentile, quantile, nanpercentile and nanquantile docstrings to reflect the actual behavior, as they're mentioned in the original issue. @MaanasArora Thankyou for your suggestion, I've modified the wording in the docstring so that it's easier to understand. |
MaanasArora
left a comment
MaanasArora
left a comment
There was a problem hiding this comment.
Thank you, just a wording suggestion for consistency (np.median reads a bit unnaturally), otherwise looks good to me. I think this is correct looking at the underlying logic.
| A new array holding the result. Return data-type is ``float64`` | ||
| for integer input, or the input data-type, otherwise. If `out` is |
There was a problem hiding this comment.
| A new array holding the result. Return data-type is ``float64`` | |
| for integer input, or the input data-type, otherwise. If `out` is | |
| A new array holding the result. For integer input, the output | |
| data-type is ``float64``. Otherwise, the output data-type | |
| is the same as that of the input. If `out` is specified, that | |
| array is returned instead. |
This is worded differently from the other functions.
There was a problem hiding this comment.
Thanks for the suggestion! I think I'll keep the original phrasing here since it conveys the same information a bit more directly and concisely. But happy to discuss further if you feel strongly otherwise.
There was a problem hiding this comment.
That's fine, but then I think this should be the same for the other functions (is there a reason why it isn't)? I pulled this phrasing from the other functions. (I don't think the input data-type, otherwise is the right tone, but otherwise this is OK.)
The original change felt unnecessarily long Co-authored-by: Maanas Arora <maanasarora23@gmail.com>
…harva2012/numpy into fix-ma-median-dtype-promotion
MaanasArora
left a comment
MaanasArora
left a comment
There was a problem hiding this comment.
Thank you, just linting issues now!
3 participants
PR summary
np.ma.median does not promote float16 and float32 inputs to float64 as documented. The docstring states the return type should be float64 for floats smaller than float64, but the result stays in the input dtype instead.
The bug is in _median in numpy/ma/extras.py. Two code paths, the 1D path and the N-D path, use np.true_divide without first casting to the correct output dtype. The fix computes out_dtype = np.result_type(asorted.dtype, np.float64) and casts before dividing in both paths.
UPDATE: After reviewer feedback, it was found that both np.median and np.ma.median return the same dtype as the input consistently. The issue is in the docstring, not the code. This PR now corrects the docstring in numpy/ma/extras.py to accurately reflect the actual behavior.
Closes #31486 Related to: #29003
First time committer introduction
I am Atharva, I use NumPy for academic projects, but it's my first time contributing to this open source project. I kept the change small and focused on a single well-defined bug.
** AI Disclosure**
AI was used to reword the PR description in more suitable language.