[GRASS-dev] [GRASS GIS] #2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account

[GRASS GIS]

#2053: r.recode: 0.0 or 1.0 as limits do not seem to be taken into account
----------------------------------------------------+-----------------------
 Reporter:  nikosa                                  |       Owner:  grass-dev@…              
     Type:  defect                                  |      Status:  new                      
 Priority:  major                                   |   Milestone:  7.0.0                    
Component:  Raster                                  |     Version:  unspecified              
 Keywords:  r.recode, DCELL, CELL, rules, needinfo  |    Platform:  Unspecified              
      Cpu:  Unspecified                             |  
----------------------------------------------------+-----------------------

Comment(by wenzeslaus):

 Replying to [comment:5 glynn]:
 > Replying to [comment:4 annakrat]:
 > > Any opinion on the suggested change? This is in my view quite serious
 bug.
 >
 > If it's going to deduce the type from the rules, I suggest checking for
 a decimal point prior to parsing rather than checking whether the parsed
 value is exactly representable as an integer. IOW, "0.0:1.0:0:255" will
 perform a float-int recode while "0:1:0:255" will perform a int-int
 conversion.
 >
 > I wouldn't suggest using the input map's type for the input type unless
 this will produce identical results.

 I think that what is expected to determine the type of input is the input
 map. The output should be determined by the rules, since it seems as a
 common practice - the numbers giving the type. This does not apply the to
 input map because it already has a type. `r.mapcalc` has the same behavior
 unless you do explicit retype (using `int()` but using number format is
 not explicit retype in my opinion).

 In other words, I consider the current behavior wrong and determining the
 input type from decimal point does not improve the situation. If rules are
 `0:1:0:255` and the input is double, the result will be always 0 for the
 whole map. This is not what I expect. For `0:10:0:255` and input again
 double from 0 to 10, the output will not look completely wrong as in
 previous case which is perhaps even more dangerous because I just don't
 expect the numbers from input map to by trimmed to integers before the
 computation (although I expect the integer on the output).

 I also don't see any case where it would be advantageous to trim the
 numbers before the recoding itself.

 What is your reason for trimming the numbers on input ("to produce
 identical results")?

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2053#comment:6>
GRASS GIS <http://grass.osgeo.org>