in fact, this has already been added for the next release, and is tentatively called relerp(). you can also undo a lerp() using the unlerp() function that appeared in 0119.

all that remains is making sure these are the names we want, and a final decision on the order of parameters. lerp uses:
float value = lerp(float start, float stop, float amount);
and then unlerp:
float amount = unlerp(float start, float stop, float value);
so relerp currently looks like:
float value = relerp(float fromStart, float fromStop, float value, float toStart, float toStop);

to do it again, we should've put the value in front as the first parameter for lerp().

well, i'm open to suggestions. we have three functions. first is lerp(), then a second that does the opposite thing (now called unlerp), then a third (which is being suggested here, and i currently have called relerp) which is identical to calling lerp() on the value produced by unlerp().

i'm concerned about "the opposite of lerp() is map()" not making any sense, though it would allow us to simply overload map() with two versions, one that takes the incoming low and high values, and a second that takes both incoming and outgoing ranges (as being suggested in the initial post).

// now called unlerp(), gives normalized value
// between 0 and 1 of "value" between fromLow and fromHigh
float map(float value, float fromLow, float fromHigh)

// remaps into another range
float map(float value, float fromLow, float fromHigh, float toLow, float toHigh)

with any luck, perhaps such functions are provided by other APIs and we can use their syntax..

eh, thanks for explaining the math to me, though i don't think that's the problem.

so instead, does it make sense to tell people "the opposite of lerp() is normalize()?" we have a function called lerp, and we need to add two cousins. my concern is how the function is taught, or when you're looking through the reference that does the opposite thing as your lerp() function, how would you find it.

i don't like "unlerp" or "relerp", which is why i said i'm open to suggestions, and neither function has been announced officially in revisions.txt or added to the reference.

so we have two suggestions so far, map() and normalize(). normalize() is of course what is technically happening, but it also means we'd need a third name for the function that was initially proposed. and i'm not nuts about having three functions, named lerp(), normalize(), and map(), that do almost the exact same thing but sound like they have nothing to do with one another.

Thanks Ben -- I'm just glad it's going to be included

This is how I imagine the troika:

[a,b]->[0,1] unlerp(x,a,b)
[a,b]->[c,d] relerp(a,b,x,c,d)
[0,1]->[c,d] lerp(x,c,d)

I think the main question is whether you want to rename lerp or not. If so, I see:

[a,b]->[0,1] mapToUnit(x,a,b)
[a,b]->[c,d] map(a,b,x,c,d)
[0,1]->[c,d] mapFromUnit(x,c,d)

If changing lerp's name is not an option... lerp/unlerp makes sense, but "relerp" makes me think of repeating the lerp operation. Maybe scaledlerp?

The only other place I know of a mapish function is max/msp; the object has inlets ordered [x a b c d]... but I think that's more max's style than any deep consideration.