> It is not part of the core library. It is certainly not meant as a reference-level implementation of math functions. It's there so you can write an easing function for a game without pulling in libc.

I saw the note and ignored it because it's not actually a repackaging of HHM. It simply happens to define a few vaguely similar functions. It doesn't reuse the naming conventions (MulVec3f vs vec3_scale), it doesn't reuse the interface (see SP_MATH_IMPLEMENTATION), and it's missing genuinely useful bits like the matrix functions.

Moreover, the quality of what's been added is significantly worse. Look at sp_sys_expf:

    f32 sp_sys_expf(f32 x) {
      f32 result = 1.0f;
      f32 term = 1.0f;
      for (int i = 0; i < 20; i++) {
        term *= x / (f32)(i + 1);
        result += term;
      }
      return result;
    }

I can't imagine a good reason why anyone (even an LLM) would ever write a 20th order taylor series for expf. A single FMA can improve on this and have capped relative error to boot, and that's not even a good way to do it. See what happens with your function at +-10 for comparison. At the f32 limit of 88, you achieve an honestly impressive 100% relative error.

Also, because sp_math doesn't use FMAs, your library isn't reproducible. Different compilers will produce different values. Reproducibility is a pretty nice property in games.

I don't like that slopcode angle either, but unfortunately I have to say that you do have picked a wrong library to bundle. For example, it's almost likely that there is a correct (not just accurate enough, but correct) implementation of sqrt in your CPU because IEEE 754 mandates that. Unless you're doing softfloat you simply want to wire it via asm.