aleaxit / gmpy

General Multi-Precision arithmetic for Python 2.6+/3+ (GMP, MPIR, MPFR, MPC)
https://gmpy2.readthedocs.io/en/latest/
GNU Lesser General Public License v3.0
513 stars 87 forks source link

Argument order yn() and jn() inconsistent with MPFR and mpmath #401

Closed casevh closed 11 months ago

casevh commented 1 year ago

The order of the arguments to the gmpy2 functions yn() and jn() are (mpfr, order_of_Bessel_function). Both MPFR and mpmath use (order_of_Bessel_function, mpfr).

Is this worth changing and risk breaking existing code?

Replace them with besselj() and bessely() to match mpmath?

Open to any other ideas.

skirpichev commented 1 year ago

Both MPFR and mpmath use (order_of_Bessel_function, mpfr).

Also, e.g. Mathematica, maple, matlab, libm's extensions. Almost anywhere.

Is this worth changing and risk breaking existing code?

Uneasy decision. On one hand, people could read the documentation. On another hand, the gmpy2 is a wrapper to the MPFR. Then, probably it should follow to conventions of MPFR interfaces (function names, argument order, etc). Also, people could expect usual mathematical conventions for gmpy2 functions (and the current for jn/yn() is very unusual).

I'm +0 for changing (ditto for other similar cases).

Replace them with besselj() and bessely() to match mpmath?

No, as the gmpy2 is not an interface to the mpmath.

skirpichev commented 11 months ago

Perhaps, this should be closed with 175fa58, @casevh? Or do you like to provide some smooth transition to deal with the backward compatibility? BTW, in some sense the former behaviour could be considered as a bug...

casevh commented 11 months ago

I will close it. I consider the previous behavior a bug.

I detect the use of (mpfr, int) as the old calling convention and raise an error that states the argument order has changed. This should catch all uses of the old convention except if both arguments are integers.