Hi,
consider the following example:
set samples 10 set xrange [0:10] f(x,y) = 2*x+y unset key set multiplot layout 3,1 plot '+' using 1:1:(f($1,$1)) with labels plot '+' using 1:1:(sprintf("%g", f($1,$1))) with labels plot '+' using 1:1:(f($0,$0)) with labels unset multiplot
The first plot is wrong, it doesn't show the output of f($1,$1)
but, probably, the values of column(1)
. The second expression with sprintf
works fine.
What puzzles me, and what made me think it might be a bug, was the third expression. That one evaluates the expression f($0,$0)
correctly.
Column 0 is treated as a special case because
1) it is always an integer
2) it would otherwise be hard to convert it to a string if you really did want it in a string.
I am a bit surprised that the special case intended to handle
plot ... using 1:2:0 with labels
also manages to catch f($0,$0).
Would you expect or prefer that your example commands 1 and 3 produced an error message rather than a plot?
Alternatively, the special case that catches $0 could be extended to catch all expressions that specifically return an integer. In that case your example 1 would still be an error, but int(f($1,$1)) would be handled. I don't really like that idea - the proper way to fix the command is to convert it to a string (your example 2) rather than converting to an integer.
Last edit: Ethan Merritt 2014-04-03
I don't know how to handle this properly. I just saw the problem, that in the current state it isn't very clear which number conversion works, and which not. Here some other cases:
The basic point is that all requests to plot "with labels" using numerical input are wrong. The question is whether the program should do the best it can even though the command is not quite correct or whether it should print an error and plot nothing at all.
The reason it happens to work for some input is that as a convenience the string handling code will silently convert integer values (INTGR) to a string representation of that same integer. The only assumptions needed are that it is a signed value to be represented in base 10. Converting a CMPLX value to a string would be far more problematic and so the program doesn't even try. Since the function column(N) and its short-hand version $N return a CMPLX value, you can't use these in place of a string.
Disregard for the moment that your examples use '+' for input. The result would be the same if there were a real data file containing
x1 y1 val1
x2 y2 val2
x3 y3 val3
...
The difference between the first command (using 1:2:3) and the second command (using 1:2:($3)) is that in the first case the third field in each line is read as a string that just happens to be a sequence of characters representing a number. No conversion is done. In the second case $3 gets translated to column(3), which explicitly means "read this as a complex value" and therefore using it as a string does not work.
"using 1:2:(stringcolumn(3))" would work in this case, and would be the same as "using 1:2:3".