Comments on scripts, modeling and Grass

[Seppo Kaitala]

Hello everybody

I whant to remind that there exists also GPL clone of MATLAB called
Octave.
Octave is compatible with Matlab vesion 3 and has output to Gluplot. You
can find code for statistical analysis and also for principal
components.  Under Octave they have also easy way how to support
financially GPL development of OCTAVE.  Maybe that way could be used
also in GRASS support.

You can find Octave at: http://www.che.wisc.edu/octave/index.html

Seppo Kaitala

bob at math.umn.edu wrote:
> 
> >
> > 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