[GRASS-dev] r.univar -g: output total as well

GRASS GRASS developer
1

Hi,

It would be nice to have the "total" output for
eval `r.univar -g rastermap`

svn diff raster/r.univar2/
Index: raster/r.univar2/stats.c

--- raster/r.univar2/stats.c (revision 38620)
+++ raster/r.univar2/stats.c (working copy)
@@ -108,6 +108,7 @@
     }

     if (param.shell_style->answer) {
+ fprintf(stdout, "total=%d\n", stats->size);
        fprintf(stdout, "n=%d\n", stats->n);
        fprintf(stdout, "null_cells=%d\n", stats->size - stats->n);
        fprintf(stdout, "min=%.15g\n", stats->min);

Any objections (say, may it break any scripts)?
Markus

2

Markus wrote:

It would be nice to have the "total" output for
eval `r.univar -g rastermap`

much faster:
  g.region -g | grep cells

but if r.univar was run for other purposes it doesn't cost
anything to also output that number.

Any objections (say, may it break any scripts)?

AFAICS in scripts/ only d.rast.edit.tcl uses a $total variable.
But maybe something in addons does. not sure

Hamish

3

On Thu, Aug 20, 2009 at 2:50 AM, Hamish<hamish_b@yahoo.com> wrote:

much faster:
g.region -g | grep cells

faster yes, but I am already running r.univar to get the other
numbers, so I can keep it simple.

On Thu, Aug 20, 2009 at 4:55 AM, Hamish<hamish_b@yahoo.com> wrote:

 if \(param\.shell\_style\-&gt;answer\) \{

+ fprintf(stdout, "total=%d\n", stats->size);
fprintf(stdout, "n=%d\n", stats->n);
fprintf(stdout, "null_cells=%d\n", stats->size - stats->n);
fprintf(stdout, "min=%.15g\n", stats->min);

FWIW I'd put it after n= so you see a nice ratio of the two a/b.

or maybe after null_cells=

n=
null_cells=
+________
total=

...

or to match `g.region -g` (and r.univar null_cells=) call it cells=
not total=

Sounds good. Submitted:

r.univar -g terra_lst1km20030624.LST_Day_1km.rst
n=5698
null_cells=821198
cells=826896
min=21.464111328125
max=29.8845901489258
range=8.42047882080078
mean=25.3690008519616
mean_of_abs=25.3690008519616
stddev=1.75958414427925
variance=3.09613636079894
coeff_var=6.93596154829724
sum=144552.5668544769

May I backport to 6.4 as well?
I checked this

cd scripts
grep r.univar */* | grep -v html | grep cell

Nothing seems to conflict.

4

Markus wrote:

Sounds good. Submitted:

r.univar -g terra_lst1km20030624.LST_Day_1km.rst
n=5698
null_cells=821198
cells=826896

great.

May I backport to 6.4 as well?

....

Nothing seems to conflict.

it seems pretty harmless, I don't see why not. But then again I thought
the same thing about r37726 when I committed it, and then trac #654
turned up. So lately I've been much more wary about backporting things
due to the wrath of unintended consequences. I figure we can always
let a few new trival features dribble in to 6.4.1 before being fully
strict about only allowing bug-fixes into the 6.4 branch- as long as
they are merged soon after the 6.4.0 release for maximum testing before
6.4.1.

But this one seems innocuous enough :slight_smile: your call

Hamish

5

> r.univar -g terra_lst1km20030624.LST_Day_1km.rst
> n=5698
> null_cells=821198
> cells=826896

does that %d (and n= and null_cells= above it) want to be %ld or something
to be LFS-safe?

fprintf(stdout, "cells=%d\n", stats->size);

e.g. IIUC signed int overflows at a sqrt(2^31) = 46341 x 46341 rows x cols
raster region size. Which people are getting closer to these days...

Hamish

6

On Thu, Aug 20, 2009 at 12:25 PM, Hamish<hamish_b@yahoo.com> wrote:

> r.univar -g terra_lst1km20030624.LST_Day_1km.rst
> n=5698
> null_cells=821198
> cells=826896

does that %d (and n= and null_cells= above it) want to be %ld or something
to be LFS-safe?

fprintf(stdout, "cells=%d\n", stats->size);

e.g. IIUC signed int overflows at a sqrt(2^31) = 46341 x 46341 rows x cols
raster region size. Which people are getting closer to these days...

Right - I guess that the entire output of r.univar needs to be revised for that.

Markus

7

Hamish:

> does that %d (and n= and null_cells= above it) want to be %ld or
> something to be LFS-safe?

....

> fprintf(stdout, "cells=%d\n", stats->size);
>
> e.g. IIUC signed int overflows at a sqrt(2^31) = 46341 x 46341
> rows x cols raster region size. Which people are getting closer to
> these days...

Markus wrote:

Right - I guess that the entire output of r.univar needs to be revised
for that.

not just the output, the innards as well. I see in global.h that both
n and size are plain signed int. Not sure why n was changed away from
being unsigned int, it used to be like that in the original C version.
(unsigned int would survive up to 65536x65536 cells, IIUC)

Also, I've been wondering whether to apply the %.7g for FCELL, %.15g
for DCELL output formats for r.univar min/max/stdev output as part of
trac #335.

Hamish