[GRASS-dev] G7: parameter standardization: n/count, min/minimum etc

neteler · October 7, 2013, 7:52pm

Hi,

we have the confusing situation of naming the same statistic in different ways:

r.series | r.statistics2 | t.rast.aggregate.* | t.vect.what.strds
...
    method Aggregate operation
             options: average,count,median,mode,minimum,min_raster,maximum,
                      max_raster,stddev,range,sum,variance,diversity,slope,
                      offset,detcoeff,tvalue,quart1,quart3,perc90,quantile,
                      skewness,kurtosis

r.in.lidar | r.in.xyz | r3.in.xyz | r.statistics
     method Statistic to use for raster values
               options: n,min,max,range,sum,mean,stddev,variance,coeff_var,
                        median,percentile,skewness,trimmean
               default: mean

I would suggest to streamline this (and personally opt for the
r.series way of naming the methods; e.g., the "n" is easily
overlooked, the "count" less so).
Also the order might be revisited and standardized...?

Markus

Pietro2 · October 8, 2013, 8:26am

On Mon, Oct 7, 2013 at 8:52 PM, Markus Neteler <neteler@osgeo.org> wrote:

r.series | r.statistics2 | t.rast.aggregate.* | t.vect.what.strds
...
    method Aggregate operation
             options: average,count,median,mode,minimum,min_raster,maximum,
                      max_raster,stddev,range,sum,variance,diversity,slope,
                      offset,detcoeff,tvalue,quart1,quart3,perc90,quantile,
                      skewness,kurtosis

r.in.lidar | r.in.xyz | r3.in.xyz | r.statistics
     method Statistic to use for raster values
               options: n,min,max,range,sum,mean,stddev,variance,coeff_var,
                        median,percentile,skewness,trimmean
               default: mean

I would suggest to streamline this (and personally opt for the
r.series way of naming the methods; e.g., the "n" is easily
overlooked, the "count" less so).

+1

Moreover min and max are functions in python, so from my point of view
it is much better minimum and maximum to avoid possible conflicts.

Pietro

Glynn_Clements1 · October 9, 2013, 12:10pm

Markus Neteler wrote:

we have the confusing situation of naming the same statistic in different ways:

r.series | r.statistics2 | t.rast.aggregate.* | t.vect.what.strds
...
    method Aggregate operation
             options: average,count,median,mode,minimum,min_raster,maximum,
                      max_raster,stddev,range,sum,variance,diversity,slope,
                      offset,detcoeff,tvalue,quart1,quart3,perc90,quantile,
                      skewness,kurtosis

r.in.lidar | r.in.xyz | r3.in.xyz | r.statistics
     method Statistic to use for raster values
               options: n,min,max,range,sum,mean,stddev,variance,coeff_var,
                        median,percentile,skewness,trimmean
               default: mean

I would suggest to streamline this (and personally opt for the
r.series way of naming the methods; e.g., the "n" is easily
overlooked, the "count" less so).
Also the order might be revisited and standardized...?

I suggest standardising on unabbreviated names. I'll look into using
the option-matching code for option values as well as names.

--
Glynn Clements <glynn@gclements.plus.com>

wenzeslaus · October 9, 2013, 2:29pm

We should also decide between mean and average. I vote for mean.

Here are some resources:
http://en.wikipedia.org/wiki/Mean

http://en.wikipedia.org/wiki/Average
http://stats.stackexchange.com/questions/14089/what-is-the-difference-between-mean-value-and-average

···

On Wed, Oct 9, 2013 at 8:10 AM, Glynn Clements <glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

we have the confusing situation of naming the same statistic in different ways:

r.series | r.statistics2 | t.rast.aggregate.* | t.vect.what.strds
…
method Aggregate operation
options: average,count,median,mode,minimum,min_raster,maximum,
max_raster,stddev,range,sum,variance,diversity,slope,
offset,detcoeff,tvalue,quart1,quart3,perc90,quantile,
skewness,kurtosis

r.in.lidar | r.in.xyz | r3.in.xyz | r.statistics
method Statistic to use for raster values
options: n,min,max,range,sum,mean,stddev,variance,coeff_var,
median,percentile,skewness,trimmean
default: mean

I would suggest to streamline this (and personally opt for the
r.series way of naming the methods; e.g., the “n” is easily
overlooked, the “count” less so).
Also the order might be revisited and standardized…?

I suggest standardising on unabbreviated names. I’ll look into using
the option-matching code for option values as well as names.

–
Glynn Clements <glynn@gclements.plus.com>

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Glynn_Clements1 · October 14, 2013, 5:44pm

Glynn Clements wrote:

I'll look into using > the option-matching code for option values as
well as names.

Done in r57999.

--
Glynn Clements <glynn@gclements.plus.com>

neteler · October 15, 2013, 9:13pm

On Mon, Oct 14, 2013 at 7:44 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Glynn Clements wrote:

I'll look into using > the option-matching code for option values as
well as names.

Done in r57999.

Is there any usage example?

Markus

Glynn_Clements1 · October 16, 2013, 5:40pm

Markus Neteler wrote:

>> I'll look into using > the option-matching code for option values as
>> well as names.
>
> Done in r57999.

Is there any usage example?

Rather than just allowing the entire option to be abbreviated to a
prefix, each word can be abbreviated individually, so e.g.
minimum_raster could be abbreviated to e.g. minr.

There remains the issue that if one option is a prefix of another, the
shorter option must always be given in full, as any abbreviation of it
will also be a valid abbreviation of the longer option, and thus
ambiguous.

Suggestions welcome.

--
Glynn Clements <glynn@gclements.plus.com>

wenzeslaus · October 16, 2013, 7:32pm

I have no suggestion but I just experienced problem with options.

I have options:

elevation
end_water_level

So, when I write
elev=… end_wl=…

I get
Sorry, <elev=> is ambiguous

Because I could write also
eleva=… eleve=…

which I’m really not going to do.

It is expected behavior but not exactly what I want. But let’s say that it is just disadvantage because writing
end_wl=
instead of
end_water_level= or end_w_l
is nice.

···

On Wed, Oct 16, 2013 at 1:40 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

I’ll look into using > the option-matching code for option values as
well as names.

Done in r57999.

Is there any usage example?

Rather than just allowing the entire option to be abbreviated to a
prefix, each word can be abbreviated individually, so e.g.
minimum_raster could be abbreviated to e.g. minr.

There remains the issue that if one option is a prefix of another, the
shorter option must always be given in full, as any abbreviation of it
will also be a valid abbreviation of the longer option, and thus
ambiguous.

Suggestions welcome.

–
Glynn Clements <glynn@gclements.plus.com>

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Glynn_Clements1 · October 17, 2013, 9:24pm

Vaclav Petras wrote:

I have no suggestion but I just experienced problem with options.

I have options:
* elevation
* end_water_level

So, when I write
elev=... end_wl=...
I get
Sorry, <elev=> is ambiguous

Can you try r58034?

This should ignore ambiguities if the given option is a prefix of
exactly one recognised option.

We might need something similar for option names.

--
Glynn Clements <glynn@gclements.plus.com>

wenzeslaus · October 17, 2013, 11:04pm

On Thu, Oct 17, 2013 at 5:24 PM, Glynn Clements <glynn@gclements.plus.com>wrote:

Vaclav Petras wrote:

> I have no suggestion but I just experienced problem with options.
>
> I have options:
> * elevation
> * end_water_level
>
> So, when I write
> elev=... end_wl=...
> I get
> Sorry, <elev=> is ambiguous

Can you try r58034?

This should ignore ambiguities if the given option is a prefix of
exactly one recognised option.

It reports still the same (I did the distclean to be sure). I wrote a small
script to test it (attached). I'm just not sure how to effectively run it
(without copying it into my dist.../scripts) and we should probably
integrated it into the library (library's test code).

Thanks,
Vaclav

We might need something similar for option names.

--
Glynn Clements <glynn@gclements.plus.com>

(attachments)

r.test.param.py (1.08 KB)

Glynn_Clements1 · October 18, 2013, 3:15pm

Vaclav Petras wrote:

> > I have options:
> > * elevation
> > * end_water_level
> >
> > So, when I write
> > elev=... end_wl=...
> > I get
> > Sorry, <elev=> is ambiguous
>
> Can you try r58034?
>
> This should ignore ambiguities if the given option is a prefix of
> exactly one recognised option.

It reports still the same (I did the distclean to be sure).

Sorry; I wasn't paying sufficient attention.

The recent changes only affected option values, where an option
(command-line parameter) has a fixed set of values (e.g. "method="
options). The ability to abbreviate option names has existed for some
time.

r58046 makes a similar change for option names.

--
Glynn Clements <glynn@gclements.plus.com>