#2233 gprintf: inconsistencies with %t and %T

[theozh]

gprintf() shows some inconsistency with %t and %T and certain numbers.
If you run the following code (gnuplot 5.2.8, but also earlier versions, Win7/64) you will get inconsistent or wrong results.
To me this looks like a bug.

Code:

### inconsistency in gprintf with %t and %T
reset session

array Numbers = [0.95, 9.5, 95, 995, 9995]

print "gprintf with %t"
do for [i=1:|Numbers|] {
    print gprintf("% 8g",Numbers[i])." = ".gprintf("%t",Numbers[i])." x 10^".gprintf("%T",Numbers[i])
}
print "gprintf with %.3t"
do for [i=1:|Numbers|] {
    print gprintf("% 8g",Numbers[i])." = ".gprintf("%.3t",Numbers[i])." x 10^".gprintf("%T",Numbers[i])
}
print "gprintf with %.0t"
do for [i=1:|Numbers|] {
    print gprintf("% 8g",Numbers[i])." = ".gprintf("%.0t",Numbers[i])." x 10^".gprintf("%T",Numbers[i])
}
### end of code

Result: (with gnuplot 5.2.8)

    gprintf with %t
        0.95 = 9.500000 x 10^-1
         9.5 = 9.500000 x 10^0
          95 = 0.950000 x 10^2    # somehow correct but not the expected result
         995 = 0.995000 x 10^3    # somehow correct but not the expected result
        9995 = 0.999500 x 10^4    # somehow correct but not the expected result
    gprintf with %.3t
        0.95 = 9.500 x 10^-1
         9.5 = 9.500 x 10^0
          95 = 9.500 x 10^2    # simply wrong
         995 = 9.950 x 10^3    # simply wrong
        9995 = 9.995 x 10^4    # simply wrong
    gprintf with %.0t
        0.95 = 9 x 10^-1
         9.5 = 9 x 10^0
          95 = 1 x 10^2    # somehow ok, rounded. But why not 9 x 10^1, similar to 9.5?
         995 = 1 x 10^3    # ok, rounded
        9995 = 1 x 10^4    # ok, rounded

[Hans-Bernhard Broeker]

gprintf() shows some inconsistency with %t and %T and certain numbers.

That's because you're using it wrong. %t and %T are a pair; precisely to avoid problems like you see here they are coupled internally.

But that interaction can only work if you use both format in one gprintf call, not if you split that into two. I.e. your script must look like this:

print "gprintf with %t"
do for [i=1:|Numbers|] {
    print gprintf("% 8g",Numbers[i])." = ".gprintf("%t x 10^%T",Numbers[i])
}
print "gprintf with %.3t"
do for [i=1:|Numbers|] {
    print gprintf("% 8g",Numbers[i])." = ".gprintf("%.3t x 10^%T",Numbers[i])
}
print "gprintf with %.0t"
do for [i=1:|Numbers|] {
    print gprintf("% 8g",Numbers[i])." = ".gprintf("%.0t x 10^%T",Numbers[i])
}

That fixes all thee of the "simply wrongs". The remaining ones are expected, partly because "in computing, 10 time 0.1 is hardly ever 1.0".

[theozh]

just to illustrate that something is not as expected with %t and %T (even when used as a pair). Well, it's not directly gprintf().
Isn't the 0.95 x 10^2 somehow unesthetic and unexpected?

set yrange[80:100]
set format y "%t x 10^{%T}"
plot x

[theozh]

Thank you for your fast response.
Well, the fact that %t and %T can only be used as a pair does not become clear from the gnuplot documentation (help format specifiers). Maybe I missed the essential sentence and you can link me to it.

How would you explain the ytics in:

set yrange[80:100]
set format y "%t x 10^{%T}"
plot x

Although, I'm using %t and %T together, I get0.950000 x 10^2 for 95.
However, if I set format y "%.6t x 10^{%T}" get 9.500000 x 10^1 for 95.
Isn't this a bit inconsistent?

Actually, the original intention was to get the order of magnitude of a number.
For example: print floor(log10(1e6)) gives me 5. Because of rounding errors.
And instead of workaround with adding some small delta or multiplying with 1.0001,
I was hoping that gprintf("%T",number) would always give me the correct order of magnitude. But you are telling me that this is not the intended use of gprintf().

What would be in your opinion the reliable way in gnuplot to get the correct order of magnitude?
For example:
0.95 --> -1
9.5 --> 0
95 --> 1
995 --> 2
9995 --> 3

[Ethan Merritt]

Isn't that by definition equal to floor(log10(x)) ?
What am I missing?

[theozh]

What do you get, e.g. if you type print floor(log10(1e6))?

[Ethan Merritt]

Huh. I see. So it's mathematically correct but subject to imprecision in the binary representation of the floating point number. I should have realized.

Right now the documentation says:

 There are some problem cases that arise when numbers like 9.999 are
 printed with a format that requires both rounding and a power.

but it does not mention that you can avoid some of these problem cases by including both %T and %t in the same format string.