{"action":"opened","issue":{"url":"https://api.github.com/repos/RobotLocomotion/drake/issues/10907","repository_url":"https://api.github.com/repos/RobotLocomotion/drake","labels_url":"https://api.github.com/repos/RobotLocomotion/drake/issues/10907/labels{/name}","comments_url":"https://api.github.com/repos/RobotLocomotion/drake/issues/10907/comments","events_url":"https://api.github.com/repos/RobotLocomotion/drake/issues/10907/events","html_url":"https://github.com/RobotLocomotion/drake/issues/10907","id":420536337,"node_id":"MDU6SXNzdWU0MjA1MzYzMzc=","number":10907,"title":"Document geometry query result precision","user":{"login":"SeanCurtis-TRI","id":22159799,"node_id":"MDQ6VXNlcjIyMTU5Nzk5","avatar_url":"https://avatars3.githubusercontent.com/u/22159799?v=4","gravatar_id":"","url":"https://api.github.com/users/SeanCurtis-TRI","html_url":"https://github.com/SeanCurtis-TRI","followers_url":"https://api.github.com/users/SeanCurtis-TRI/followers","following_url":"https://api.github.com/users/SeanCurtis-TRI/following{/other_user}","gists_url":"https://api.github.com/users/SeanCurtis-TRI/gists{/gist_id}","starred_url":"https://api.github.com/users/SeanCurtis-TRI/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/SeanCurtis-TRI/subscriptions","organizations_url":"https://api.github.com/users/SeanCurtis-TRI/orgs","repos_url":"https://api.github.com/users/SeanCurtis-TRI/repos","events_url":"https://api.github.com/users/SeanCurtis-TRI/events{/privacy}","received_events_url":"https://api.github.com/users/SeanCurtis-TRI/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2019-03-13T14:38:35Z","updated_at":"2019-03-13T14:38:35Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"In the current master (as of 3/13/2019), the quality of the answers in geometric queries is accurate to machine precision in some cases, and approximate to within some threshold in others. Even as we improve the code so that more and more answers will be precise to machine precision, we know we can't guarantee that universally.\r\n\r\nSo, the module documentation should discuss this and document the current state of affairs. Users should be able to pull up a set of tables (one per query type) that say:\r\n\r\n> For shape type A vs shape type B, this query will produce an answer that is within [tolerance] of the true answer.\r\n\r\nFor example:\r\n\r\n| | Sphere | Box | Cylinder |\r\n| -: | :-: | :-: | :-: |\r\n| Sphere | ε | ε | ε |\r\n| Box |  | 10e-8  | ε |\r\n| Cylinder | | | user tolerance¹ |\r\n\r\n- ε represents the machine precision multiplied by the \"scale\" of the geometry configuration: the scale of the two geometries and the distance between surfaces.\r\n1. user tolerance is set through `SomeClass::set_tolerance()`.\r\n\r\nWhen we're done, every cell that can be populated with ε will be, all others will be configurable with user-defined tolerances. And, in the interim, it will reflect the current state of the code. (In some cases, the tolerance for the current state of the code may be \"unknown\".)"}}
{"actor":{"display_login":"SeanCurtis-TRI"}}