Bug#231730: floating-point value for max_val option is broken

[Niko Tyni]

reopen 231730
thanks

> now the colors are correct, but 'precision' does not work well: it just
> round the label so you end up with several time the same label if there
> is very few integral y values (say just 0 and 1).
 
> Just try this script:
 
> You get three y-labels 0 and 3 y-labels 1.

Yes. This is just what I would expect, given a precision of 0. What
did you expect? 

I pointed at 'precision' as a solution to the problem with the version
graph at

http://people.debian.org/~ballombe/popcon-new/

where there scale has (several) integers that are presented as floats,
apparently because the data consists of floating-point values.

Another, and possibly better alternative for this should be
'integer_ticks_only'. See below for that.

> The woody version did not have this problem.

My apologies, but I'm not sure what the problem is. The difference I see
between woody and sid in your example case is the automatic selection
of the maximum value in the graph.  The woody version uses a scale of
0 to 10 here, while the sid version uses 0 to the maximum value of the
data. The latter looks more predictable to me, and you can explicitly
get the old behaviour by setting

$obj->set ('max_val' => 10);

along with using 'precision' or 'integer_ticks_only'. 


In your other mail, you state:

> It seems the option "integer_ticks_only" does not work:

but for me it does. For example, your example script with data
consisting only of integers '0' and '1', the default behaviour without
'integer_ticks_only' is to have a scale of .2 units per tick (with a
precision of 3), while with 'integer_ticks_only', there are only the
ticks for '0' and '1'. Could you be more specific, please?

This is all getting a bit confusing, but I hope this helps.

Cheers,
-- 
Niko Tyni	ntyni at iki.fi