I've wondered the same thing myself. They're probably easier to standardize since the specification for that behavior is already done by mathematicians. And the implementation is generally re-entrant so the possibility of show-stopper design bugs is minimal.

Getting concepts wrong, in contrast, has a much larger downside.

Not saying special maths should be standardized. Just attempting to describe the phenomenon.

Library implementors would have to implement it. Most of them are probably unqualified to do it, so they'll probably just grab Boost's implementation. And Boost's implementation would be unreadable to most implementors. Thus everyone would get a slightly subpar implementation, because most numerical researchers are not keeping an eye on Boost and making sure it has the best methods available. The end result is that those in the know will avoid the C++ stdlib, just like Qt did and reimplemented strings and maps.

We've seen this problem before with valarray and with export. There is a problem with standardising something that nobody wants or nobody can implement correctly.

For example, if you want to implement a Student's t-test, you soon will run into the problem that you want to have a Beta function or the gamma function.

One could probably copy-paste a somewhat working version together from search engines, add asserts to prevent me from ever calling them with arguments out of the range where it seems to work, but for most of us, the result likely will be slower and less precise than a version that gcc, clang, or commercial compilers would provide.

And yes, I could probably buy an implementation somewhere, but in the real world, that often isn’t a real option, and even then, I wouldn’t know how well it worked, either.