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

[Markus Neteler]

Hi all,

On Fri, May 18, 2001 at 12:26:50PM +0100, Glynn Clements wrote:
> 
> [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.

unfortunately there is still no discussion on these problems...

Just want to get this problem back into minds :-)

Markus