[GRASS-dev] [GRASS GIS] #2466: r.param.scale slow on Windows when there is no data in raster
GRASS GIS
trac at osgeo.org
Fri Oct 31 15:16:50 PDT 2014
#2466: r.param.scale slow on Windows when there is no data in raster
--------------------------------+-------------------------------------------
Reporter: annakrat | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: unspecified
Keywords: r.param.scale, nan | Platform: MSWindows 8
Cpu: Unspecified |
--------------------------------+-------------------------------------------
Comment(by glynn):
Replying to [ticket:2466 annakrat]:
> When I run r.param.scale on Windows with raster map with a lot of no
data, the computation is significantly slower (90 s on Ubuntu, 50 min on
Windows). r.param.scale doesn't propagate nulls. I read somewhere that
computing with nan can be slower on some architectures, could this be the
reason?
Normal floating-point operations will be handled directly by the CPU,
without the OS getting involved. But it's possible that converting NaN to
integer raises an exception which must be handled by the OS.
Aside from performance, it's not guaranteed that converting a NaN to an
integer will produce the integer null value (-2^31^), although that
happens to be the case on Linux/x86-64.
Code which converts potentially-null values needs to handle nulls
explicitly, e.g.
{{{
double d = ...;
int x;
if (Rast_is_d_null_value(&d))
Rast_set_c_null_value(&x, 1);
else
x = (CELL)floor(d);
}}}
Also, conversion should use normally use floor, ceil or rounding
(floor(x+0.5)). A C cast rounds toward zero (i.e. downward for positive
values, upward for negative values), which is rarely the correct choice.
> I attached a patch to propagate nans. I also realized that at one point
during preprocessing, there are large numbers computed (especially with
big cell size and high window size), so I thought double would be more
appropriate.
Are these values ever converted to integer? If so, conversion of out-of-
range values needs to be handled explicitly.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2466#comment:1>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list