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

[Roger Bivand]

On Mon, 4 Jun 2001, Glynn Clements wrote:

> 
> Roger Bivand wrote:
> 
> > 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.

I'm sure you're right if a user needs to read the output. I tend to be too
abstract and would generally use awk, sed, or something similar to
post-process output in any case - %e with specified significance is more
for other programs to read. But for other programs, this is what preserves
the precision in the data.
 
> 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?
> 

Yes. The next step is where to keep the knowledge about the value range,
number of significant digits, etc., which is a kind of metadata. Should it
be given explicitly to each modular command, or treated like a region or
histogram, or palette, or operate per session for a location? In a
different thread, the common-sense in GRASS implicit in having separate
programs do different things is stressed. But here - as with GUI-type
things, the granularity is different, with the significance metadata
needing (potentially) to be accessible to successive programs, so that the
formatting decisions don't need to be passed to each in turn. 

> [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.
> 
> 

Roger

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