[GRASS-dev] Re: r.univar: allow multiple rasters to be processed
> Glynn Clements <[EMAIL PROTECTED]> writes: > I tried running r.univar on the same map for comparison, but it > crashed while trying to compute the percentile (the other > statistics were computed okay). [...] >> qpos_perc[i] = (int) (stats->n * stats->perc[i] / 100. - 0.5); [...] >> Here, it should rather be, e. g.: >> qpos_perc[i] = (int) (stats->n * 1e-2 * stats->perc[i] - 0.5); > Right. I've now committed the change: http://trac.osgeo.org/grass/changeset/30605 [...] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: r.univar: allow multiple rasters to be processed
> Glynn Clements <[EMAIL PROTECTED]> writes: Is there some fundamental reason why r.univar has separate cases for CELL/FCELL/DCELL types, rather than just working in DCELL throughout? >>> I can't remember with any certainty why I did it that way; it's >>> been like that since the first CVS checkin. >> Please consider the following patch. >> RASTER_MAP_TYPE map_type; >> +void *all_values >> + = ((! param.extended->answer) ? 0 >> + : (map_type == DCELL_TYPE) ? stats->dcell_array >> + : (map_type == FCELL_TYPE) ? stats->fcell_array >> + : stats->cell_array); > map_type hasn't been initialised yet. There's no reason why it can't > be initialised in the declaration, i.e.: > RASTER_MAP_TYPE map_type = G_get_raster_map_type (fd); [...] > We have G_raster_size() for this: [...] > all_values is a void*, and arithmetic on a void* isn't permitted by > ANSI C (gcc allows it as an extension). > We have G_incr_void_ptr() for this, e.g..: > memcpy(G_incr_void_ptr(all_values, stats->n * value_sz), ptr, > value_sz); > Or you can just make it a char* instead. Yes, thanks. I hope to test the corrected patch within a few days. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: r.univar: allow multiple rasters to be processed
Ivan Shmakov wrote:
> >>> I tried running r.univar on the same map for comparison, but it
> >>> crashed while trying to compute the percentile (the other
> >>> statistics were computed okay).
>
> >> Is it due to the memory allocation issues, or?
>
> > I don't know. 30m cells * 8 bytes per cell = ~240MiB. The system has
> > 1GiB of swap, so malloc() shouldn't fail.
>
> $ nl -ba stats.c
> ...
>135/* TODO: mode, skewness, kurtosis */
>136if (param.extended->answer) {
>137qpos_perc = (int *) G_calloc(stats->n_perc,
> sizeof(int));
>138quartile_perc = (double *) G_calloc(stats->n_perc,
> sizeof(double));
>139for (i = 0; i < stats->n_perc; i++) {
>140qpos_perc[i] = (int) (stats->n * stats->perc[i] /
> 100. - 0.5);
>141}
> ...
> $
>
> Here, it should rather be, e. g.:
>
>qpos_perc[i] = (int) (stats->n * 1e-2 * stats->perc[i] - 0.5);
Right.
> (BTW, would it benefit from an explicit round ()?)
I don't think so. Also, just removing the -0.5 would give the same
result as round().
--
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: r.univar: allow multiple rasters to be processed
> Glynn Clements <[EMAIL PROTECTED]> writes:
>>> I tried running r.univar on the same map for comparison, but it
>>> crashed while trying to compute the percentile (the other
>>> statistics were computed okay).
>> Is it due to the memory allocation issues, or?
> I don't know. 30m cells * 8 bytes per cell = ~240MiB. The system has
> 1GiB of swap, so malloc() shouldn't fail.
$ nl -ba stats.c
...
135 /* TODO: mode, skewness, kurtosis */
136 if (param.extended->answer) {
137 qpos_perc = (int *) G_calloc(stats->n_perc, sizeof(int));
138 quartile_perc = (double *) G_calloc(stats->n_perc,
sizeof(double));
139 for (i = 0; i < stats->n_perc; i++) {
140 qpos_perc[i] = (int) (stats->n * stats->perc[i] / 100. -
0.5);
141 }
...
$
Here, it should rather be, e. g.:
qpos_perc[i] = (int) (stats->n * 1e-2 * stats->perc[i] - 0.5);
(BTW, would it benefit from an explicit round ()?)
Otherwise the result of the multiplication overflows the `int'
type:
(30 \cdot 10 ^6) \cdot 90
\approx (2 ^5 \cdot 2 ^{20}) \cdot (2 ^6 + 2 ^5)
> 2 ^{25} \cdot 2 ^6
= 2 ^{31}
[...]
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: r.univar: allow multiple rasters to be processed
> Glynn Clements <[EMAIL PROTECTED]> writes: [...] >> Anyway, I guess I may commit my patch? I believe that the other >> issues you've mentioned should be resolved by separate changesets. >> (And I joyfully commit the ``double'' cast patch personally.) > Agreed. I've now committed both of the changes: http://trac.osgeo.org/grass/changeset/30383 http://trac.osgeo.org/grass/changeset/30384 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: r.univar: allow multiple rasters to be processed
> Hamish <[EMAIL PROTECTED]> writes: >> Anyway, I guess I may commit my patch? > I am curious to know about in what real-world application it is > useful to use multiple input maps for r.univar? Is it for a time > series of the same variable? Yes, as well as for the case of ``segmented'' dataset. > And how does that relate to r.series? Which method is more useful? > e.g.: > r.univar in=1,2,3,4 | grep mean >vs > for MAP in `g.mlist` ; do r.univar $MAP | grep mean ; done > RESULT=`bc average($mean_list)` #pseudo >vs > r.series in=1,2,3,4 out=mean_map method=average && r.univar mean_map > just wondering, Hamish Allowing multiple rasters to be specified saves one from using a temporary raster map for the result of `r.series' or `r.patch'. Also, the calculation of the standard deviation with the help of `r.series' or some Bash code like the above is hardly an obvious thing. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
