After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 590908 - minor ticks in log plot
minor ticks in log plot
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: Charting
git master
Other All
: Normal normal
: ---
Assigned To: Emmanuel Pacaud
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2009-08-06 06:43 UTC by Andreas J. Guelzow
Modified: 2009-08-07 18:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andreas J. Guelzow 2009-08-06 06:43:38 UTC
Consider the data:
1	1
2	2
3	4
4	8
5	16
6	32
7	64
8	128
9	256
10	512

Create an XY plot and make the y-axis logarithmic.

Rather than using automatic minor ticks, set teh minor ticks to 8 -> works
to 6 -> no minor ticks
to 16 -> still 8 minor ticks...

If you set major ticks to 2, I can't fin any working minor ticks.
Comment 1 Morten Welinder 2009-08-06 14:40:47 UTC
map_log_calc_ticks is the decider.

In base-10 mode, you either get 8 minor ticks or you get none.  This is as
you observe.  They correspond to {2,3,...,9}*10^n.  For 8 ticks that is
natural for a base-10-thinking human.  With any other number of minor
ticks, I do not know where you would want the minor ticks.  Enlighten me,
please.

If you are not in base-10 mode -- set major ticks to log10(2), for example --
then the rules are different.  You get N equidistant (in log space) ticks.
In some cases, that actually makes sense: major=log10(4), minor=1, for
example.  That gives you minor ticks at 2.

I like things this way, but if you have better ideas I am all ears.
Comment 2 Andreas J. Guelzow 2009-08-06 17:22:45 UTC
I don't use logarithmic axes. So 8 minor ticks is not a problem with me. 

The primary problem is the interface: if there are only two choices, minor ticks or not, we really shouldn't have a spin button allowing us to pick various numbers.

If we have major ticks every second decade, it would make sense to have 17 minor ticks though (8 in each decade and one in place of the missing major tick) and that doesn't seem to work either.

I run ito this while trying to fix 563275 and testing whether the suggestion there is correct.
Comment 3 Morten Welinder 2009-08-07 13:03:57 UTC
> If we have major ticks every second decade, it would make sense to have 17
> minor ticks though (8 in each decade and one in place of the missing major
> tick) and that doesn't seem to work either.

And, in fact, 8 is a fairly bad choice in that case.  We should probably
use 9*N-1 unless that is too big, in which case N-1 should do.
Comment 4 Morten Welinder 2009-08-07 18:26:46 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.


Now we can have 0, N-1, or 9N-1 minor ticks in base-10 mode.