Thanks Robert, really appreciate it!

On Thu, Aug 24, 2023 at 12:19 Robert Kern <> wrote:
On Wed, Aug 23, 2023 at 10:06 PM Bao Guo <> wrote:
I am writing to seek clarification on the specific differences between the numpy.trunc() and numpy.fix() functions.

I have come across opinions stating that these two functions exist for backward compatibility and that they serve different functional requirements. However, I am puzzled as to why these functions could not be merged or one of them upgraded to encompass both functionalities. Despite my efforts in researching and contemplating on this matter, I have not come across a convincing explanation.

Could anyone kindly shed some light on this matter? I am seeking a deeper understanding of the design choices made for these functions and the rationale behind their coexistence.

Thank you in advance for your time and assistance.

`fix()` was added to numpy back in the super-early days when it was emerging from Numeric, its earlier predecessor. It was named after the equivalent MATLAB function.

At some point thereafter, we settled on a policy for inclusion of mathematical ufuncs into numpy. We got tired of arguing whether a special function was "important enough" to be in numpy instead of scipy.special. Eventually, we settled on a bright line that if a math function was in the C99 standard, we'd go ahead and allow a ufunc for it in numpy. `trunc()` is the name of that equivalent function in the C99 standard. It is a ufunc instead of a plain function like `fix()` and has a (strict, I believe) superset of functionality. You can ignore `fix()`, more or less. I'm not sure if it's on the list for deprecation/removal in numpy 2.0, but it certainly could be.

Robert Kern
NumPy-Discussion mailing list --
To unsubscribe send an email to
Member address:
Sent from Gmail Mobile