Hypergeometric function naming

[andrjohns]

Description

We have some implementations of hypergeometric functions in the Math library (and more to come), that would be good to expose:

• 2F1: gradients partially implemented (#2663), values implemented in Boost
• 3F2: gradients and functions implemented in Math

I'm proposing that we use a consistent naming convention for these moving forward, matching that used by Boost: hyper_pFq. So the functions in the Math library would be named:

• hyper_2F1
• hyper_3F2

This would involve renaming the F32 function/header, but given that it's only internal at the moment I don't think it would be much of an issue

[spinkney]

Do you want to expose the grad_2F1 and grad_3F2 functions as well as hyper_2F1 and hyper_3F2?

[andrjohns]

I don't think we would expose the grad_ functions, since they would have to be rewritten or wrapped to be able to be used in the Stan language (since they currently overwrite their inputs rather than returning outputs). But that option is always there if there turns out to be enough demand for them

[betanalpha]

Given how obscure these functions will be for most users, in particular those who wouldn’t be common users of Boost, I would prefer to err on the side of redundancy and go with “hypergeo_pFq”.

To me “hyper” reads as too generic, especially when the Stan language doesn’t have namespaces to provide meaningful context like Boost.

Description

We have some implementations of hypergeometric functions in the Math library (and more to come https://github.com/stan-dev/math/pull/2510), that would be good to expose:

2F1: gradients partially implemented (#2663 https://github.com/stan-dev/math/issues/2663), values implemented in Boost 3F2: gradients and functions implemented in Math I'm proposing that we use a consistent naming convention for these moving forward, matching that used by Boost: hyper_pFq. So the functions in the Math library would be named:

hyper_2F1 hyper_3F2 This would involve renaming the F32 function/header, but given that it's only internal at the moment I don't think it would be much of an issue

[andrjohns]

I see what you mean. In that case it would probably better to be completely explicit: hypergeometric_pFq, since it's it not much more verbose