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

[Roger Bivand]

Probably the reason why this went quiet is that it is difficult to do well
and portably. R uses six different user-controlled functions:

     `ceiling' takes a single numeric argument `x' and returns a
     numeric vector containing the smallest integers not less than the
     corresponding elements of `x'.

     `floor' takes a single numeric argument `x' and returns a numeric
     vector containing the largest integers not greater than the
     corresponding elements of `x'.

     `round' rounds the values in its first argument to the specified
     number of decimal places (default 0). Note that for rounding off a
     5, the IEEE standard is used, ``go to the even digit''. Therefore
     `round(0.5)' is `0' and `round(-1.5)' is `-2'.

     `signif' rounds the values in its first argument to the specified
     number of significant digits.

     `trunc' takes a single numeric argument `x' and returns a numeric
     vector containing the integers by truncating the values in `x'
     toward `0'.

     `zapsmall' determines a `digits' argument `dr' for calling
     `round(x, digits = dr)' such that values ``close to zero'' values
     are ``zapped'', i.e., treated as `0'.

where the underlying C code has to take care of machine dependencies as
well as retaining default values for the number of digits to round to, and
the number of significant digits to retain. The resulting returned values
are then handed off to formatting code. One reason for the difficulties is
that different users may need very different precisions for different
purposes, and this would in our case add to the arguments taken by
programs outputting FCELL and DCELL as text.

Roger 


On Fri, 1 Jun 2001, Markus Neteler wrote:

> 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 :-)
> 

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand at nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.