Draft: remap implementation in std library

[Sparsh-N]

Description

Work in progress PR. Aims to resolve #1899

Some questions I have regarding implementing it are:

• To be added to the std lib, do I need to write for all types (normal, point, color)? Currently only have float and vectors types written.
• In case the combination of mix/unmix is used to implement remap (which I've seen is elsewhere, at least in many gamedev tutorials where remap is a lerp(inverseLerp()) call), does a separate unmix method need to be added to OSL or is there a easier way to complete it?
• From the documentation of efit in VEX https://www.sidefx.com/docs/houdini/vex/functions/efit.html, there's also a method signature which takes in 2 floats as the bounds for the 'new' range, while taking vectors for all other values. Should this also be added to the std library (or documentation)?

Thanks!

[Update]
I'll be keeping a changelog of the issue here as I go along with it. So far, I've implemented a inverseLerp/unmix method, although there's some changes missing. I'll get unmix working with tests before moving onto the full remap() implementation.

Tests

Haven't added any tests currently, will add more once the method is complete. To my understanding the tests would be in
/testsuite/remap-reg folder

Checklist:

• I have read the contribution guidelines.
• I have updated the documentation, if applicable.
• I have ensured that the change is tested somewhere in the testsuite (adding new test cases if necessary).
• My code follows the prevailing code style of this project. If I haven't
  already run clang-format v17 before submitting, I definitely will look at
  the CI test that runs clang-format and fix anything that it highlights as
  being nonconforming.

[lgritz]

Are you planning to come back and finish this?

[Sparsh-N]

I've been trying to attend one of the TSC meetings to ask these questions regarding the implementation, but there's often a overlap with a class in university. I'll send the questions posted in the slack channel in case anyone's suggestions there would be of help.

For the time being, I'll try getting a remap implementation working as described in the initial issue, and from there can add to this PR other compiler optimizations mentioned in the discussion.

[lgritz]

Please note also that I just merged a PR that removed the .tex files for the old LaTeX documentation, which is no longer used. The right place to document library functions like this are in src/doc/stdlib.md.

Feel free to ask questions on the slack, on the mail list, or here in the discussion for your PR. Especially if you have schedule conflicts, there isn't really any need to come to the biweekly meetings just to ask a small question about the code (in fact, questions about code are almost always better asked as text rather than voice, where it's hard to pose exact problems and give code solutions by just talking).

[lgritz]

I would just keep these definitions where it's implemented in OSL, and remove the ones where it's marked BUILTIN (which is a lot more work for you to implement, with little evidence so far that it would be helpful).

Also, you don't need to assume x != y, division by zero is defined to be safe in OSL. (It may be nonsensical to call unmix under such conditions, however, but you get what you deserve if you do so.)