[GRASS-dev] [GRASS GIS] #2854: results in winGRASS7 32bit vs 64bit: should they be identical?

GRASS GIS trac at osgeo.org
Mon Jan 11 12:23:08 PST 2016


#2854: results in winGRASS7 32bit vs 64bit: should they be identical?
---------------------+---------------------------------
  Reporter:  hellik  |      Owner:  grass-dev@…
      Type:  defect  |     Status:  new
  Priority:  normal  |  Milestone:  7.0.3
 Component:  Raster  |    Version:  svn-releasebranch70
Resolution:          |   Keywords:
       CPU:  x86-64  |   Platform:  MSWindows 7
---------------------+---------------------------------

Comment (by glynn):

 Replying to [comment:7 neteler]:

 > Doesn't this qualify for "basically identical results as much as
 different architectures can achieve"?

 In theory, it should be possible to obtain identical results on any
 architecture using IEEE-754 floating-point for calculations using only +,
 -, *, / and sqrt() (no transcendental functions such as sin, cos, log,
 exp, etc). But that may have a noticeable performance cost (e.g. using
 -ffloat-store to discard excess precision, forgoing certain optimisations,
 etc).

 Regarding the use of an "epsilon":

 1. The accuracy of a floating-point value is proportional to its
 magnitude. For IEEE-754, FLT_EPSILON is ~1.192e-7 while DBL_EPSILON is
 ~2.22e-16. This represents the difference between 1.0 and the smallest
 distinct, representable value greater than 1.0.

 Consequently, it provides a measure of the worst-case rounding error for
 values between 1.0 (inclusive) and 2.0 (exclusive). For round-to-nearest,
 the worst-case rounding error will be plus or minus half that value. For
 larger or smaller values, the maximum rounding error will be scaled
 accordingly. I.e. a typical "tolerant comparison" would be along the lines
 of
 {{{
     if (fabs(a-b) < N * epsilon * max(fabs(a),fabs(b))) ...
 }}}

 2. Rounding error occurs at each stage in the computation. The expected
 absolute error for a complex calculation will be at least the sum of the
 absolute errors for the individual steps.

 3. When subtractions are involved, you can't rely upon the absolute error
 in the result being proportional to the magnitude of the result, as
 subtracting similar values will produce a result whose magnitude may be
 much smaller than either of the individual values, but whose absolute
 error is proportional to that of the individual values.

 (A concrete example of that last point is that a single-pass variance
 calculation using sum-of-squares minus sum-squared can yield a negative
 value for the variance if the deviations are small relative to the mean).

 4. Other common cases where the accuracy of the result can be far worse
 than that of intermediate results or the inputs include finding roots of
 high-degree polynomials
 ([https://en.wikipedia.org/wiki/Wilkinson's_polynomial an extreme
 example]) and acos(x) where x is close to 1.0 (as x tends to 1.0, the
 derivative of acos(x) tends to infinity while acos(x) itself tends to
 zero; the first magnifies the absolute error while the second further
 magnifies the relative error).

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2854#comment:9>
GRASS GIS <https://grass.osgeo.org>



More information about the grass-dev mailing list