[GRASS-dev] Re: [GRASS-user] low radiance values after i.atcor and i.topo.corr

[Glynn Clements]

Markus Neteler wrote:

> >> > I would appreciate it if someone who understands i.cluster could test
> >> > the current version.
> >>
> >> (I have backported the changes to 6.4.svn for easier testing for me).
> >>
> >> The i.cluster continues to work for CELL maps.
> >>
> >> Here a test with the NC data set for FP maps:
> >
> >> Maybe my example is nonsense?
> >
> > Well, I don't actually understand what i.cluster does, so I couldn't
> > tell "sensible" output from garbage.
> 
> It does something like this:
> http://en.wikipedia.org/wiki/Cluster_analysis

Oh, I'm familiar with the general concept, k-means, etc. I'm just not
familiar with the specifics of i.cluster (e.g. whether it's finding
clusters in geographic space or colour space, what the output
signifies, etc).

> > However:
> >
> > 1. The behaviour for integer maps should remain unchanged.
> 
> Confirmed.
> 
> > 2. Simply converting an integer map to FP shouldn't affect the
> > results.
> 
> I suppose so.
> 
> > If the above aren't true, then I've introduced a bug somewhere.
> 
> No bug in the upper part. No bug at all, but missing feature (see below).
> 
> > Beyond that, is i.cluster linear? IOW, if you scale all inputs by a
> > constant factor, should you get "equivalent" results?
> 
> Indeed: results are simply divided by 10000. in this case.
> Since the precision doesn't suffice, it fails as all gets 0.00000x.
> 
> First class of integer map:
> #produced by i.cluster
> #Class 1
> 235
> 68.897872 50.136170 41.085106 18.565957 17.463830 14.174468 25.851064
> 9.425423
> 10.432770 18.562575
> 14.645481 23.813148 37.283324
> 8.686252 12.072177 21.374704 45.503110
> 11.581760 12.654519 23.242408 48.065430 74.796763
> 9.086270 8.638534 15.972268 27.007674 44.474286 32.136097
> 8.065921 9.900709 18.880251 28.033370 33.176214 19.970540 55.734133
> 
> First class of FP map (integer map divided by 10000. as in my example):
> #produced by i.cluster
> #Class 1
> 235
> 0.006890 0.005014 0.004109 0.001857 0.001746 0.001417 0.002585
> 0.000000
> 0.000000 0.000000
> 0.000000 0.000000 0.000000
> 0.000000 0.000000 0.000000 0.000000
> 0.000000 0.000000 0.000000 0.000000 0.000001
> 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000
> 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000001
> 
> What's needed since we cannot change the format

No? If the format was changed to %g (i.e. like %f for "typical"
values, like %e for particularly large or small values), it would
remain compatible with anything using scanf("%f"), atof(), strtod()
etc, as those functions all understand exponential notation.

[About the only plausible situation where switching from %f to %g or
%e can cause problems is when code tries to match FP literals against
a regexp such as "[0-9]+\.[0-9]*".]

> is a normalization related to the range (AFAIK in
> i.cluster/print2.c).

You would need to add an explicit scale= (e.g.) option. As there's no
way to pass the scale factor out to the user, the user would have to
pass the scale factor in.

OTOH, a scale= option and switching to %g aren't mutually exclusive;
but %g would largely eliminate the need for scale=, and would probably
be more useful.

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