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

Glynn Clements glynn.clements at virgin.net
Wed Jun 6 10:09:27 EDT 2001


Roger Bivand wrote:

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

And, of course, the step after that is for any program which generates
data to automatically set the precision based upon the precision of
the input(s) and the nature of the computation. But I'm not expecting
to see that happen soon.

For now, I'm just looking for a way to "pass the buck" to the user. 
At least they *might* know the correct format to use.

Anyway, much of this is starting to look like 5.1 territory.

For 5.0.0 I'd suggest something along the lines of:

	printf("%#.*g", atoi(getenv("GRASS_PRECISION")), val);

except in any cases where exponential form is known not to work, in
which case use "%.*f" instead.

For numbers larger than 1e-4, you can prevent exponential form from
being used by setting GRASS_PRECISION to a large enough value. And
numbers smaller than 1e-4 weren't handled well with "%f" anyway
(maximum of 2 sig.dig).

Also, I'm not sure if there's much point having separate defaults for
FCELL and DCELL data. Does anyone know of real-world cases where the
actual precision exceeds that of "float" (rel. error ~= 1.2e-7)?

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



More information about the grass-dev mailing list