[Bug] r.univar returns nan for rasters with only negative values

[wenzeslaus]

Describe the bug

For rasters with only negative values, r.univar returns nan for maximum and range.

For positive values and a mix of positive and negative values, the module returns expected max and range values.

To Reproduce

grass -c ~/grassdata/nc_spm_08_grass7/test1

GRASS nc_spm_08_grass7/user1:grass > r.mapcalc "negative_const = -1"
 100%
GRASS nc_spm_08_grass7/user1:grass > r.mapcalc "negative_random = rand(-1, -0.01)" -s
 100%
GRASS nc_spm_08_grass7/user1:grass > r.univar negative_const
 100%
 100%
total null and non-null cells: 277200
total null cells: 0

Of the non-null cells:
----------------------
n: 277200
minimum: -1
maximum: nan
range: nan
mean: -1
mean of absolute values: 1
standard deviation: 0
variance: 0
variation coefficient: -0 %
sum: -277200
GRASS nc_spm_08_grass7/user1:grass > r.univar negative_random
 100%
 100%
total null and non-null cells: 277200
total null cells: 0

Of the non-null cells:
----------------------
n: 277200
minimum: -0.999997
maximum: nan
range: nan
mean: -0.505264
mean of absolute values: 0.505264
standard deviation: 0.285897
variance: 0.0817371
variation coefficient: -56.5837 %
sum: -140059.082419107

Same with the g flag.

Expected behavior

Maximum and range computed.

System description

• Operating System: Linux
• GRASS GIS version: main branch

I didn't do a full git bisect, but 8.2.0 is good and 8.3.0 is bad.

[neteler]

Here's a candidate, in preparation for CMake support:

• cmake support preparation: use of INFINITY and NAN (checks: Use of INFINITY and NAN instead of divisions #2681), merged Jan 16, 2023
  • which was extracted from WIP PR [WIP] CMake build with Visual Studio support #289

Then 8.3.0 was released on Jun 24, 2023.

[wenzeslaus]

I did git bisect and it is indeed you guess: a946ca6 (#2681)

git bisect

Test script test_for_bisect.sh (assuming the data from above):

#!/bin/bash
cd raster/r.univar
make && /.../bin.x86_64-pc-linux-gnu/grass /.../grassdata/nc_spm_08_grass7/test1/ \
   --exec r.univar negative_random \
   | grep -E "maximum: [-0-9\.]"

git bisect start
git bisect good 8.2.0
git bisect bad 8.3.0
git bisect run bash test_for_bisect.sh

After a while of crunching, it yields:

a946ca6bb7da6721617a43cf94ae4f67edc5d416 is the first bad commit

[neteler]

Maybe @nilason and/or @metzm can help with the nan magic?

[nilason]

Your bisect approach looked nice, but somehow it missed the failing commit. I manually traced it to 7a51911.

[echoix]

Could we have a small unit test for this bug, it seems important since it meant bad results were returned.

I consider this issue as something that should be handled with the errata procedure.

[wenzeslaus]

Your bisect approach looked nice, but somehow it missed the failing commit.

How funny! I won't be investigating where the issue was. It looked reasonable since that was what Markus was guessing.

[wenzeslaus]

I consider this issue as something that should be handled with the errata procedure.

We still need to specify what errata means. In my mind, errata concept is for bugs which are non-obvious results which are wrong. This one you can see just like if the output formatting would be broken in some way, so I was not thinking errata here.