Perhaps diversify "closest()" functions

[OneLoneCoder]

Currently closest() functions yield closest point on a shape boundary to some nominated point. Perhaps additional closest functions for shape vs shape?

[ulsoe05]

This is a good point :-)

Given the current primitives (point, line, circle, rectangle, triangle, ray) it appears to me that the most rigorous behaviour would be to return different types for each kind of closest overload. However, this can get somewhat complicated.

Let us take the closest(rectangle, line) case.

• could return a point (most likely)
• could return a 2 points (in case of overlap or in case of the line segment being inside the box with endpoints equally close to either end)
• could return 3 or 4 points if the line is inside the rectangle and one or both endpoints are near a corner
• could return a line (in case of the line being parallel to one of the sides. This could either be inside, outside or on the rectangle)
• could return a line + 1 or 2 points (if the line segment is locate inside the recangle, parallel to one side, but with one or two of the end point equally close to other sides.)
• could return 2 lines ...
• could return 2 lines and a point
• could return 2 lines and 2 points

This is only one such case. A worse one is triangle vs. triangle.

What to do?

I can see several ways a "closest" function could work for arbitrary primitive vs. primitive.

1. Accepting the complicated return options using std::variant or something like that.

Pro: Very rigorous
Con: Lots of complicated code
Con: Pretty complicated for the user

2. Always pick one point and return that (maybe inform the user in case of ambiguity).

Pro: Easy to understand and use.
Pro: Not that much code.
Con: Not very rigorous.

3. Refuse to return anything in case of ambiguity

Pro: Easy to understand and use.
Pro: Not that much code.
Con: I think this might be less useful for most users.

4. Do not handle the cases of overlapping or fully contained shapes. Possibly with a returned enum informing the user

Pro: Pretty useful
Con: Could still have more than one return type, but it will reduce the options considerably.

One could also imagine hydrids of the above approaches.
Personally, I would prefer to get exactly 1 point every time, but get informed if:

• Shape1 is contained in shape2
• Shape2 is contained in shape1
• Shape1 and 2 overlap
• If closest point is not ambiguous.

What do you people think? Either way, I would be happy to help implementing it.

[Piratux]

Firstly, I'd suggest to come up with use case for these "closest()" functions.

"Maybe it will be of use to someone" is poor argument, because without a use case there is no purpose of thinking of implementations.

I currently don't see a use for "closest()" function besides the "point vs shape" scenario.
Therefore I'd suggest not to implement this function for all shape combinations.

[Hannibaa]

I ll try to completed in my vacation, it's close, by using differential geometry and numerical methods.