Before I delve into the code to try to find this out: does someone know
what is the behaviour of r.recode at the limits, i.e. with
0:10:0:1
10:20:10:20
what is 10 recoded to ?
In other words are the min and max values exclusive or inclusive ?
Moritz
Moritz Lennert wrote:
Before I delve into the code to try to find this out: does someone know
what is the behaviour of r.recode at the limits, i.e. with
0:10:0:1
10:20:10:20
what is 10 recoded to ?
1
In other words are the min and max values exclusive or inclusive ?
They're both inclusive. If ranges overlap (Rast_fpreclass_add_rule()
doesn't prevent this), the first match is used. If the rules were
reversed:
10:20:10:20
0:10:0:1
then 10 would be recoded to 10.
BTW, libraster needs reformatting; the change of prefix from G_* to
Rast* means that parameter lists which are split over multiple lines
no longer align, e.g.:
void Rast_fpreclass_add_rule(struct FPReclass *r,
DCELL dLow, DCELL dHigh,
DCELL rLow, DCELL rHigh)
--
Glynn Clements <glynn@gclements.plus.com>
On Mon, Jul 13, 2009 at 5:25 PM, Glynn Clements<glynn@gclements.plus.com> wrote:
BTW, libraster needs reformatting; the change of prefix from G_* to
Rast* means that parameter lists which are split over multiple lines
no longer align, e.g.:
void Rast_fpreclass_add_rule(struct FPReclass *r,
DCELL dLow, DCELL dHigh,
DCELL rLow, DCELL rHigh)
I have tried but the script in tools/ is introducing
ugly vertical white space in the variable definitions, e.g.
@@ -28,8 +30,11 @@
static int organize_fp_lookup(struct Colors *colors, int mod)
{
int i;
+
DCELL val;
+
struct _Color_Info_ *cp;
+
struct _Color_Rule_ *rule;
Some "indent" magic apparently.
Markus
Markus Neteler wrote:
> BTW, libraster needs reformatting; the change of prefix from G_* to
> Rast* means that parameter lists which are split over multiple lines
> no longer align, e.g.:
>
> void Rast_fpreclass_add_rule(struct FPReclass *r,
> DCELL dLow, DCELL dHigh,
> DCELL rLow, DCELL rHigh)
I have tried but the script in tools/ is introducing
ugly vertical white space in the variable definitions, e.g.
@@ -28,8 +30,11 @@
static int organize_fp_lookup(struct Colors *colors, int mod)
{
int i;
+
DCELL val;
+
struct _Color_Info_ *cp;
+
struct _Color_Rule_ *rule;
Some "indent" magic apparently.
I can't reproduce this, and grass_indent.sh passes -npro to indent
so it shouldn't be affected by any .indent.pro files.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2009/7/14 Glynn Clements <glynn@gclements.plus.com>:
[...]
I have tried but the script in tools/ is introducing
ugly vertical white space in the variable definitions, e.g.
@@ -28,8 +30,11 @@
static int organize_fp_lookup(struct Colors *colors, int mod)
{
int i;
+
DCELL val;
+
struct _Color_Info_ *cp;
+
struct _Color_Rule_ *rule;
Some "indent" magic apparently.
I can't reproduce this, and grass_indent.sh passes -npro to indent
so it shouldn't be affected by any .indent.pro files.
I have the same problem, Debian GNU/Linux Sid,
GNU indent 2.2.10
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Martin Landa wrote:
>> I have tried but the script in tools/ is introducing
>> ugly vertical white space in the variable definitions, e.g.
> I can't reproduce this, and grass_indent.sh passes -npro to indent
> so it shouldn't be affected by any .indent.pro files.
I have the same problem, Debian GNU/Linux Sid,
GNU indent 2.2.10
FWIW: GNU indent 2.2.9.
This appears to be a bug in 2.2.10, e.g.:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485764
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Jul 15, 2009 at 6:32 AM, Glynn Clements<glynn@gclements.plus.com> wrote:
Martin Landa wrote:
>> I have tried but the script in tools/ is introducing
>> ugly vertical white space in the variable definitions, e.g.
> I can't reproduce this, and grass_indent.sh passes -npro to indent
> so it shouldn't be affected by any .indent.pro files.
I have the same problem, Debian GNU/Linux Sid,
GNU indent 2.2.10
FWIW: GNU indent 2.2.9.
This appears to be a bug in 2.2.10, e.g.:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485764
I have reported it upstream:
https://savannah.gnu.org/bugs/index.php?27036
Markus