chapel-lang / chapel

a Productive Parallel Programming Language
https://chapel-lang.org
Other
1.78k stars 418 forks source link

Math module - Rename Bessel functions #19051

Open lydia-duncan opened 2 years ago

lydia-duncan commented 2 years ago

The names for these functions lack outside context and are very short - I propose renaming them in the following way:

old name new name
j0 firstBesselOrder0
j1 firstBesselOrder1
jn firstBesselOrderN
y0 secondBesselOrder0
y1 secondBesselOrder1
yn secondBesselOrderN

The documentation should use the old names, in case a user is searching for them based on that name.

bradcray commented 2 years ago

My standard question: What do other modern Math libraries (for languages we care about) call these? If the short names are what everyone expects, I'd keep them (and having them be in a non-auto-used module makes that seem less bad). If modern convention has gone to other/longer names, that sounds good to me as well.

lydia-duncan commented 2 years ago

Python's SciPy library uses these names, but puts them in a special module (literally scipy.special).

C uses those names, and gcc includes them by default, which caused a user on stackoverflow to run into problems when they tried to define a variable with the same name (more a problem for the y variants than the j variants, as y is frequently used in other scenarios).

Rust puts its Bessel functions in their own library but also uses a variation of the same name (Y0 rather than y0 but still j0, maybe due to y0 being something users would type regularly?)

I can go look at other languages, but it seems pretty unified thus far

bradcray commented 2 years ago

Yeah, this suggests to me that we should probably stick with the current names, and that making them not be auto-available would reduce chances of confusion. We wouldn't have the C/gcc problem because of not having a global flat namespace, so the worst case here (I think) would be a user who uses rather than imports Math; thinks they've shadowed one of these routines, but has failed to for some reason; and then tries to refer to their shadow variables but gets these instead.

lydia-duncan commented 2 years ago

Do you think it would be worth putting them in their own special submodule as well? It'd only be the six of them so far as I know, but 6 isn't too few and it did seem like there were other ones that could be added later if someone missed them.

bradcray commented 2 years ago

I probably wouldn't personally, unless we did that for more Math routines in general or saw an inherent problem with keeping them in Math (I don't really, particularly in a non-auto-use world).

[edit: Or there's some other rationale for it that I'm missing]

lydia-duncan commented 1 year ago

I think we're not going to do this, based on the discussion, so I'm just going to close the issue

lydia-duncan commented 1 year ago

On the tgamma/lgamma issue (#19022), Damian indicated that he'd like us to think a bit more about the names of these functions and potentially their location. Reopening, but removing the 2.0 label as we're planning on marking them unstable for 2.0 and discussing after that (given how soon the 2.0 release candidate is approaching)