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

[Glynn Clements]

Roger Bivand wrote:

> > > 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.
> > 
> > Yep; so what should the syntax of these arguments be?
> > 
> > The simplest option (to implement) would be to allow a literal format
> > string to be specified, e.g. "fmt=%.6g". But that isn't necessarily
> > the best option for users.
> > 
> ...
> > 
> > Thinking about this a bit, there are quite a few different ways to
> > specify the precision, including (but probably not limited to):
> > 
> > 	Number of decimal places
> > 	Number of significant figures
> > 	Relative error
> > 	Absolute error
> 
> It looks as though number of significant figures is the most important,
> because that takes care of relative error too. Absolute error is maybe too
> scale-dependent to help, I don't have a feel for that unless that's what a
> client asks about? Number of decimal places is also dependent on where the
> point is to start with, so significant digits seem to be the way to go,
> and the line of least resistance is then %<sig.digs>e, (taking into
> account platform dependencies with regard to the exponent). Default values
> would follow from machine representation, for DCELL say 16 and for FCELL
> say 8, but stored as environment variables.

%e is certainly the simplest to implement; it isn't necessarily all
that user friendly, though. It may not be acceptable to some programs
either (although this can be worked around by post-processing, e.g. 
with awk).

I suspect that using exponential form generally might prove unpopular.

Having thought about it some more, some of the potentially useful
options can't be implemented simply by replacing printf("%f, val) with
print_in_preferred_format(val).

When displaying multiple values, it might sometimes be desirable to
have all the values printed in a similar format, e.g.

	 9.80e+3
	 9.90e+3
	10.00e+3
	10.10e+3

might be preferred over:

	9.80e+3
	9.90e+3
	1.00e+4
	1.01e+4

This would require the program to perform two passes on the data; one
to determine the range of magnitudes and another to print the values.

I guess that what I'm getting at is that the "default format" isn't so
much a constant as a function of various parameters, such as the
minimum and maximum values, the precision of the data[1], and maybe
program-specific constraints.

However, it isn't practical to allow the user to specify an arbitrary
function at run-time. The best practical option is for the (fixed)
formatting function to have the right parameters so that any remotely
reasonable formatting function can be chosen at run-time.

Does this make sense?

[1] The precision is really more than just whether the data is FCELL
or DCELL, although at present that's all that we have to go on. It
would be better if coordinate data (i.e. vector and sites files) could
include an indication of the data's actual precision.

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