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

[Markus Neteler]

On Wed, May 16, 2001 at 10:47:17PM +0100, Glynn Clements wrote:
> 
> 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,

I agree with you that accuracy is to be considered, not neatness.
Therefore I am careful to change anything and continue to discuss/learn
here :-)

How shall we deal with the example:
r.mapcalc plane=1.123456789
r.stats -1 plane
 1.1234568357   
 1.1234568357   
 1.1234568357   
          ^^^   
          These numbers are phantasy.
As a lot of users (like me) like to redirect the output of r.stats into
awk and other tools, they run into troubles with precision.

I have implemented "-s" right now into r.stats (not uploaded yet) which
offers optional scientific notation (%e). In our example we would get:
1.123457e+

Does such a flag make sense? 
But: What about r.to.sites which is using %f and sending the wrong numbers
into the sites list? Here we need a change, too.

Regards

 Markus


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