[GRASS-dev] Binary operations added to r.mapcalc

[Glynn Clements]

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>