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
{{ message }}
This repository has been archived by the owner on Nov 18, 2022. It is now read-only.
As floating point numbers are used to represent coordinates, there are precision issues (having cumulative effects).
For example, if we are calculating the location of a point that divides an edge by a previously calculated ratio, sometimes it might produce a point that lies slightly off the edge. In once case around 4% difference in expected and actual areas of subpolygon was observed.
Ideas for improvement:
review order of arithmetic actions. Maybe some calculations could also be simplified to improve precision.
for each point produced, track the edge it belongs to and use that in further calculations.
Alternatively, snap produced points to the edge it belonged to.
Or make small adjustments once each subpolygon is produced.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As floating point numbers are used to represent coordinates, there are precision issues (having cumulative effects).
For example, if we are calculating the location of a point that divides an edge by a previously calculated ratio, sometimes it might produce a point that lies slightly off the edge. In once case around 4% difference in expected and actual areas of subpolygon was observed.
Ideas for improvement:
The text was updated successfully, but these errors were encountered: