[GRASS-dev] Binary operations added to r.mapcalc
Glynn Clements
glynn at gclements.plus.com
Sun May 27 22:43:21 EDT 2007
Glynn Clements wrote:
> > > Oops; I could have sworn that r.mapcalc understood hex. Sorry; you'll
> > > need to use decimal values, e.g.
> > >
> > > r.mapcalc MASK="if(sur_refl_qc_250 & 240 == 176 , 1, null())"
> >
> > so r.mapcalc can do bitwise & |? (nothing about that in the help pages)
>
> Damn, no, that neither.
>
> Third attempt:
>
> r.mapcalc MASK="if((sur_refl_qc_250 / 16) % 16 == 11 , 1, null())"
>
> I'll look at adding the missing functionality to r.mapcalc.
I've added several new functions/operators to r.mapcalc, namely:
operator function description
<< shiftl shift left
>> shiftr shift right
>>> shiftru shift right (unsigned)
& bitand bit-wise and
| bitor bit-wise or
n/a xor bit-wise exclusive-or (XOR)
~ bitnot bit-wise not (one's complement)
[Note that there isn't an infix operator for XOR, as we're already
using "^" for exponentiation.]
Also, integers can be entered in hexadecimal notation (e.g. 0xFFFF). I
didn't add octal as there might be scripts which pass decimal numbers
with leading zeros.
In addition, I've changed the precedence of certain operators to match
C. Specifically, "&" has higher precedence than "|" (ditto for &&/&&&
versus ||/|||), and the inequalities (<,<=,>,>=) have higher
precedence than the equalities (== and !=).
Although this could theoretically affect existing scripts, I suspect
that it's unlikely.
In the &&/|| case, most people would either add explicit parentheses
or assume the C rules (and add the parentheses when they discover that
the C rules didn't hold).
In the case of [in]equalities, it's quite rare to nest these
operators. If nesting does occur, inequalities are invariably nested
within equalities (e.g. "(a < b) == (c < d)") rather than the other
way around, and the old rules would require explicit parentheses here.
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list