GNOME Bugzilla – Bug 700598
depending on insignificant digits, tick label sometimes disappears
Last modified: 2013-05-19 04:38:46 UTC
Created attachment 244651 [details] spreadsheet to exhibit axis bugs A) As shown in the attached example, setting the axis bounds max to 0.150000001 leads to the uppermost tick label disappearing. B) In contrast, it works OK to use 0.15000001 (i.e. same as above, except with one fewer zero). C) Tangential remark: Using 0.15 results in correct tick labels, but has other problems as discussed in a separate bug report. Note that these numbers are well within the range of representable IEEE floats, and even if they weren't, Case (A) should be in no way worse than 0.15.
The other bug alluded to in item (C) now has a number: Bug 700599
Note that A has really nothing to do with "0.150000001". You will see the same effect with just "15". At least in current git you do not get a tick mark at 15 if you change the maximum to 15.
This is not a bug. With a linear map, ticks are at i * step with i an integer which might be negative, so the last tick would be at 0.150000003 which is larger than 0.150000001, the set maximum. If you set the minimum to -0.150000001, the first tick disappears, which is just logic. Andreas, I don't see your point.
Jean, the original report sounded like there is something special about 0.150000001 when the behaviour is the same as with 15; as you explained since both are less than 0.150000003.
May I ask /why/ the last tick "would be at 0.150000003" ? Why not 0.15000000000001 ??? Or perhaps more to the point, why not 0.5*3, which according to gnumeric comes out to 0.15000000000000002220 ??? Or why not just do the reasonable thing, which is to plot the tick label ????? > is just logic. Usefulness, style, and grace have a logic of their own. Just because this behavior is a foreseeable consequence of the way the code is written doesn't make it "logical". It just means the code is badly written. More-or-less every other graphics package on the planet uses integer arithmetic to decide how many ticks to plot, and *then* calculates what the tick label should be. Holding the tick label hostage to the vagaries of rounding of insignificant digits is not "logic" ... it's just bad design.
This is not really on topic, but where do you see "0.5*3, which according to gnumeric comes out to 0.15000000000000002220 ??"? If I enter =0.5 *3 then on 30 decimals I see 1.5000...000.
John, in your sample file you have Major ticks: 0.050000001. So you are asking for ticks every 0.050000001, in other words at 0, 0.050000001, 0.100000002, 0.150000003.
I can't quite follow your argument re integer arithmetic. You are asking for a strange value of "Major Ticks" Why aren't you using 0.05?
Created attachment 244680 [details] multiply 0.05 by 3
In answer to the tangential question: > This is not really on topic, but where do you see "0.5*3, which > according to gnumeric comes out to 0.15000000000000002220 ??"? > If I enter =0.5 *3 then on 30 decimals I see 1.5000...000. Answer: Please check your decimal point. Or check cell A1 in the new attachment. ====================== As to the on-topic question, I now see the point about the major tick spacing. This is an unfortunate artifact of my attempts to work around Bug 700599. So I would be happy to merge this whole discussion into Bug 700599. I have learned something about the workaround: it is necessary to add something small to the bounds, and then add something /even smaller/ to the tick spacing. I don't "really" want a strange tick spacing; all I want is a workaround that allows me to use manual scale settings. This is important, because I need to be able to change the data and compare the results graphically, without having the scale change behind my back.
You had written 0.5 * 3, and 0.5 is exactly representable in base 2 so you should not see anything you might find surprising. Of course 0.05 is not exactly representable in base 2 so you are really working with a number that is in fact slightly larger than 0.05. I would completely agree that bug #700599 is a bug, one should be able to set manual values to the values that currently happen to be the automatic ones.