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@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@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@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@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@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@math.umn.edu
Ferventer Vestite