GNOME Bugzilla – Bug 789076
minor ticks on logarithmic axes
Last modified: 2018-05-22 14:31:08 UTC
Created attachment 361699 [details] screen shot For a logarithmic axes, Gnumeric renders minor ticks in equal distance between the major ticks. This differs from the way Excel or LibreOffice (and virtually everybody else places the ticks. Excel and LO appear to place ticks at the positions corresponding to the values a + (b-a)/m * k with k = 1,2, ..., (m-1) where a and b are adjacent major ticks. That the spacing between a and the first minor tick is significantly larger than between the first two minor ticks. I have included a screen shot of LibreOffice's logarithmic scale. Excel's looks similar.
I guess I simplified the situation too much. In the example file we end up with the same as in LO. If I use Minimum=1, Maximum=12000, major=2, minor=9 I get the attached image in LO but only 1 minor tick in Gnumeric.
Created attachment 361700 [details] screenshot 2
This all becomes more obvious with minimum=1, maximum=120, major=0.3010299956639812, minor=4. PS: in comment 1 it should be 1200 instead of 12000.
Looks like this is actually a feature. Reading the code, I see that we have either 8 minor ticks or none. The user interface is very bad actually. If you ask for more than 8 minor ticks, you get 8, never more, and if you request less, you don't get any. There is a UI related bug : #414383.
Since there is no distinction between logarithmic base 10 and logarithmic base 8 axes, it doesn't make sense to consider specific minor ticks. log_{a}(x)=log_{10}(X)/log_{10}(x)=, so different bases would just scale the axis which is hidden by the fact that we specify minimum and maximum. So we should show minor ticks for any number of minor ticks. I know there is a prior "fixed" bug in which the discussion hinged on base 10. But that is really meaningless here. I believe in all cases: minor ticks are placed at the points corresponding to the values a + (b-a)/(m+1) * k with k = 1,2, ..., m where a and b are consecutive major ticks and m is the number of desired minor ticks.
I am not sure. Obviously your math is right, but what set of ticks is desired could well be different. For base 10 (100, 1000, ...) we surely want minor ticks for 20, 30, ..., 90 in the 10-100 decade. But for a base that is a power of 2, does anyone actually want ticks at (say) 2*64, 3*64, ..., 7*64? I.e., ticks that are equidistant in value space? I think I would prefer ticks that are equidistant in log space (and thus on the graph).
Specifically, if major ticks are a factor of 8 apart, it would make sense (to me) to have minor ticks a factor of 2 apart. Ie. major at x=1, 8, 64, ... minor at x= 2, 4, 16, 32, ...
Morten, there can surely be arguments be made for both equally spaced ticks before or after the logarithmic transformation. I just think we should be consistent or have a selector so that users can choose one or the other. In the moment we seem to sometimes use before some times after and sometimes none at all.
We can certainly add gui to choose, but that's not going to solve the problem for files we import from LO or XL. For better or worse, we still need a heuristic. testfile coming up showing. 1. A base-10 sample. 2. A base-2 sample. (complete with crazy rounding issue)
Created attachment 362099 [details] log axis test file
LO has equal distances prior to the transformation independent of the interval for the major ticks. So no heuristic needed for that. In fact we are currently discussing this issue in the ODF TC to better define the behaviour. I only looked at this in Gnumeric since the question is what implementations are in fact doing.
The crazy displayed precision has been fixed.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/326.