``invlerp`` and ``remap`` implementation

[bilhox]

trafficstars

Implementation of #2649 Docs will come in a short time.

[bilhox]

I don't think you should change anything about math.lerp in this PR, you can submit a separate PR for that (that includes both the implementation and the docs).

It's because I had to use lerp and invlerp in remap, So I updated it. Technically I can make python calls. Should I point it out btw ?

[Matiiss]

I don't think you should change anything about math.lerp in this PR, you can submit a separate PR for that (that includes both the implementation and the docs).

It's because I had to use lerp and invlerp in remap, So I updated it. Technically I can make python calls. Should I point it out btw ?

I'm just saying to not touch math_lerp in this PR, you can submit another PR that implements the changes in math_lerp using your helper functions and the change in the docs (although the docs change can maybe stay here, but if you're gonna submit another PR for math_lerp, might as well move that change to there too).

Also, not sure how much it really matters, but you could inline those two helpers, perhaps.

[bilhox]

LGTM 🎉 If you want to, you can implement Ankith's suggestions, but otherwise it seems to be functionally fine. It is failing one of the CI runs though and as far as I can tell, you'd just need to rebase this branch on top of main and that should fix that I hope.

There is one thing I didn't understand from what ankith asked me to do, and with my exams I didn't have time sorry. Anyways, if you can explain me how to specificly now which variable is incorrect, rather than copy/pasting the error condition.

[Matiiss]

There is one thing I didn't understand from what ankith asked me to do, and with my exams I didn't have time sorry. Anyways, if you can explain me how to specificly now which variable is incorrect, rather than copy/pasting the error condition.

Good question, one approach would of course be a macro that does that, just add it after every double conversion and give it the argument number or name or whatever and make it just add the error message with that name in that place using the macro (make sure you undef it after usage). I guess another approach is a function, but that seems somewhat unnecessary for this. So yeah, probably a macro if you want to do that.

[Starbuck5]

Why is this implemented in C?

[MyreMylar]

Why is this implemented in C?

Why not? I think for this current PR it would be a bit awkward & somewhat confusing to have 90% of the current math library in C and just two functions not written in C. It is a worthwhile question to ask though and I would like more of pygame's code to be written in python.

If you are pondering re-implementing the whole of pygame.math in python then that would be interesting to see how the current speed of python 3.12 stacks up against C implementations.

[Starbuck5]

Why not?

Because bigwhoop's feature request had the functions written in Python. It would be trivial to just monkey patch them in in __init__.py.

Less code on our end, might even be more performant.

[MyreMylar]

Why not?

Because bigwhoop's feature request had the functions written in Python. It would be trivial to just monkey patch them in in __init__.py.

Less code on our end, might even be more performant.

I'd like to see a pull request like this - both to see how it looks as an example case, and to see some performance testing. I think performance is definitely relevant for a math function like this that could be called repeatedly in tight loop drawing code.

[ankith26]

Here is a simple performance test script for testing the invlerp implemented here

import pygame
import random
import time


use_python = False

objs = [
    (
        random.uniform(-100, 100),
        random.uniform(-100, 100),
        random.uniform(0, 1),
    )
    for _ in range(5000)
]

def py_invlerp(a, b, v, /):
    return (v - a) / (b - a)


start = time.time()

if use_python:
    for arg in objs:
        py_invlerp(*arg)


else:
    for arg in objs:
        pygame.math.invlerp(*arg)


print(time.time() - start)

I'm on python 3.12 and the C version implemented in this PR is more performant than the python version. However, at the rate at which the language is evolving (with the jit compiler and stuff), the difference is only going to lessen over the years, seems like.

On this specific case, I still would support the C implementation because it is simple enough, and if we ever decide to do a python re-implementation: it's a one-liner.

[bilhox]

I highly believe that at this stage of implementation, and because the rest of math lib is written in C, that we keep this implementation.