terrible lerp.cpp

template <class _Ty>
_NODISCARD /* constexpr */ _Ty _Common_lerp(const _Ty _ArgA, const _Ty _ArgB, const _Ty _ArgT) noexcept {
    // on a line intersecting {(0.0, _ArgA), (1.0, _ArgB)}, return the Y value for X == _ArgT

    const int _Finite_mask = (int{isfinite(_ArgA)} << 2) | (int{isfinite(_ArgB)} << 1) | int{isfinite(_ArgT)};
    if (_Finite_mask == 0b111) {
        // 99% case, put it first; this block comes from P0811R3
        if ((_ArgA <= 0 && _ArgB >= 0) || (_ArgA >= 0 && _ArgB <= 0)) {
            // exact, monotonic, bounded, determinate, and (for _ArgA == _ArgB == 0) consistent:
            return _ArgT * _ArgB + (1 - _ArgT) * _ArgA;
        }

        if (_ArgT == 1) {
            // exact
            return _ArgB;
        }

        // exact at _ArgT == 0, monotonic except near _ArgT == 1, bounded, determinate, and consistent:
        const auto _Candidate = _ArgA + _ArgT * (_ArgB - _ArgA);
        // monotonic near _ArgT == 1:
        if ((_ArgT > 1) == (_ArgB > _ArgA)) {
            if (_ArgB > _Candidate) {
                return _ArgB;
            }
        } else {
            if (_Candidate > _ArgB) {
                return _ArgB;
            }
        }

        return _Candidate;
    }

    if (isnan(_ArgA)) {
        return _ArgA;
    }

    if (isnan(_ArgB)) {
        return _ArgB;
    }

    if (isnan(_ArgT)) {
        return _ArgT;
    }

    switch (_Finite_mask) {
    case 0b000:
        // All values are infinities
        if (_ArgT >= 1) {
            return _ArgB;
        }

        return _ArgA;
    case 0b010:
    case 0b100:
    case 0b110:
        // _ArgT is an infinity; return infinity in the "direction" of _ArgA and _ArgB
        return _ArgT * (_ArgB - _ArgA);
    case 0b001:
        // Here _ArgA and _ArgB are infinities
        if (_ArgA == _ArgB) {
            // same sign, so T doesn't matter
            return _ArgA;
        }

        // Opposite signs, choose the "infinity direction" according to T if it makes sense.
        if (_ArgT <= 0) {
            return _ArgA;
        }

        if (_ArgT >= 1) {
            return _ArgB;
        }

        // Interpolating between infinities of opposite signs doesn't make sense, NaN
        if constexpr (sizeof(_Ty) == sizeof(float)) {
            return __builtin_nanf("0");
        } else {
            return __builtin_nan("0");
        }
    case 0b011:
        // _ArgA is an infinity but _ArgB is not
        if (_ArgT == 1) {
            return _ArgB;
        }

        if (_ArgT < 1) {
            // towards the infinity, return it
            return _ArgA;
        }

        // away from the infinity
        return -_ArgA;
    case 0b101:
        // _ArgA is finite and _ArgB is an infinity
        if (_ArgT == 0) {
            return _ArgA;
        }

        if (_ArgT > 0) {
            // toward the infinity
            return _ArgB;
        }

        return -_ArgB;
    case 0b111: // impossible; handled in fast path
    default:
        _CSTD abort();
    }
}

functions that you would expect to be simple (inner_product, etc)

inner_product is not a function where the "simple" implementation produces incorrect answers.

You don't think we could find inputs that would be incorrect? We would have to seek them out, but that's what has been done for lerp.
The end result of anticipating every possible misuse is it just won't be useful for anyone. Any implementation is a compromise compared to its theoretical design. As other posters have mentioned, who is this lerp for?

Let's assume you're right though. inner_product was just one example. I shared the link to show that the STL used to be extremely simple. It's doubtful ANY of the functions or data structures you find in the original STL are even close to as long or complex as the current standard library has made them. Can you find any of them which has become more simple in any major implementation?

The priorities are (1) correctness, (2) performance, (3) simplicity. The result of that is that simplicity goes down over time in favor of correctness or perf.

lerp got standardized precisely because a correct implementation is not simple. All the normal floating point rules already do the correct thing for inner_product (e.g. always take the leftmost NaN, raise the right floating point exceptions, don't accumulate rounding errors within the algorithm, etc.).

If you want the 'simple' one then go for it. The library function doesn't exist for you.

Correctness is relative to a domain. You can often get all three (correctness, performance, and simplicity) by constraining your domain to more reasonable inputs to avoid pathological results. For example, some may say code which is not threadsafe is not correct. You can resolve this by throwing locks on everything, or you can just declare that accessing it from multiple threads is incorrect. Could we accomplish the same with Lerp by specifying a reasonable domain instead?

If someone truly cared about performance they wouldn't be using the STL all over the place

Ah yes, great, if I cared about performance, I'd instead be reinventing my own wheels instead of standing on shoulders of giants, of course I would do that, such an amazing idea, surely one that works out just great for many people...

If someone truly cared about performance they wouldn't be using the STL all over the place

Ah yes, great, if I cared about performance, I'd instead be reinventing my own wheels instead of standing on shoulders of giants, of course I would do that, such an amazing idea, surely one that works out just great for many people...

This is more common than you think in high performance applications in the professional workspace. Look at Rad Game Tools for example.

But, I digress… I too enjoy using the STL as much as I can.

You can take your trolling elsewhere though, with all the sarcasm and such.

beautiful