#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 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.
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.
Another issue with a C cast is that if the result is outside the range of
an integer, the behaviour is undefined. Ideally such values should be
either converted to null or clamped to the most positive/negative
representable value.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2053#comment:8>
GRASS GIS <http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
