Arrgh! I only coded the complex versions of sinc and sinhc!
:-) It happens.
I will look at your implementation tomorrow, but I feel it would perhaps be simpler to replace my files with yours or merge the implementations (specialization for scalars and specialization for complexes), and update the library documentation. I'd also like to add valarray support, at least for the scalars (pending the language decisions concerning layout guaranties), at some point, though rereading the discussion of two years ago this may prove contentious.
At any rate, I believe this is an enrichment of an existing, accepted, library, and as such does not warrant a separate review. Adding valarray support might warrant one, though, since there has been controversy (and thus the opportunity for improvement thru review).
OK, since my implementations are strictly complex number only, yours would still be needed for reals. BTW, I haven't implemented asinh/acosh as such: these are trivial variations of asin/acos (which are implemented). Just to be different, atan is a trivial variation of atanh: C99 expressed the relationship this way around, so I just followed.
I do not have institutional free access from my "beloved workplace" (grumble...).
No nor do I, but I've used this authors work before, and the current exchange rate makes ACM access not too painful...
Any others? You've got my curiosity roused...
In the stopgap series of implementations that my "special functions library" is, I would have simply used a succession of truncated series expansion, at least near zero (like I did for the various other functions), and then rely on whatever exponential function was coded in the user's platform's standard library.
Yep, that's easy enough: take a look at my log1p: the series evaluation is all boilerplate, so doing the same for expm1 is just a case of writing a short function object that calculates successive terms each time it's called. John.