Hello,
Sorry for delay in answer -- we had long holidays here..
(For the place for this and similar topics, I deem Road-map section is reasonable choice, at least with the current small amount of topics.)
Regarding comparison of reals by ==:
0. No doubt it is bad practice, and we are trying to eliminate such cases when identified in our routine activity.
1. The common practice to check the value for being zero (or two values to be equal) -- by comparing the absolute value (difference) with some precision -- is in plain code, i.e. with no special function employed. I believe this approach is appropriate. Note that some classes (e.g. gp_Pnt) provide methods (typically called IsEqual) to check for equality.
2. Currently we do not plan to dedicate special efforts to dealing with this kind of issues, as it is difficult to expect touchable improvements from corrections made without real test cases.
3. The precision to be used in particular check generally depends on the nature of the quantities being compared.
OCCT provides some default precision values for comparison of 3d co-ordinates (Precision::Confusion), parametric co-ordinates (Precision::PConfusion), angular values (Precision::Angular), etc.
It is clear that these values are just default 'stub' and in each particular case some better defined value can be used. For instance, in the code dealing with topological shapes tolerance is typically used for coincidence checks, as tolerance is a measure of precision of the geometric representation of the entity. When working with parametric geometries, 3d tolerance can be mapped to parametric space using so-called 'Resolution' methods (estimates of maximum moduli of derivatives). In low-level math functions, precision is often chosen basing on floating point resolution, etc.
In practice, it is not always possible (or feasible) to choose really 'true' precision value for each check. Hence in many places you can observe usage of seemingly doubtful values, such as direct comparison to zero. I believe, however, that most of such cases are 'safe', i.e. they either check for equality to special values, or serve as protection against singular cases which should not happen in normal use.
I agree that cleaning the code from obviously wrong comparisons, such as those you have reported above, should theoretically improve the code. Note though that direct comparisons of reals is just the most obvious, by unlikely the most important situation when precision of calculation can be lost. Practically each floating-point calculation can be suspect of possible precision problems, depending on the input data. Hence I do not see alternative to our current case-based approach: the problem is fixed when it is identified.
This is where we would expect help from the user's community: it should not be difficult for everyone who spots this kind of problem to report it in the bug tracker and possibly provide a correction via Git. Now we have infrastructure allowing us to run certification tests and integration of code changes efficiently, thus your contributions are welcome!
Commenter-1