Comments on scripts, modeling and Grass

bob at math.umn.edu bob at math.umn.edu
Wed Oct 27 10:28:50 EDT 1999


> 
> I comment here on the several reactions to my message 
> "Re: Forestry and Grass + scripts for models"
> 
> Issue 1: Are "classic" programming languages (i.e., FORTRAN, c, c++...)
> adequate for GIS modeling?
> 
>  Rich Shepard <rshepard at appl-ecosys.com>
> 
> >"  It was only when I moved to microcomputers and C (in the mid-1980's) that
> >I learned the value of commenting code. Scientists aren't taught this;
> >programmers are.
> 
> >  My code now is at least 50% comments; often much more. I explain why I did
> >something a certain way or what I was trying to accomplish. The effort is
> >repaid manyfold when I look at old code years later. :-)"
> 
> Well, this demonstrates that C is not a good language for modeling, as 
> you have
> to repeat each line in a different language. Would English be an adequate 
> language for this
> message if I had to repeat every paragraph in a different language because
> virtually nobody (even not myself!) could understand what I'm saying? 
> (OK, sometimes my English can be so obscure that this problem could actually 
> be real!).

The real point here is to adequately comment all programs.  That is, one should
include explanatory text explaining the flow of the algorithms used.  This is
useful even when nobody but you will see the code, since mere mortals like me
can forget details within a few months of writing a program.
 
> Note that I'm talking about modeling. I understand that, in other 
> applications,
> FORTRAN, C, C++,..., can be the best alternative. But, in modeling, often you
> cannot evaluate the program just by the result. If you write a program to
> display an image, you can easily detect an error in the code because
> the display would be wrong. Or if you write a program to calculate
> an FFT you can use a simple input and compare the result to your own 
> computation
> or to the result produced by another FFT program: the result is predictable.
> Instead, in modeling, the result is not predictable (yet): that's why
> you make the model. Also, you can have a CORRECT result out of a WRONG model:
> the result must be produced by processes that are physically, biologically,
> ecologically... consistent, and this should be assessed by other scientists
> being able to read the code. Which implies a simple syntax with, ideally,
> one action per line.
 
... Or the code needs to produce sufficient meaningful diagnostics so as to
let anybody determine whether the result is nonsense.  That is to say, it 
needs to be compared with data, somehow.  I venture to say that few people
will want to dive into the actual code. 
 
<snip> 
> Issue 2: Are the scripting languages around convenient alternatives?

<snip> 
> Leonard Coop <coopl at ava.bcc.orst.edu>:
> 
> >Here is a snippet from a perl script (I didn't write it but I use it)
> >running GRASS showing how you can use perl files as standard i/o to
> >write to GRASS functions, in this case r.mapcalc:
> 
> >    open RMAPCALC, "|r.mapcalc" or die "Can't launch r.mapcalc";
> >    # STEP 5: ADD CORRECTIONS
> >    print RMAPCALC "$corrname = ($basename * $rationame)/1000\n";
> >    # STEPS 6: FORCE NEGATIVES TO ZERO
> >    print RMAPCALC "$outname = max($corrname,0)\n";
> >    close RMAPCALC;
> 
> Well, here we have 5 lines for what should be just one, 
> r.mapcalc "out = max( ($basename * $rationame)/1000, 0)"
> 
> ...and not to tell about the annoying and redundant "$": if we write
> a program, the default should be that the names of the variables represent
> the variables, or should I sign this message as $AgustinLobo ? If I sign
> as Agustin Lobo, would anybody understand that my name has written the 
> message?

Ah, but in Perl one does not declare variables, an advantage.  One could 
replace Leonard's small bit of code with a subroutine, call it something
like "mapcalc_corr()" and have a perfectly readable line.

The key is IMHO to use a language with which you have familiarity.  What
GRASS would then do is require a standard I/O for communicating with what
you write.
 
<snip> 
> ISSUE 3. Are "high level" languages (i.e., Splus (R as free alternative),
> Matlab (Octave as free alternative), IDL ...) adequate for GIS modeling?
> 
> Rich Shepard <rshepard at appl-ecosys.com>:
> > I've know of S-Plus and I just discovered R. I think that it
> > would be ideal to link GRASS and R for analytical purposes.
> 
> "Pete St. Onge" <pete at seul.org>
> 
> >Alternatively, R has a batch mode that can be called from the shell. You
> >could actually build an R script programmatically from another app once
> >the data files have been created, then launch R to do batch processing 
> by running the script.
> 
> Yes, as with Splus and, probably, Matlab. The problem, as I said, is
> that the communication between R and Grass would be through writing
> and reading files: this is slow (remember a model can have thousands
> of iterations) and uses more disk space (which is becoming a minor
> problem, though).

True enough.  Communication via ports or pipes is a possibility.

> Another problem with Splus (I think that R is better but don't know
> how much better) is that it is very inefficient with FOR loops, as it
> allocates all the memory at once. This is a big problem for simulations,
> that typically have long loops.

Matlab is designed to run fast vector and matrix algorithms using ':' notation
in indexing, and other tools.  Of course, one needs to keep in mind that 
GRASS is open source.  Becoming overly-reliant on any one commercial package
could pose problems down the road.
 
<snip> 
> Final comment: using C for writing is like making a toy out of raw 
> plastic material:
> you can do whatever you want but it is difficult and, probably, the parts 
> will not
> be used by others. Using grass commands within a script (either a shell 
> script
> or Splus, Matlab etc) is more like using a LEGO: you have more constraints,
> but the parts are standard, which implies that many others use them and can
> detect errors.

Very true, and a good goal.

> Agus
> 
> Dr. Agustin Lobo
> Instituto de Ciencias de la Tierra (CSIC)
> Lluis Sole Sabaris s/n
> 08028 Barcelona SPAIN
> tel 34 93409 5410
> fax 34 93411 0012
> alobo at ija.csic.es
> http://pangea.ija.csic.es/alobo

Adios,
Chris
-- 
C.S. Cornuelle 
School of Mathematics/MCIM, University of Minnesota
206 Church St. SE, Minneapolis, MN 55455
(612) 626-8930v, (612) 624-2333f, bob at math.umn.edu
Ferventer Vestite



More information about the grass-user mailing list