Open lydia-duncan opened 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.
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
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 use
s rather than import
s 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.
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.
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]
I think we're not going to do this, based on the discussion, so I'm just going to close the issue
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)
The names for these functions lack outside context and are very short - I propose renaming them in the following way:
The documentation should use the old names, in case a user is searching for them based on that name.