It would be great to have the bessel functions available in the math module.
Seems like this should be fairly easy to add -- a good c2chapel test?
@bradcray - were you thinking of using c2chapel to wrap GSL's Bessel functions?
That's what I thought we'd need to do at first, but then I started to convince myself that they may simply be in -lmath based on https://www.gnu.org/software/libc/manual/html_node/Special-Functions.html and the man page on my Mac. Granted, it was early in the morning, though.
Hello, may I start contributing in making Bessel function, it would be my first contribution in Chapel, and as per CONTRIBUTING.md, I sent my details of CLA and Github ID, please provide me some guide if I鈥檓 struck.
@nimitbhardwaj : I don't believe anyone currently owns this and we'd be happy to have you work on it if you're able. Definitely give a shout if you have any questions (here or on IRC or email). Thanks!
OK, thanks, I am working now
One more thing, as in previous comment, should I use c2chapel or have to implement them from scratch, as they are already there by GNU, we can use them, but the concern that they are in -lmath, I didn't get it much.
should I use c2chapel or have to implement them from scratch, as they are already there by GNU, we can use them, but the concern that they are in -lmath, I didn't get it much.
I would use c2chapel to wrap the routines in math.h, which includes j0, since Chapel compiles with -lm by default.
Here's a simple example of what c2chapel might generate for float j0(float x):
extern proc j0(x: real(32)): real(32);
An open question: Do we intend to provide all of math.h functionality in Math.chpl, or just add the bessel functions requested in this issue?
You've both used -lmath in your text, but do you mean -lm (and math.h)?
Do we intend to provide all of -lmath functionality in Math.chpl, or just add the bessel functions requested in this issue?
For this issue, let's start with the Bessel functions, but I think a broader review of what we're missing is probably in order as well.
I forgot about the fact that the bessel functions have such commonplace names relative to variable names that users might use for variables. That may be part of the reason we skipped over them the first time around. If Python or other libraries suggested names that might be more descriptive, we might consider using them. Hopefully even names like j0 won't cause problems if we've got our scoping rules correct, though.
You've both used -lmath in your text, but do you mean -lm (and math.h)?
Whoops . Corrected my comment above.
If Python or other libraries suggested names that might be more descriptive, we might consider using them
Python uses the same names. It appears this naming schemes is fairly standardized, and it would be unfortunate to steer too far away from it. Some languages use a bessel prefix - that seems like a good option.
OK, I think if C and Python both use those names, we should too. If it breaks existing code (I've got to think we have code that uses those variable names), that'll be worth understanding better. Again, my hope is that our scoping rules will be such that it doesn't. If it does, we could consider pushing them into a non-auto-used Bessel module or sub-module.
Oks, got it and make the PR correct
Most helpful comment
OK, I think if C and Python both use those names, we should too. If it breaks existing code (I've got to think we have code that uses those variable names), that'll be worth understanding better. Again, my hope is that our scoping rules will be such that it doesn't. If it does, we could consider pushing them into a non-auto-
usedBesselmodule or sub-module.