Menu
▾
▴
#4676 Some math functions which are not documented
There are some math functions which aren't documented.
- make_elliptic_e, make_elliptic_f, jacobi_am, kelliptic
- hypergeometric_regularized, hypergeometric_u
- whittaker_m, whittaker_w
- inverse_erf, inverse_erfc
double_factorial(EDIT 2026-04-14: I pushed commit [ c31eeb6 ] which has documentation for double_factorial)- eulerpoly, cubrt
whittaker_m and whittaker_w are the same as %m and %w, respectively. There is documentation under the latter names.
Looks like there was an attempt some time ago to rename %m and %w but it was incomplete. Assuming we go ahead with that, then relabel the existing documentation to the new names.
I seem to recall EDIT 2026-04-14: I pushed commit [ c31eeb6 ] which merges double_factorial is not the same as the !! operator -- they handle different special cases, if I recall correctly. Probably should merge double_factorial into the simplification rules for !! and then nuke double_factorial. !! and double_factorial; the parser recognizes both in input and they produce the same type of expression, which is displayed as !!. This is analogous to the behavior of ! and factorial.
double_factorialis a more powerful function than!!.Unlike
!!,double_factorialbehaves likeFactorial2/!!from Mathematica - that is, it can also accept negative numbers as an argument, with the exception of negative even integers.double_factorialalso handles complex numbers correctly.I think nothing needs to be removed. Both
double_factorialand the!!operator should be kept. This is exactly the approach taken in Mathematica, for instance - not everyone prefers to use unary operators.Therefore,
double_factorialsimply needs to be documented, while the!!operator should be brought into conformance withdouble_factorial, not the other way around.There is a minor issue with the
inverse_erfandinverse_erfcfunctions. The problem is that Maxima is unable to simplifyinverse_erf(erf(x))andinverse_erfc(erfc(x))symbolically.Additionally, some problems arise when attempting numerical evaluation.
First, there is significant numerical error:
inverse_erf(erf(5)),numerevaluates to5.000004776115367.Second,
inverse_erf(erf(6)),numerandinverse_erfc(erfc(28)),numercannot be evaluated at all, since due to floating-point error the inverse functions receive1and0, respectively, as their arguments, at which point these functions are undefined.Accordingly, a way should be found to allow Maxima to simplify these expressions symbolically.
Last edit: RoyalX 2026-02-25
Thanks for looking at
erf/inverse_erf. The lack of a simplification rule is a feature request; I'll open a ticket for that.The numerical problems are, I believe, not bugs. Given that the argument to
inverse_erfis a floating point number, it is to be expected that the result will be inaccurate, given that the slope oferfis almost zero for large positive or negative values. For greater numerical accuracy, you might considerbfloatinstead offloat.I've opened ticket https://sourceforge.net/p/maxima/bugs/4690 to cover the problem about erf(inverse_erf(x)) not simplifying.