proposal of new keywords for np.nan_to_num
Hi all, I propose to add some keywords to nan_to_num function. The addition do not modify the actual behavior. Information related with this addition can be found in these links: https://github.com/numpy/numpy/pull/13219 https://github.com/numpy/numpy/pull/9355 The basic idea is to allow the user to use their own defined values when replacing nan, positive infinity and/or negative infinity. The proposed names for the keywords are 'nan', posinf', and 'neginf' respectively. So the usage would be something like this:
Please, could you comment if it would be useful the addition?, if the PR needs any change?... Thanks to Eric, Joseph, Allan and Matti for their comments and revisions on GH. Kind regards.
On Thu, Apr 4, 2019, at 10:12, kikocorreoso wrote:
The added functionality seems fine, given what that function does already. But, a question for those who have seen its API put in place: What is the rationale behind replacing infinities, when the function is called `nan_to_num`? Also, this odd part of the docstring: *NumPy uses the IEEE Standard for Binary Floating-Point for Arithmetic** * *(IEEE 754). This means that Not a Number is not equivalent to infinity.** * The meaning of this note isn't clear to me. Why would the reader suspect that Not a Number is equivalent to infinity? Do we detail somewhere how NaN's vs infinities typically arise in code? Stéfan
On Thu, Apr 4, 2019, at 10:12, kikocorreoso wrote:
The added functionality seems fine, given what that function does already. But, a question for those who have seen its API put in place: What is the rationale behind replacing infinities, when the function is called `nan_to_num`? Also, this odd part of the docstring: *NumPy uses the IEEE Standard for Binary Floating-Point for Arithmetic** * *(IEEE 754). This means that Not a Number is not equivalent to infinity.** * The meaning of this note isn't clear to me. Why would the reader suspect that Not a Number is equivalent to infinity? Do we detail somewhere how NaN's vs infinities typically arise in code? Stéfan
participants (3)
-
Allan Haldane -
kikocorreoso -
Stefan van der Walt