Hi all, During the last triage meeting, the topic of np.fix came up. I'm sure this has come up in the past, but I was surprised to discover that np.fix is totally superfluous - it has the exact same output as np.trunc. Worse than that, it's implemented in a silly way that is slower than np.trunc. On my ARM Mac, I measure a 50% slowdown compared with np.trunc on a million-element array of floats.
I don't know all the historical details, but np.trunc is the version that's been standardized by the array API consortium and is also the version that is implemented as a ufunc. IMO we should deprecate np.fix. See https://github.com/numpy/numpy/issues/30096 and https://github.com/numpy/numpy/pull/30098). A less intrusive change would be to make np.fix an alias for np.trunc, which would fix the performance issue but leave an API wart of having an alias in the top-level API. Ralf rightly pointed out ( https://github.com/numpy/numpy/pull/30098#pullrequestreview-3408343827) that np.fix does have substantial downstream usage and that a deprecation needs to go through the mailing list, so I'm raising this here. We will also keep the deprecation around for a long time, since there are likely unmaintained projects and scripts that use np.fix. We'll hold off on merging the PR until after NumPy 2.4.0 is released at the earliest to give downstream some time to adapt in the NumPy 2.5 cycle. If anyone raises objections here, we'll also hold off. -Nathan
_______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected]
