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@gclements.plus.com>