#1667 format specifier "% h" broken for ticslabels
(see also bug #1518, I'm not sure if this was not in fact the identical problem, only fp precision really was not the cause.)
The format specifier "% h" does somehow not round the minimally imprecise ticslabels appearing in logscale mode to usably even values. "%h" works OK, so does "% .h", and "%H" with or without the " " modifier.
set multi layou 1,5
set logsc y
do for [fs in '"%h" "% h" "% .h" "%H" "% H"'] {
set format y fs;set title fs;plot [0:12] exp(-x) notit}
unset multi
I cannot reproduce this in the gprintf() function, seems to be somewhat specific to the ticslabels.
Btw., is there a reason why the default format specifier "% h" has the space as modifier? As I see this only makes sense if the y2 axis has positive and negative numbers, where it lines up the decimal points.
Everywhere else, it has no effect (y1 axis), misaligns the labels (x) and leaves a too big space between axis and labels (y2)
#set format "%h" #uncomment do see the difference
set y2tics; set ytics nomirr; set xtics 1
plot [-4:4] x**2, x**2 axes x1y2
Could you attach a copy of the output that shows a problem?
The output I get here looks correct. The different formats are, well, different, but none is obviously more or less correct that the others. For this particular plot ranges I would actually prefer "%.1lx10^{%L}", and maybe it would be worth adding a shorthand version of that.
Thanks for reminding me about Bug #1518. I have a patch for that kicking around that I never applied because HBB applied a different fix, but I think it still needs a final sanity check that the precision of the format does not exceed the precision of the floating point representation.
(png output attached from 5.0cvs, 5.1 looks identical.)
The "% h" format string just does not work for me on some plots, i.e. axis ranges/ticslabels. Surely it should be identical to "% H", except for the multipication sign?
Somehow the function gprintf() in src/util.c:539 gets tripped up by that space. Or is it somewhere else? Because
gives "0.1"
A special format specifier that always does the enhanced mode exponential notation output would sure be handy.
Last edit: Karl Ratzsch 2015-08-31
Got it. Here is the explanation. The string "% h" (note the extra space) is a magic value that really means "default tic format". It is not treated as "%h" with a space in front of it. This was probably a bad idea, but it allowed the previously existing code to distinguish the default state from a format provided explicitly by the user. The idea was that if the user provides a poor format (e.g. too much precision), use it anyhow. But if the program itself is generating the format then replace the default if needed in order to provide an appropriate number of decimal places. At the same time other places in the code that do not bother to check against the default string can just use it as-is. Maybe there are no such places any more; I'm not sure.
Some possible options.
1) Leave it. Output such as in your test case is not so much "wrong" as "unexpected".
2) Leave it but adjust the criteria for choosing an appropriate number of decimal places.
3) Continue treating "% h" as a magic value, but substitute something other than the %f variant shown above. For instance some variant of %l + %L
4) Replace "% h" with a different magic string, maybe "default", and make sure that nowhere in the code tries to use it as an actual format. This would reduce the surprise element, since "% h" really would act like "%h" with a space in front. But it doesn't address the question of what format exactly to generate when the magic string "default" is encountered.
5) Maybe the default should act differently in the case of log-scale axes.
That was what I meant by "%.Nlx10^{%L}". But it could be smarter about recognizing that "x10^0" can be omitted or replaced by blank space.
Ah! I've set the format string to "%h" in "~/.gnuplot" for my day work, and this sometimes leads to ticslabels with too few digits, because it does not get replaced as you describe.
Here's an idea: The "%h" format could regard no number of decimals specified (i.e. no decimal point in the format string) as the new "default" state, where then only the number of decimals gets adjusted as necessary for the present data, but not the whole format switched to "%f" any more.
Btw., the number of decimals is also not handled correctly at the moment by "%h":
Last edit: Karl Ratzsch 2015-09-01
That would be backwards. You already get %h format, which is "some variant of %l + %L", if the above does not replace anything.
When the above code was originally added, %h didn't exist yet. Back then the default format was "% g". But the logic is essentially the same. %h just supports enh text automatically. Now, %g format is defined to automatically switch between float and exponential forms, based on the number of characters needed to display the result. That definition is where the limit of 4 in the above snippet comes from. The only thing new the "patch default format" feature really does is make sure that the same format works for all the tics on an axis. I.e. it avoids mixing %f and %e format on one axis.
Last edit: Hans-Bernhard Broeker 2015-08-31
I think "% h" should definitely act as the documentation says, and not do some unexpected automagic. I agree it's not a pressing problem. But just to separate the two issues, the introduction of a new default format "%a" would be nice.
Two small things in the docs of the format specifiers:
My pocket calculator refers to what is the "%T" format as scientific power (SCI), and "%S" (exponent multiple of 3) as engineering (ENG). Wikipedia https://en.wikipedia.org/wiki/Engineering_notation agrees with my TI-30, so i think this is a mixup in gnuplot's docs?
And the docs say "Some systems may not support all of these modifiers but may also support others; in case of doubt, check the appropriate documentation and then experiment." , which applies to the sprintf() format strings, which are defined in the C library, but is that really true for the gnuplot-specific formats?