> I am trying it at the moment with 1002 maps and, apart from the fact
> that it takes some time (which I am sure it would in GRASS as well),
> it seems to be working.
>
> I will be looking at R.series again later, when I run the simulations
> again. But I assume that there will be serious problems with 25000
> maps - I might have to do it with a sample of maps.
Hi,
for the standard stats available from r.univar
n
minimum
maximum
range
mean
mean of absolute values
standard deviation
variance
variation coefficient
sum
(ie not median, quartiles) you can use r.series in a loop, eg 1000 maps
at a time, and then sum up the resulting 25 summary maps before doing a
little math to get the overall answers. (or lots of 100 maps x250, ...)
I think you would need to add a new sum_of_squares method to r.series
to calculate variance/stdev. see r.univar/stats.c print_stats()
Or 25000 runs of
r.mapcalc "$map.sq = $map^2"
I can add sum of squares/cubes/etc to r.series easily enough if there
is a use for them.
Regarding command-line limits: is it worth extending G_parser() to
allow arguments to be read from a file? E.g. "r.series @args.txt".
It was quite common for this feature to be added to DOS ports of Unix
programs, as DOS had a much lower limit than Unix on the maximum
length of a command line.
On Wed, Feb 11, 2009 at 11:08 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Regarding command-line limits: is it worth extending G_parser() to
allow arguments to be read from a file? E.g. "r.series @args.txt".
It was quite common for this feature to be added to DOS ports of Unix
programs, as DOS had a much lower limit than Unix on the maximum
length of a command line.
Just to understand - does this allow to exceed the command limits?
Then it would be pretty helpful (as text files are easy to generate).
> Regarding command-line limits: is it worth extending G_parser() to
> allow arguments to be read from a file? E.g. "r.series @args.txt".
>
> It was quite common for this feature to be added to DOS ports of Unix
> programs, as DOS had a much lower limit than Unix on the maximum
> length of a command line.
Just to understand - does this allow to exceed the command limits?
Then it would be pretty helpful (as text files are easy to generate).
The idea is to have G_parser() recognise arguments of the form @filename, and read the file, treating each line the same way that it
would treat an argv[i].
would be equivalent[1], except that the former wouldn't run the risk
of exceeding any OS limit on the maximum length of a command line.
[1] Actually, they would interpret whitespace differently. The logical
implementation of @filename would treat each line as a single
argument. This is probably the most useful behaviour if you're
generating the arguments with commands, and eliminates the need to
provide a quoting mechanism (so long as you don't need to allow
newlines within an argument).
I can add sum of squares/cubes/etc to r.series easily
enough if there is a use for them.
well, sum of squares is useful so you can calculate variance & friends.
don't know of any use for cubes+.
r.univar/stats.c:
/* all these calculations get promoted to doubles, so any DIV0 becomes nan */
mean = stats->sum / stats->n;
variance = (stats->sumsq - stats->sum * stats->sum / stats->n) / stats->n;
if (variance < GRASS_EPSILON)
variance = 0.0;
stdev = sqrt(variance);
var_coef = (stdev / mean) * 100.; /* perhaps stdev/fabs(mean) ? */
adding sum of sq would let people calc that with r.series+r.mapcalc
manually.
not sure what components are required to calc kurtosis & skewness,
although I've an idea that they'd be possible with a single-serial-pass
construction method as s.cellstats had them (??).
> I can add sum of squares/cubes/etc to r.series easily
> enough if there is a use for them.
well, sum of squares is useful so you can calculate variance & friends.
don't know of any use for cubes+.
Skew needs sum(x^3), kurtosis needs sum(x^4).
r.univar/stats.c:
/* all these calculations get promoted to doubles, so any DIV0 becomes nan */
mean = stats->sum / stats->n;
variance = (stats->sumsq - stats->sum * stats->sum / stats->n) / stats->n;
if (variance < GRASS_EPSILON)
variance = 0.0;
stdev = sqrt(variance);
var_coef = (stdev / mean) * 100.; /* perhaps stdev/fabs(mean) ? */
adding sum of sq would let people calc that with r.series+r.mapcalc
manually.
not sure what components are required to calc kurtosis & skewness,
although I've an idea that they'd be possible with a single-serial-pass
construction method as s.cellstats had them (??).
Like variance, it's possible to calculate them in a single pass
(v.univar does so), but the inaccuracies of a single-pass calculation
will get worse with higher powers.