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. http://tinyurl.com/2os9co
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. Best -- Fernando Cacciola SciSoft http://fcacciola.50webs.com