These are likely going to introduce more imprecision than necessary.

LOGV is 0.693161 which is meant to be the nearest to the infinitely precise abs(log(0.5)), but with a touch of imprecision that accounts for the rounding error over the entire set of logic. HALFV is likewise 1 and INVV2 is likewise 0.25, both with a touch of explicit imprecision.

This comes from the actual algorithm where cosh(x) is (e^x + e^-x) / 2 or ((e^(2 * x)) + 1) / (2 * e^x) or (1 + e^(-2 * x)) / (2 * e^-x). All of this can simplify down to e^(|x| + log(0.5)) + 0.25 / e^(|x| + log(0.5)), i.e. the algorithm used here.

AOCL LIBM doesn't provide an official vectorized implementation for double, unfortunately, so we'd have to compute the correct adjustments ourselves. Short of that, simply using 0.6931471805599453, 1.0, and 0.25, is the next best thing and will be the closest to correct for us.

The actual logic used to pick these constants requires us to consider that for the infinitely precise logv, the nearest representable float (0.693147182464599609375) is off by approx 0.000000001904654299958.

The used LOGV value used for float ends up picking 0.63161f which is off by 0.0000138301822422 instead (note that this is part of the imprecision we then see in HALFV).

The used value for HALFV is then off by 0.000000001904654309375 from the infinitely precise 1.0000138301822422 (note that this is roughly the value that the defined LOGV is off by).

For INVV2 it picks 0.24999309 which is off from 0.25 by 0.0000069141387939453125, I've not done the work to figure out this where this adjustment factors in yet as I've been helping on a few other issues.

Thanks. Meaning I should just update them to 0.6931471805599453, 1.0, and 0.25, right?

Yeah, for now. I'll work on finishing figuring out the adjustment factor for 0.25 and then get then adjust to the "proper" values for double later.