Adding math.dist()?

[FoamyGuy]

I wondering if there is interest in having an math.dist() (CPython ref: https://docs.python.org/3/library/math.html#math.dist) in the core?

I had a try at implementing it in this branch: https://github.com/FoamyGuy/circuitpython/tree/math_dist. It only supports 2D, whereas the CPython one seems to allow higher dimensions, and I have done only some minimal "happy path" testing, but it does seem to work correctly and mostly match CPython results with the points I've tested.

I started with this issue instead of opening a PR directly because I was unsure of the following:

1. to gauge whether there is interest in this and

2. if so to ask if the way that I did it (adding the new implementation into shared-bindings/math/__init__.c) The math module doesn't seem to exist in shared-module most of the functions appear to just map directly to C functions pretty closely, the few that do have additional code are inside of shared-bindings/math/__init__.c so I followed that.

3. Should this be part of the MICROPY_PY_MATH_SPECIAL_FUNCTIONS? I did put it inside of the if blocks currently. My thought was to try to limit it to not be included on any devices that might be especially tight on firmware space, but I don't know if this flag is actually used for that purpose for certain.

[FoamyGuy]

I have learned about an alternative way to calculate euclidean distance from here: https://stackoverflow.com/a/1401828/507810 This one uses numpy.linalg.norm which it turns out that we already have access to by way of ulab

The syntax to use it is a bit different, needing you to create two numpy arrays, so maybe the math.dist() version could be slightly more convenient to use. But I'm not sure if "slightly more convenient" really makes it worth using up the extra space.

The numpy solution will work fine for my intended use so I could go either way on the inclusion of math.dist(). I'm happy to either close this, or push it further with a PR based on whether there is any other interest in math.dist() specifically.

[tannewt]

What is the background for this? Is it helping you do something faster?

[FoamyGuy]

I am trying to make intersection detection functionality for arcade / physics style games. (#9483 is the beginning of this effort).

Some of the intersection functions rely on euclidean distance calculations so I looked into refactoring it into it's own function but went looking and found that CPython already has it.

I do intend for for these intersection detection functions to help me do something faster, specifically being able to check for intersection between lots of different shapes i.e. in a breakout style game I'll be checking for intersection between the ball and every brick each tick of the game loop.

I implemented the detection in python code first and did find that it slows down the main game loop by more than I'd prefer compared to the same code running with no detection logic. That's what led me to start working on intersection functions in the core and ultimately down the path that led to my interest in math.dist(). I have not done any bench-marking or comparison between (my 1st attempt at) C vs. Python implementations yet but do intend to. Theoretically the game can work-around slower intersection logic by increasing the distance the ball moves each frame, but I'm hoping to keep that distance as low as possible so that the ball movement will appear smooth and not "jittery".

[deshipu]

@FoamyGuy for collision detection you really don't want to use the euclidean distance directly, you want to use the square of the euclidean distance (and also square the number you are comparing it with), this way you don't have to calculate the costly square root.

[somenice]

I think it would make sense to add for completeness. Useful small addition to Math rather than using NumPy
Curious what the difference in performance comparing squares **2 vs squareroot **0.5?
Enjoying the progress @FoamyGuy

[tannewt]

I think this would be fine to add under MICROPY_PY_MATH_SPECIAL_FUNCTIONS.