Details Ticket 5202


Comment | Reply | Take | Resolve


Serial Number 5202
Subject Bug with floating point maps in r.stats
Area grass6
Queue grass
Requestors soerengebbert@googlemail.com
Owner none
Status open
Last User Contact Wed May 9 21:26:03 2007 (1 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Thu Dec 6 00:58:07 2007 (1 yr ago)
Created Thu Oct 12 11:25:12 2006 (2 yr ago)

Transaction History Ticket 5202


Thu, Oct 12 2006 11:25:12    Request created by guest  
Subject: Bug with floating point maps in r.stats

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources

Hi,
there is a bug in r.stats.
The cell counting seems to be wrong.

Using the test suite mapset i get the following result:

Mapset <testmapset> in Location <TestLocation>                              
GRASS 6.3.cvs > g.region -p res=200

GRASS 6.3.cvs > r.mapcalc "stat_test=col()*1.0"

GRASS 6.3.cvs > r.stats -npc input=stat_test nsteps=10
 100%
1-1.9 10  12.50%
1.9-2.8 10  12.50%
2.8-3.7 10  12.50%
3.7-4.6 10  12.50%
4.6-5.5 10  12.50%
5.5-6.4 10  12.50%
6.4-7.3 10  12.50%
7.3-8.2 10  12.50%
8.2-9.1 10  12.50%
9.1-10 10  12.50%

GRASS 6.3.cvs > r.stats -npc input=stat_test nsteps=2
 100%
1-5.5 90 102.27%
5.5-10 10  11.36%  <------------ ???
                                                                            
GRASS 6.3.cvs > r.stats -npc input=stat_test nsteps=3
 100%
1-4 50  57.47%
4-7 40  45.98%
7-10 10  11.49%  <------------ ???

Best regards
Soeren
Thu, Oct 26 2006 02:22:22    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17727.65464.356813.878371@cerise.gclements.plus.com>
Date Thu, 26 Oct 2006 01:22:16 +0100
To Request Tracker <grass-bugs@intevation.de>
Cc grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #5202] (grass) Bug with floating point maps in r.stats
In-Reply-To <20061012092512.32B151005A3@lists.intevation.de>
References <20061012092512.32B151005A3@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
X-Spam-Level
Request Tracker wrote:

> this bug's URL: http://intevation.de/rt/webrt?serial_num=5202
> -------------------------------------------------------------------------
> 
> Subject: Bug with floating point maps in r.stats
> 
> Platform: GNU/Linux/x86
> grass obtained from: CVS
> grass binary for platform: Compiled from Sources
> 
> Hi,
> there is a bug in r.stats.
> The cell counting seems to be wrong.
> 
> Using the test suite mapset i get the following result:
> 
> Mapset <testmapset> in Location <TestLocation>                            
GRASS 6.3.cvs > g.region -p res=200
> 
> GRASS 6.3.cvs > r.mapcalc "stat_test=col()*1.0"
> 
> GRASS 6.3.cvs > r.stats -npc input=stat_test nsteps=10
>  100%
> 1-1.9 10  12.50%
> 1.9-2.8 10  12.50%
> 2.8-3.7 10  12.50%
> 3.7-4.6 10  12.50%
> 4.6-5.5 10  12.50%
> 5.5-6.4 10  12.50%
> 6.4-7.3 10  12.50%
> 7.3-8.2 10  12.50%
> 8.2-9.1 10  12.50%
> 9.1-10 10  12.50%
> 
> GRASS 6.3.cvs > r.stats -npc input=stat_test nsteps=2
>  100%
> 1-5.5 90 102.27%
> 5.5-10 10  11.36%  <------------ ???
>                                                                           
GRASS 6.3.cvs > r.stats -npc input=stat_test nsteps=3
>  100%
> 1-4 50  57.47%
> 4-7 40  45.98%
> 7-10 10  11.49%  <------------ ???

There appear to be several errors here, probably related to the fact
that the documentation for G_quant_* is at best vague, and at worst
gibberish.

E.g.:

> int G_quant_add_rule(struct Quant *q, DCELL dmin, DCELL dmax, CELL cmin, CELL
cmax)
> 
> Add the rule that the floating-point range [dmin,dmin] produces an
> integer in the range [cmin,cmax] by linear interpolation.

Saying "by linear interpolation" doesn't really tell you very much
when the result is an integer. Examining the code for
G_quant_get_cell_value() reveals that it uses C truncation (round
towards zero). So if you have the rule:

	G_quant_add_rule(q, 1.0, 10.0, 1, 2)

then inputs in the range 1.0 <= x < 10.0 return 1, while an input of
exactly 10.0 returns 2. This explains why nsteps=2 produces a 90/10
split.

The obvious question is whether the problem is with libgis'
quantisation code or with the way that r.stats is using it. The
programmers' manual doesn't help, and there is no reliable way to tell
whether any modules rely upon the current behaviour (searching for
explicit references to "G_quant" doesn't help, because
G_get_raster_row() etc use it, and just about everything uses those
functions).

Realistically, I think that r.stats needs to avoid using G_quant_*
altogether, and implement its own quantisation. Relying upon libgis'
quantisation code is asking for trouble.

The bogus ranges and the totals exceeding 100% are separate bugs.

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


Wed, May 9 2007 21:26:03    Mail sent by mneteler  
hi Soeren,

do you see a chance to give r.stats a kick? It's a pretty important module...
Markus
Wed, May 9 2007 22:34:32    Mail sent by soerengebbert@gmx.de  
Return-Path <soerengebbert@gmx.de>
Delivered-To grass-bugs@lists.intevation.de
X-Authenticated #5818486
X-Provags-ID V01U2FsdGVkX1/PfGc6+L/PCP+55R2sGH3pbBT04x+VwfGLdEiZ2E 4F7Qc4oIGHqlzb
From Soeren Gebbert <soerengebbert@gmx.de>
To Markus Neteler via RT <grass-bugs@intevation.de>
Subject Re: [bug #5202] (grass) Bug with floating point maps in r.stats
Date Wed, 9 May 2007 22:43:08 +0200
User-Agent KMail/1.9.5
References <20070509192603.215B81006D0@lists.intevation.de>
In-Reply-To <20070509192603.215B81006D0@lists.intevation.de>
MIME-Version 1.0
Content-Type text/plain; charset="iso-8859-15"
Content-Transfer-Encoding 7bit
Content-Disposition inline
Message-Id <200705092243.09411.soerengebbert@gmx.de>
X-Y-GMX-Trusted 0
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, score=-5 tagged_above=-999 required=3.5 tests=[BAYES_00=-5]
X-Spam-Score -5
X-Spam-Level
Hi Markus,
im very sorry, but im too short of time to fix r.stats. 
r.stats is a kind of complicated, so its not easy for me to find the bug. 
I re-implemented r3.stats from scratch, because r.stats was much too complex
for the 3d stuff.

soeren

Am Mittwoch, 9. Mai 2007 21:26 schrieb Markus Neteler via RT:
> hi Soeren,
>
>
>
> do you see a chance to give r.stats a kick? It's a pretty important
> module...
>
>
>
> Markus
>
> -------------------------------------------- Managed by Request Tracker


Thu, Dec 6 2007 00:58:07    User changed to soerengebbert@googlemail.com by mneteler  
Comment | Reply | Take | Resolve

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request