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

[Helena]

Markus,

as far as I can tell there is nothing wrong with r.mapcalc and Glynn is right
that this is a floating point precission issue. Everybody who does some
numerical computations has to deal with that - Lubos keeps a small constant
in his programs and when subtracting two FP numbers which could be
similar he compares the difference against that constant.
We had to deal with that in our grass programs too.

You can let r.mapcalc use only six digits when reporting the range (as
r.describe does)
so people won't get confused by getting a slightly different number,
on the other hand it is good to know what
the computer is really working with, so I would keep it there.

I think that  you need to take care of the issue in r.univar (as suggested by
Glynn).
If you want to know more,Lubos can explain it better than me, I can ask him to
write you.
We should put something about this into the GRASS handbook too.

BTW ArcView 3 spatial analyst map calculator quietly cuts-off some floating
point numbers - see
http://www2.gis.uiuc.edu:2280/modviz/erosion/usped.html
with some serious consequences - we don't want that in GRASS. (they have fixed
it for ArcGIS8)

Helena

Glynn Clements wrote:

> Markus Neteler wrote:
>
> > > Does this go away if you compile r.univar with "-ffloat-store"?
> >
> > Well, r.univar is only a script using r.stats and awk. However, after
> > recompiling r.stats with above flag (adding
> > EXTRA_CFLAGS=-ffloat-store
> > to the r.stats' Gmakefile) I can't see any difference.
>
> That wouldn't help; it's the awk script which is doing the relevant
> calculations. Looking at the awk script, I don't think that compiling
> awk with -ffloat-store would help.
>
> The problem is basically that none of the axioms of real arithmetic
> quite hold true for floating-point arithmetic.
>
> In this particular case, the variance is:
>
>         (SUM[x(i)^2] - SUM[x(i)]^2/N)/N
>
> If all of the x(i)'s are identical, then the two sides of the
> subtraction should be equal. However, given the error introduced by
> each floating point operation, they will differ slightly; if the RHS
> is slightly larger, then result will be negative, causing the sqrt()
> to fail.
>
> Whilst there probably is an algorithmic solution (a decent textbook on
> numerical methods should list many approaches for working around the
> problems inherent in floating-point subtraction), I'm not sure whether
> that would be justified, or if it would be better to just include an
> explicit check for a negative variance (indicating a variance so low
> that it's been swamped by rounding error).
>
> --
> 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'


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