[GRASS-dev] [GRASS GIS] #2986: r.mapcalc with same variable on LHS and RHS

[GRASS GIS]

#2986: r.mapcalc with same variable on LHS and RHS
--------------------------+-------------------------
  Reporter:  mankoff      |      Owner:  grass-dev@…
      Type:  defect       |     Status:  closed
  Priority:  major        |  Milestone:  7.0.4
 Component:  Docs         |    Version:  7.0.3
Resolution:  fixed        |   Keywords:  r.mapcalc
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by glynn):

 Replying to [comment:8 mankoff]:
 > I'm still confused. The specific case of {{{r.mapcalc 'map=map'}}}
 mentioned 2 comments above does seem to work for me in v7.0.3 (see code
 example below).

 If the map had categories or quantisation rules, they will be discarded. A
 colour table should also be discarded but isn't because
 Rast_remove_colors(mapname,"") doesn't work (it compares the mapset
 literally with the current mapset without checking for the empty string).

 > Also, the last comment appears to say that everything on the LHS, even
 if a new unique LHSname, will be a variable and not a map (I'm not even
 sure what "variables" are in GRASS).
 The result of any expression can be assigned to a variable; that's what
 "=" does. If the assignment is a top-level expression (i.e. not a sub-
 expression), the value is written to an output map with the same name as
 the variable. Assignments other than at the top level (e.g. within eval(),
 which exists for this specific purpose) don't generate an output map. E.g.
 the i.pansharpen script uses the following r.mapcalc expression:
 {{{
 eval(k = "$ms1" + "$ms2" + "$ms3")
 "$outr" = 1.0 * "$ms3" * "$panmatch3" / k
 "$outg" = 1.0 * "$ms2" * "$panmatch2" / k
 "$outb" = 1.0 * "$ms1" * "$panmatch1" / k
 }}}

 Here, k is just a variable; because it occurs as a sub-expression of the
 eval() call rather than as a top-level expression, it doesn't result in an
 output map named "k". Its value is used in the subsequent expressions,
 avoiding the need to repeat the calculation for each one.

 Regardless of whether a variable is written to an output map, it's still a
 variable (i.e. something which is calculated for each row), not an input
 map (thus you cannot use any modifiers on it). If you use a name for both
 a variable and an input map, the variable hides the input map for all
 expressions following the assignment which creates the variable.

 > Finally, would it be possible to change this behavior, so that
 {{{r.mapcalc 'map = map * 2'}}} is valid syntax?
 No. It's already syntactically valid, the issue is that modifying a map
 while it is being read is undefined behaviour which only "sort-of" works
 (e.g. it may not work at all if r.external and r.external.out are in use
 such that the input and output maps refer to the same data file). That's
 an issue with the core GRASS libraries, and not something which r.mapcalc
 can realistically work around.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2986#comment:9>
GRASS GIS <https://grass.osgeo.org>