John D. Cook at The Endeavour writes Math library functions that seem unnecessary, in which he gives examples of functions in the standard C math library that seem unnecessary at first glance, and the special cases that make them indispensable….

Ruben

For it to matter if the log of 1.000000000wheeeeeee16 is correct or an error makes me feel like an innumerate old man.

* There may be differences in performance, because one has more patches than the other. If you add additional patching, you’re making the situation worse than either option.

* That “for the same input” caveat is really the key here. Because floating-point numbers are discrete and unevenly spaced, you CAN’T give them the same input. In particular, if X is 1 + 1e-57, you can pass 1e-57 to log1p, but you can’t pass 1 + 1e57 to log — the closest available floating-point number you can pass to log is just 1. The accuracy distinctions are entirely about the input that you give to the functions, and have nothing to do with the internal function implementation itself.

Thus, you want to use log1p() for numbers very close to 1 that can’t be accurately represented directly — but if, and only if, your algorithm is already designed to compute and store them as offsets from 1 rather than storing them directly (i.e., as offsets from 0). If you are storing those inputs directly, you gain nothing from writing things as log1p(x – 1), because your algorithm has already lost the any extra precision of those inputs it might have had in computing and storing them that way. If x is already rounded to 1 rather than a conceptual representation of 1 + 1e-57 (where the “1 +” is implied and only the 1e-57 is stored in the variable in memory), then subtracting 1 from it gets you 0, not 1e-57, and using log1p is no help at all.

I suspect lgamma is implemented a little differently than log(tgamma(x)), as tgamma doesn’t have enough precision.