[GRASS-dev] G_exp_colors()?

[Glynn Clements]

Hamish wrote:

> > Given that this seems to be specific to the use of G_log_colors(),
> 
> is it?
> 
> for the same data 'r.colors -e color=bcyr' only gets half way through the
> data range:

That's a completely different issue. Apart from anything else, -e uses
integer categories.

> > I suspect that the problem is due to slight errors in the calculation:
> ....
> > However, real arithmetic and floating-point arithmetic aren't quite
> > the same thing, and even the slightest error will cause the tests in
> > the lookup code to fail.
> > 
> > I can modify G_log_colors() to use special cases for i==0 and
> > i==samples (see attached patch).
> 
> Yes, that worked, this is the new colr/ file:

> or diff'd with the previous (r30909, G_add_d_..()):
> - % 0.010000000000000003677613769071 64.565417527653337970150460023433
> + % 0.010000000000000000208166817117 64.565417527653323759295744821429

Right; that makes sense. The difference corresponds to the bottom few
bits of a double.

> but now -g does bad things to the original CELL 0-65534 map:

You don't say ;)

log(0) is negative infinity; applying a logarithmic colour table to a
map which extends to (or below) zero isn't going to work.

> should it be like
>  	if (i == 0)
> -	    x = min;
> +	    x = exp(lmin);
> 
> etc. ?

No; if any change is required, it's more like:

	if (min <= 0)
		G_fatal_error(...)

> > Another option would be to add an extra rule at each end, so that any
> > values which are slightly out of range (by how much?) just use the end
> > colours.
> >
> > But I'm wondering if it would be better to handle this in the lookup
> > code, i.e. whether there should be an option for out-of-range colours
> > to use the colour for the corresponding extreme (min or max).
> 
> you will see in the above colr/ file examples there is:
> nv:255
> *:255
> 
> nv: is the color to use for null values, *: is the color to use for out
> of range.  (a single number there expands to n:n:n greyscale)
> 
> if we go slightly beyond min/max we will damage the *: functionality.

That's why I suggested it as an option.

I suspect that the default colour was intended primarily for use with
discrete categories; I'm not sure whether it makes much sense for
floating-point data.

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