#359: r.quantile computes incorrect values with default number of bins
------------------------+---------------------------------------------------
Reporter: dylan | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Keywords: r.quantile | Platform: Linux
Cpu: x86-32 |
------------------------+---------------------------------------------------
I noticed that when computing quantiles from a highly skewed distribution,
incorrect values are returned with the default number of bins. Reducing
the number of bins seems to correct the problem
Example, based on attached raster file in GRASS ASCII format:
#359: r.quantile computes incorrect values with default number of bins
----------------------+-----------------------------------------------------
Reporter: dylan | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: | Keywords: r.quantile
Platform: Linux | Cpu: x86-32
----------------------+-----------------------------------------------------
Comment (by glynn):
Replying to [ticket:359 dylan]:
> I noticed that when computing quantiles from a highly skewed
distribution, incorrect values are returned with the default number of
bins. Reducing the number of bins seems to correct the problem
>
> Example, based on attached raster file in GRASS ASCII format:
[snip]
I cannot reproduce this. I always get the second set of values regardless
of the number of bins used:
#359: r.quantile computes incorrect values with default number of bins
-------------------------+--------------------------------------------------
Reporter: dylan | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Resolution: worksforme | Keywords: r.quantile
Platform: Linux | Cpu: x86-32
-------------------------+--------------------------------------------------
Comment (by hamish):
I'd be very cautious about ignoring this one and assuming that it
magically healed itself. Silent data corruption is rather nasty when you
base other work on it.
The URL test dataset is no longer active, so I can't help test.
I wonder if "g.region rast=inputmap" might help though.