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

[Glynn Clements]

Markus Neteler wrote:

> > Unless someone is planning on implementing a more robust variance
> > algorithm, we should at least add a check for negative variance in
> > r.univar. BTW, does s.univar suffer from the same problem?
> 
> I have tested this:

[snip]

>       standard deviation 1.45885e-13
> coefficient of variation 1.32622e-11

[snip]

> -> far from being perfect

At least it didn't fail with a domain error, although that may well
just be luck. Not having looked at the code, I can imagine that using
a different input value might result in a variance slightly less than
zero instead of one slightly greater.

> > > r.mapcalc seems to generate FCELL only. Shouldn't the range printed with
> > > float precision then?
> > 
> > Yes. float has just under 7 digits of precision (FLT_EPSILON is around
> > 1.19e-7 for IEEE single precision), so "%.6f" should do it. I suspect
> > that "%.10f" was "pulled out of a hat".
> 
> O.k. I have changed that to "%.6f" in CVS.
> Now I get:
> 
> r.mapcalc plane=1.1
> range: 1.1 1.1
> 
> which is looking better.
> 
> and:
> r.mapcalc plane=1.123456789
> range: 1.123457 1.123457

Note, however, that a similar approach probably should NOT be adopted
for writing data to files (e.g. sites files). Whilst using less
precision than a float has may improve the appearance (and conserve
space), it is likely to introduce further error.

Furthermore, "%f" (with or without width and/or precision modifiers)
should never be used for data which is intended to be read by a
program; use "%e" instead.

> > > Sorry for insisting here, but above range will
> > > be expected to be wrong by the average user not familiar with precision
> > > issues.
> > > 
> > > And r.stats: maybe the printed precision should be dependent from the
> > > input map type, means more decimals for DCELL maps that FCELL maps.
> > 
> > Maybe; although this won't help if a DCELL map is generated using
> > float data somewhere in the process.
> 
> O.k., but we should address the problem when displaying a FCELL map.
> In above example I get:
> 
> r.stats -1 plane
> 1.1234568357
> 1.1234568357
> 1.1234568357
> 
> instead of
> 1.1234568
> 1.1234568
> 1.1234568
> 
> Could the RASTER_MAP_TYPE be used somehow for the "fprintf()"s?

It could, but I suggest that care is taken not to put neatness before
accuracy.

Having said that, GRASS seems to use "%f" liberally, which tends to
suck for very large or very small values; you get roughly constant
absolute error rather than roughly constant relative error.

For an illustration, redo your tests with numbers a million times
smaller; you'll end up with only two significant digits. OTOH, if you
redo them with numbers a thousand times larger, you'll get the error
digits back.

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

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'