This seems great. Can you explain a bit the justification of the specific set of values proposed? e.g., why sqrt(pi)?

1/π and √π are needed to, say, normalize the Fourier coefficients and the Fourier Transform — for the latter, actually 1/√(2π) but I did not want to add to many constants (maybe a separate √2 is useful?).

Another thing to possibly discuss: I used names with underscores — as I find them clearer — but √π is sometimes written sqrtpi.

BTW, shouldn't these use the hexadecimal float notation that was added recently? I think it's supposed to be more reliable

1/π and √π are needed to, say, normalize the Fourier coefficients and the Fourier Transform

Okay, but why can't they be computed when needed? Are they needed so often that avoiding the computation is worthwhile from a performance perspective? Or is there some numerical sensitivity issue you're accounting for that makes it better to give the exact values you provide?

@diml One can hope that the compiler does a correct rounding when parsing numbers but maybe you would like to add some tests? Using the hexadecimal notation in the library itself will make it work only for recent versions of OCaml or require conditional code.

Base already requires OCaml >= 4.03. I didn't check but I'm pretty sure we are already using 4.03 specific features in Base. So it's not really a problem to require support for the hexadecimal notation.

@Chris00 Is pi_2 really better than pi /. 2.? The meaning of the former is unclear from the name (pi_over_2 would be clear enough, but now clearly less concise).

sqrt_pi is clear, but no clearer than sqrt pi. Similarly, inv_pi is clear, but not obviously better than 1. /. pi. Is the motivation for these more about precision or performance? Certainly division and sqrt are expensive operations.

sqrt_pi in indeed slightly more precise (sqrt_pi -. sqrt pi ≈ 2.22e-16) and less costly (but of course, one can always declare it in a given module). So the reason for √π is mostly precision [with it, sqrt 2. *. sqrt_pi gives the best approximation of √(2π) — I just checked and sqrt 2. *. sqrt pi works as well, but not sqrt(2. *. pi)].

So maybe it is better to add sqrt_2pi instead of sqrt_pi.

It's also maybe worth looking at other places for prior art. Here's the list of constants from boost, C# and glibc.

http://www.boost.org/doc/libs/1_46_0/libs/math/doc/sf_and_dist/html/math_toolkit/toolkit/internals1/constants.html
https://msdn.microsoft.com/en-us/library/4hwaceh6.aspx
http://www.gnu.org/software/libc/manual/html_node/Mathematical-Constants.html

See also the GSL.

See also Gg.

Please also see Richard Jones's comment in https://caml.inria.fr/mantis/view.php?id=4170

Sorry for letting this hang out for so long. I'm pushing this through our internal process.

(Edited in response to question below.)

One can hope that the compiler does a correct rounding when parsing numbers but maybe you would like to add some tests?

This was my thought as well, but it appears that decimal numbers are not reliably rounded correctly. The problem is that caml_float_of_string uses C's strtod, whose correctness is platform-dependent. Googling strtod implementations, the first one I found had this comment: "If the mantissa has more than 18 digits, ignore the extras, since they can't affect the value anyway." (That's untrue for numbers that are close to halfway between representable values.) On my own machine, about 1 in 50,000 values gets rounded the wrong way. The concern for me is the not the negligible loss of precision but the nondeterminism that comes from different machines having versions of strtod that disagree about the mapping of strings to doubles. (Thankfully the scope of this problem is pretty narrow, because presumably they do agree about how to round strings that result from converting a double to a string.)

@cshardin You are speaking of decimal representations, right?

This has been released internally, and will land in the next bleeding-edge release.