Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Library : Other (not classified elsewhere) » [Possible bug] Geometry - Point
[Possible bug] Geometry - Point [message #7032] Fri, 08 December 2006 11:15 Go to next message
artekk is currently offline  artekk
Messages: 1
Registered: December 2006
Junior Member
Hello

I suggest operator == and != should look something like this:

bool operator==( const Pointf3 &p )const
{
return fabs(x-p.x)<=EPSILON &&
fabs(y-p.y)<=EPSILON &&
fabs(z-p.z)<=EPSILON;
}

because in almost cases original code isn't accurate for veryvery small (EPSILON) distances between points.

artek

Re: [Possible bug] Geometry - Point [message #7122 is a reply to message #7032] Thu, 14 December 2006 20:59 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
I will ask our expert in the area, anyway, my problem with this is "what should be EPSILON"....

Mirek
Re: [Possible bug] Geometry - Point [message #7125 is a reply to message #7032] Thu, 14 December 2006 23:01 Go to previous message
rylek is currently offline  rylek
Messages: 79
Registered: November 2005
Member
Hello artekk!

I am afraid that your proposal, although sound in motivation, cannot stand a closer scrutiny. One of its major flaws has been pointed above by Mirek - the EPSILON is highly application- and context-dependent and cannot be pre-set to a constant value to suit every possible situation. Another argument against it looks somewhat abstract, but has serious practical implications: the above definition of equality is not transitive, i.e. generally (a == b && b == c) doesn't imply a == c. This is very important because it can introduce unexpected bugs into various algorithms. The inexact nature of the above proposed 'similarity relation' also causes trouble in hashing (e.g. in the Index / Map class family) which is based on the axiom that for each two values a, b, such that a == b, it must also hold that GetHashValue(a) == GetHashValue(b). When you define equality via similarity, I believe there is no way to define the hash value algorithm (other than a fixed constant independent on the argument) not breaking that axiom.

To make the long story short: I believe there is good reason in standard C/C++ for the == operator on floats and doubles to match only exactly equal values (and I think it is only natural for Pointf to build on this behaviour as in analytical geometry points and vectors are usually seen simply as ordered n-tuples of real numbers).

It is true, of course, that, when working with real numbers (and of course also with their n-tuples), funny things sometimes happen due to rounding and inexact nature of various arithmetical and transcendental operations. However, the nature of these deviations from math-theoretical behaviour (i.e. the difference between results of finite-precision and infinite-precision calculations) is far too complex to be "swept under the rug" using such a simple modification of the equality operator. I myself write real-number algorithms quite often and I strongly believe that the construction of a robust algorithm involves thorough theoretical analysis of the introduction and propagation of noise in the algorithm, static and/or dynamic estimation of error accumulation and a clear distinction where deviations are tolerable and the acceptable magnitude of these deviations (for instance, you usually need altogether different measure for linear and angular deviations).

Regards

Tomas

[Updated on: Thu, 14 December 2006 23:05]

Report message to a moderator

Previous Topic: NFormat and crash of the program
Next Topic: About the sort of the GridCtrl
Goto Forum:
  


Current Time: Fri Mar 29 16:23:36 CET 2024

Total time taken to generate the page: 0.00933 seconds