# remove \`math.lerp\` bounds for t · gitcafe/zig

[View on GitCafe](https://git.cafe/gitcafe/zig/commit/7a858257f2c05f0ab8df0debda9f1d58b5ecf251)

Repository: [gitcafe/zig](https://git.cafe/gitcafe/zig)

Visibility: public

Requested revision: 7a858257f2c05f0ab8df0debda9f1d58b5ecf251

Requested commit: 7a858257f2c05f0ab8df0debda9f1d58b5ecf251

Commit: 7a858257f2c05f0ab8df0debda9f1d58b5ecf251

Tree: fd97c46a20905ce449c5ef6f99931a9974ba995f

Author: pancelor

Committer: Andrew Kelley

## Message

```
remove `math.lerp` bounds for t

I think of lerp() as a way to change coordinate systems, essentially
remapping the input numberline onto a shifted+rescaled numberline. In
my mind the full numberline is remapped, not just the 0-1 segment.

An example of how this is useful: in a game, you can write:
`myPos = lerp(pos0, pos1, easeOutBack(u))`
for some `u` that changes from 0 to 1 over time.
(see https://easings.net/#easeOutBack)
This will animate `myPos` between `pos0` and `pos1`, overshooting the
goal position `pos1` in a nicely-animated way.
`easeOutBack(float)->float` is a pure function that overshoots 1,
and by combining it with `lerp()` we can remap coordinates in other
coordinate systems, making them overshoot in the same way.

However, this overshooting is only possible because `easeOutBack(t)`
sometimes exceeds the range 0-1 (e.g. `easeOutBack(0.5)` is 1.0877),
which is not allowed by the current `math.lerp` implementation.

This commit removes the asserts that prevented this use-case. Now, any
value can be inputted for t. For example, `lerp(10,20, 2.0)` will now
return 30, instead of throwing an assert error.

```

## Parents

- [ea8e9e668b8b566a94e8d69476d392458918382a](https://git.cafe/gitcafe/zig/commit/ea8e9e668b8b566a94e8d69476d392458918382a?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zig/tree/7a858257f2c05f0ab8df0debda9f1d58b5ecf251?format=markdown)