[GRASS5] Re: [GRASS_DE] r.mapcalc round()

[Glynn Clements]

Markus Neteler wrote:

> > > Could the RASTER_MAP_TYPE be used somehow for the "fprintf()"s?
> > 
> > It could, but I suggest that care is taken not to put neatness before
> > accuracy.
> > 
> > Having said that, GRASS seems to use "%f" liberally, which tends to
> > suck for very large or very small values; you get roughly constant
> > absolute error rather than roughly constant relative error.
> > 
> > For an illustration, redo your tests with numbers a million times
> > smaller; you'll end up with only two significant digits. OTOH, if you
> > redo them with numbers a thousand times larger, you'll get the error
> > digits back.
> 
> I agree with you that accuracy is to be considered, not neatness.
> Therefore I am careful to change anything and continue to discuss/learn
> here :-)
> 
> How shall we deal with the example:
> r.mapcalc plane=1.123456789
> r.stats -1 plane
>  1.1234568357   
>  1.1234568357   
>  1.1234568357   
>           ^^^   
>           These numbers are phantasy.

Use "%.7e" or "%.8g" (or "%#.8g"). These (along with "%.38f", which
you probably won't want) are the smallest precision values which won't
introduce further error into a float. For double, the equivalents are
"%.16e", "%.17g" and "%.308f" (which you definitely won't want).

> As a lot of users (like me) like to redirect the output of r.stats into
> awk and other tools, they run into troubles with precision.
> 
> I have implemented "-s" right now into r.stats (not uploaded yet) which
> offers optional scientific notation (%e). In our example we would get:
> 1.123457e+
> 
> Does such a flag make sense? 

The inverse of this flag might make sense; "%e" should be the default
(if you really don't like that, at least use "%g").

> But: What about r.to.sites which is using %f and sending the wrong numbers
> into the sites list? Here we need a change, too.

If you use floating-point, you can't help but output "wrong" numbers.

In a few specific cases (including those from your original email),
the error introduced by prematurely trunctating the decimal
representation just happens to exactly cancel the error introduced by
converting to floating point. However, truncation will increase error
far more often than it reduces it.

How about this example:

r.mapcalc plane=0.00000001123456789
r.stats -1 plane
0.0000000112
0.0000000112
0.0000000112
0.0000000112
0.0000000112
0.0000000112
0.0000000112
0.0000000112
0.0000000112
0.0000000112
            ^^^
            These numbers weren't fantasy but, due to "%f", they are now.

(NB: r.mapcalc doesn't appear to support "E" notation for constants;
this could be considered a bug).

The above is with "%.10f"; with "%f", the output would be zero, which
is a rather substantial error.

Shouldn't we be more concerned about how GRASS handles real-world data
than contrived test cases? 

If GRASS only needs to support "toy" numbers, there doesn't seem to be
much point in having floating-point support at all.

The bottom line is that "%f" isn't much use unless you know the range
of the data, as the precision specifies an absolute error. An error of
1.2e-7 doesn't seem like much if you're assuming that the values will
be within a few orders of magnitude of 1.0; but is this assumption
valid?

-- 
Glynn Clements <glynn.clements at virgin.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'