Closed gilgamec closed 7 months ago
I agree that this is a bit counterintuitive. Moreover, the slerp
function uses the opposite convention, where slerp a b 0 = a
and slerp a b 1 = b
.
Unfortunately, the lerp
function is pretty widely used, so I'd feel a bit remorseful about changing the convention all of a sudden. I'd say the best thing to do is to just document this.
I'd say the implementation is more than just counterintuitive, it's downright wrong. Like I said, every version I've ever used or could find does it the other way around; so if even the other interpolation function from linear
does it that way, I'd say it's clearly a bug and should at least be documented as such.
(I note both functions were written by @ekmett; maybe he has a higher purpose, but I'd guess the lerp
implementation is just a longstanding typo.)
Agreed. Can this not be made much clearer in the documentation?
I had some very jittery animations until I figured this out. It defies all my intuition to defined it this way!
This was a complete brainfart on my part. I'm surprised it has stood this long.
I'd be open to a major version bump and clear CHANGELOG entry and fixing this.
I've uploaded linear-1.23
to Hackage with a fix.
I guess I've never had occasion to use it, but I just noticed that
lerp
(inAdditive
) works the opposite way of any other lerp implementation I've seen. (A brief Googling supports this; see C++, GLSL, Unity, Processing.) I'd expect thatthat is, that
lerp 0 a b == a
andlerp 1 a b == b
, and that is the case in all other implementations. However, the implementation inlinear
is the opposite of this, i.e.lerp 0 a b == b
andlerp 1 a b == a
.Is this mismatch intentional? If so, can it be clearly documented? If not, might it be fixed? I understand that it's longstanding at this point, but maybe something can be done.