#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 annakrat):
Replying to [comment:8 glynn]:
> Replying to [comment:5 glynn]:
>
> > I wouldn't suggest using the input map's type for the input type
unless this will produce identical results.
>
> From examining lib/raster/fpreclass.c, it appears that they will produce
identical results (int and float values are simply converted to double),
so this is a non-issue.
>
So, if we decide to go with a simple fix, using input map type (as
suggested in the code snippet above) would be a solution, right?
>
> However, this might be a good time to re-examine how floating-point
values are converted to integers both in fpreclass.c and put_row.c.
>
> Both cases simply use a C cast, which is defined as discarding the
fractional part, i.e. rounding toward zero (inwards). The GRASS
quantisation functions are only used when reading floating-point maps as
integer, not when writing.
>
> This is one of the least useful rounding modes, due to its anti-
symmetric behaviour (i.e. positive numbers are rounded down, negative
numbers are rounded up). Rounding to nearest integer or rounding toward
negative infinity (i.e. floor()) are usually preferred.
Floor sounds definitely better. How invasive and difficult would be this
're-examining'?
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2053#comment:9>
GRASS GIS <http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
