Indeed r.bilinear doesn't produce atrifact .5 and stuff anymore, but it's
output is slightly different than the output of the new r.resamp.interp
method=bilinear.
See spearfish60 example:
$ g.region rast=slope -a
$ g.region res=10.95 -a
$ r.bilinear input=slope output=slope_rbil
$ r.resamp.interp input=slope output=slope_rinterp method=bilinear
$ r.mapcalc 'diff=slope_rbil-slope_rinterp'
There is a minimal difference...
$ r.info -r diff
min=-0.000000
max=0.000000
... which can be seen on display as a kind off a regular pattern, and if
exagerated x10^15 it is noticable as:
$ r.mapcalc 'diff_exag=diff*10.0^15.0'
$ r.info diff_exag -r
min=-7.105427
max=7.105427
?
Maciek
-------------------------------------------- Managed by Request Tracker
Maciek Sieczka via RT wrote:
Indeed r.bilinear doesn't produce atrifact .5 and stuff anymore, but it's
output is slightly different than the output of the new r.resamp.interp
method=bilinear.
See spearfish60 example:
$ g.region rast=slope -a
$ g.region res=10.95 -a
$ r.bilinear input=slope output=slope_rbil
$ r.resamp.interp input=slope output=slope_rinterp method=bilinear
$ r.mapcalc 'diff=slope_rbil-slope_rinterp'
There is a minimal difference...
$ r.info -r diff
min=-0.000000
max=0.000000
... which can be seen on display as a kind off a regular pattern, and if
exagerated x10^15 it is noticable as:
$ r.mapcalc 'diff_exag=diff*10.0^15.0'
$ r.info diff_exag -r
min=-7.105427
max=7.105427
?
That level of error can easily be attributed to differences in
rounding. It's by no means clear which of the two (if either) is more
accurate.
For IEEE FP, DBL_EPSILON is ~2.2e-16, so a value of ~7.1e-15 is
roughly 32 * DBL_EPSILON. "r.info slope" gives the range as roughly
0-52.5, so I'd expect to see errors of +/- 1.2e-14 (i.e. around 63%
more than you're actually getting).
Differences at that scale are irrelevant; there's no way that your
source data is going to be accurate to 16 digits (2.2e-16 is
equivalent to measuring the equatorial circumference to an accuracy of
10 nanometres).
--
Glynn Clements <glynn@gclements.plus.com>