Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
casevh opened this issue Mar 20, 2023 · 3 comments
Closed

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

casevh opened this issue Mar 20, 2023 · 3 comments

Comments

@casevh
Copy link
Collaborator

casevh commented Mar 20, 2023

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Collaborator Author

casevh commented Oct 4, 2023

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.

@casevh casevh closed this as completed Oct 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants