https://svn.boost.org/trac10/ticket/10201 <p> boost::geometry::detail::disjoint &lt;point_tag, point_tag&gt; seems to be using boost::geometry::math::equals instead of boost::geometry::math::equals_with_epsilon . </p> <p> It seems like in most cases, the latter would be more appropriate, especially considering that it applies only to floating point numbers. </p> <p> I'm not sure what the desired behaviour here is.] </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/10201 Trac 1.4.3 awulkiew Tue, 24 Mar 2015 01:10:37 GMT https://svn.boost.org/trac10/ticket/10201#comment:1 https://svn.boost.org/trac10/ticket/10201#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> Thanks! </p> <p> However everything should be ok here. <code>math::equals()</code> uses scaled machine epsilon to compare floating point numbers. By default <code>math::equals_with_epsilon()</code> uses <code>math::equals()</code>. </p> <p> AFAIK <code>equals_with_epsilon()</code> was used in the past as a workaround in some cases (e.g. it allowed to define comparison differently for user-defined coordinate types) but now after robustness upgrades it's no longer needed. </p> <p> Do you have any problems with disjoint() because of this? Or did you catch this while reading the code? </p> <p> Anyway, I'm closing the report. </p> Ticket anonymous Tue, 24 Mar 2015 04:23:07 GMT