[GRASS-dev] [GRASS GIS] #2466: r.param.scale slow on Windows when there is no data in raster

[GRASS GIS]

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