The rationale for the current names was to avoid hogging single letters and Greek letter names since the user may want to use them as variables. On the other hand, uppercase Pi, Gamma, Digamma, Beta and Zeta are not exactly commonplace variable names. E and I are much more questionable.
It's tempting to introduce aliases, but it's something I'd really prefer to avoid.
Next issue: distinguishing between numbers / polynomials / functions where names are overloaded. The Mathematica convention of Person + Symbol (like BesselJ) is nice, but hard to apply consistently (FibonacciF is ugly), and in any case not every function has a person's name associated with it).
I'm also leaning towards using separate symbols for generalizations (adding more parameters) of the same function. For example, Mathematica uses BernoulliB for both Bernoulli numbers and Bernoulli polynomials, but I think I'd rather have separate symbols.
This also ties into the question of Gamma and Zeta above: I'd rather not use the same symbol for the complete and incomplete gamma functions, and RiemannZeta is nice because there are multiple ways to generalize this function to several variables (HurwitzZeta, MultiZetaValue, ...).
Derivatives: some functions currently take an optional extra parameter to denote differentiation with respect to the "main" variable (which is the main variable depends on each function). Possible alternatives:
Being strict about the number of parameters for normal functions, and adding separate differentiated versions of functions (BesselJDerivative, etc.). The only drawback is that it introduces a lot of symbols...
Some kind of special expressions for derivatives: something like BesselJ(n, DerivativeOrder(z, 1)) or BesselJ(n, z, DerivativeOrder(1)) or BesselJ(n, z, DerivativeOrder(0, 1)). "Systematic" but ugly.
Similarly with non-principal branches: LambertW currently takes two parameters (or three for a derivative); these should perhaps be LambertW and LambertWBranch instead. What about other functions with branch cuts? What about analytic continuation paths? There is now a special Path object; one idea is to allow LambertW(Path(0, -ConstI, -1)) to represent an analytic continuation.
Miscellaneous bikeshedding design issues. Comments are welcome.
The rationale for the current names was to avoid hogging single letters and Greek letter names since the user may want to use them as variables. On the other hand, uppercase
Pi,Gamma,Digamma,BetaandZetaare not exactly commonplace variable names.EandIare much more questionable.It's tempting to introduce aliases, but it's something I'd really prefer to avoid.
Next issue: distinguishing between numbers / polynomials / functions where names are overloaded. The Mathematica convention of
Person+Symbol(likeBesselJ) is nice, but hard to apply consistently (FibonacciFis ugly), and in any case not every function has a person's name associated with it).I'm also leaning towards using separate symbols for generalizations (adding more parameters) of the same function. For example, Mathematica uses
BernoulliBfor both Bernoulli numbers and Bernoulli polynomials, but I think I'd rather have separate symbols.Currently (not very consistent):
Alternatives:
This also ties into the question of
GammaandZetaabove: I'd rather not use the same symbol for the complete and incomplete gamma functions, andRiemannZetais nice because there are multiple ways to generalize this function to several variables (HurwitzZeta,MultiZetaValue, ...).Derivatives: some functions currently take an optional extra parameter to denote differentiation with respect to the "main" variable (which is the main variable depends on each function). Possible alternatives:
BesselJDerivative, etc.). The only drawback is that it introduces a lot of symbols...BesselJ(n, DerivativeOrder(z, 1))orBesselJ(n, z, DerivativeOrder(1))orBesselJ(n, z, DerivativeOrder(0, 1)). "Systematic" but ugly.Similarly with non-principal branches:
LambertWcurrently takes two parameters (or three for a derivative); these should perhaps beLambertWandLambertWBranchinstead. What about other functions with branch cuts? What about analytic continuation paths? There is now a specialPathobject; one idea is to allowLambertW(Path(0, -ConstI, -1))to represent an analytic continuation.Trivial things:
for consistency with the other operators (or the other way around)
Also:
Other functions:
Not really a naming issue; should the argument be m or k? Separate functions?