You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Probably, the problem is that the bounding box becomes (inf) or how small floating point errors will partially add up when calculating the intersection. To iterate improvements of this algorithm, inf could then be redefined to treat smaller inputs with finesse and then to calibrate the value of epsilon (eps) to be less strict about minor floating-point deviation. Some ways you could improve the precision are:
Refine the Bounding Box:
Instead of inf fixed large bounding box, you may consider that the bounding box is computed on ranges of input points and it is an adjustment dynamically on data.
Tolerance for Precision (eps) :
For epsilon, it has been set at 1e-9. In some instances this value might be too small, especially when there is the need to address floating-point imprecision. You may try increasing this a bit, handle precision without losing some precision.
Small Inputs and Edge Cases
Deal with the inputs that have negative coordinates or very small values explicitly, make sure you check for edge cases when your coordinate is close to zero.
The code in the article seems to yield the wrong result for some tiny inputs, for example:
The intersection should be bounded:
The problem is likely the large bounding box.
The text was updated successfully, but these errors were encountered: