std::lerp?

[Nico Weber]

Hi,

The "C++20 is now allowed in Chromium" email says "we are allowing a significant number of features immediately [...]: std::lerp and std::midpoint".

Is there a discussion of these particular functions that I could read?

It is my (surface-level) understanding that std::lerp is kind of the std::unordered_map of lerps: Specced to behave well on all kinds of corner cases, but that also means the implementation is more complex (and slower) than the `a + (b - a) * x` (or `a * x + b * (1 - x)`? :P) you often want.

Here's the libc++ implementation: https://github.com/llvm/llvm-project/blob/main/libcxx/include/cmath#L789-L799 It's "just" 10 lines, but it's quite a few conditionals.

Here's the MSVC STL implementation, at a bit over 70 lines: https://github.com/microsoft/STL/blob/46843b3bf320c6070ff63e978936bcf898e5a2bc/stl/inc/cmath#L1392-L1465 (Granted, we don't care about the MSVC STL.)

Sometimes we want all the corner case handling, but often we don't.

Maybe it makes sense to have a recommendation similar to std::unordered_map, along the lines of "don't default to std::lerp"?

Often it won't matter either way, but the C++20 email suggested animation systems where we might call the interpolation function often, and for many values.

Nico

1: Vaguely lerp-shaded code snippets, often just inline:

https://source.chromium.org/search?q=%5CS%2B%5C%20%5C%2B%5C%20%5C(%5CS%2B%5C%20-%5C%20%5CS%2B%5C)%5C%20%5C*%5C%20%5CS%2B;%20-file:third_party&sq=&ss=chromium%2Fchromium%2Fsrc

https://source.chromium.org/search?q=%5C%2B%5C%20%5CS%2B%5C%20%5C*%5C%20%5C(1%5CS*%5C%20-%5C%20%5CS*%5C)%20-file:third_party&ss=chromium%2Fchromium%2Fsrc

https://source.chromium.org/search?q=%5C(1%5CS*%5C%20-%5C%20%5CS*%5C)%5C%20%5C*%5C%20%5CS%2B%20-file:third_party&ss=chromium%2Fchromium%2Fsrc

[Peter Kasting]

We didn't discuss lerp deeply.

I'm skeptical that the extra code to handle corner cases would ever result in noticeable perf loss. If, for example, you're using it in animation and calling it several times in a 60 hz callback, any additional overhead will be unnoticeable. Plus, if the overhead is conditionals to check for edge cases, they'll be branch-predicted correctly.

On the flip side, we have certainly had UI bugs that came from oversimplified lerp implementations that didn't handle past-the-end values and the like.

PK

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CADZ1XiYgQSCg9mtQ7CcqQu2fvt%3Db%2BvYaEXT7qAuN8JsEtBJ-1Q%40mail.gmail.com.