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

[Glynn Clements]

[CC'd to grass5, as I really think that this merits some discussion.]

Markus Neteler wrote:

> as you really know much more than me about the precision issue and the
> related %f (and whatever), may I leave eventual changes to you? I am
> afraid to introduce more problems that currently there. My intention is
> to have relyable numbers, not optically polished numbers, no question!
> 
> The candidates seem to be
>  r.stats
>  r.to.sites
>  r.describe
>  r.report
> 
> which print numbers to stdout.

I started looking into r.stats, and noticed a couple of issues:

1. r.stats uses DCELL for all floating-point data. Theoretically this
needs 17 significant digits in order to preserve accuracy, but would
the data ever be this accurate?

For geographical data, I suspect not; but how accurate might it be? If
we pick some "reasonable" value, that then becomes the limit of its
accuracy. If we don't, 17 digits is likely to be too many in 99% of
cases (9 digits too many for all FCELL data).

I noticed some code which appeared to be intended to support
specifying the precision ("dp" variable in main.c, "fmt" argument to
cell_stats, print_cell_stats). However, this isn't actually used (in
that "dp" can't actually be changed).

2. Shouldn't the format of "r.stats -1" be consistent for all data?

This initially started as a question of whether to strip trailing
zeroes, but then there's the issue that, with "%g", some values could
be printed in exponential form and others not.

One solution would be to select either "%e" or "%f" (and an
appropriate precision) once, based upon the overall range of the data,
rather than letting "%g" choose for each individual value.

3. Might the output from "r.stats -1" be fed to programs which don't
recognise exponential form? The ANSI functions (atof, strtod, *scanf)
all support it, but not everything uses those.

I haven't looked at the other programs; I suspect that similar issues
may apply to those.

If the output from the above programs (apart from r.to.sites) is
intended for a user (instead of or as well as for programs), then
appearance is a valid consideration. Further, programs may impose
limitations on their input (e.g. a program which reads floating-point
values may first store the string in a buffer which isn't wide enough
for the full precision of a double).

It might be worth the effort of designing and implementing (the latter
is the easy part) a system-wide function for converting floating-point
numbers to decimal.

At it's simplest, this could be little more than:

	sprintf(buf, getenv("GRASS_FLOAT_FMT"), val);

(don't take this too literally).

A better approach would allow individual programs to specify
particular requirements, with the default format filling in the
blanks.

An additional possibility is a new option type (in the sense of
G_define_option) to allow consistent input of format specifications as
command-line parameters.

-- 
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'