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

[Glynn Clements]

Markus Neteler wrote:

> > a) the awk script "r.univar",
> 
> BTW: A C implementation would be better (maybe using s.univar). Would
> be a nice exercise, but I don't have the time.

Simply re-implementing it in C should be trivial; however, that won't
solve the problems when the variance is swamped by the rounding error.

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?

> > > r.mapcalc test=1.1
> > > CREATING SUPPORT FILES FOR test
> > > range: 1.1000000238 1.1000000238
> > 
> > This is to be expected; r.mapcalc also uses "%.10f", which is more
> > precision than a float has (float will be promoted to double when
> > passed as an unprototyped argument, as is the case with printf()).
> 
> O.k. I think I understand the problem now. But how to deal with it?

Just use "%f" or "%.6f"

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

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

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