Hi Fernando, Fernando Cacciola wrote:
Hi Barend,
See:
Thanks for the clarification. The library uses the epsilon for floating point comparisons. Your will see it next week, but it is like this: inline bool operator==(const point& other) const { if (std::numeric_limits<T>::is_exact) return m_x == other.m_x && m_y == other.m_y; else return abs(m_x - other.m_x) < std::numeric_limits<T>::epsilon() && abs(m_y - other.m_y) < std::numeric_limits<T>::epsilon(); }
If this approach is not enough
Indeed, is not enough.
you can please help us to make it more robust because I agree, the library should handle these issues and not the user because that is not possible.
Yes, I can help you. The very first thing you need to do is understand the problem and why that approach is insufficient.
Have you read the sample discussion I posted before? that should get you started.
OK, thanks for your offer. Let me first finish the preview, it will take me too much time if I dive into this at this moment. I glanced through the discussion and to the philosophy page of CGAL, thanks.
If the library *unnecesarily* fails to produce correct results because of numerical issues then it's not 'simple' but 'simplistic'.
OK, tell me next week if it is bright and simple or just simplistic, I'm curious.
You are using the so-called epislon-geometry approach, so I can tell you now: this is simplistic ;)
Feel free to contact me directly if you want, though it might be interesting to discuss it on the list becasue this is not a problem specific to geometric computing but any computing sensitive to round off.
Thanks again, I surely will come back to this. Barend Gehrels. ------------------------------------- Barend Gehrels, Geodan Holding b.v., Amsterdam, The Netherlands, www.geodan.nl