#1755 special files clobber variable value

[Matthew Halverson]

Using gnuplot 5.0.3 (windows) suppose that we have a fresh console (just opened it) and run the following commands

x = 4
print x # shows 4
set xrange[0:3]
plot "+" u 1:1
print x # shows 3

It seems that the special file overwrites the variable x with each point generated (we would expect plot "+" u 1:(x) with lines to draw a horizontal line with y equal to 4, but it draws a diagonal line). Similarly "++" overwrites the values of x and y with each point generated.

There are cases where the user may wish to use these variable names and will be suprised that a = 3; plot "+" u 1:(a) with lines generates a horizontal line but x = 3; plot "+" u 1:(x) with lines does not.

I'm not sure if this behavior is by design (it allows one to do plot "+" u (x):(sin(x)) for example, but plot "+" u 1:(sin($1)) gives the same) or is a bug. I am sure that the variable names are being used internally to generate the values and that is why this is happening. More evidence of that is found by the fact that running (in a clean console) plot "+" u 1:1 as the first command, and then show variables shows that the variable x now exists when it didn't before.

If this isn't by design, I suggest using a variable name with the GPVAL prefix for generating these - GPVAL_GEN_x and GPVAL_GEN_y for an example.

[Karl Ratzsch]

I'm afraid this is by design, but you can change it if you want: The names of the independent variables (one for plot, 2 for splot) are defined by set dummy, and their default names are x and y.

[Karl Ratzsch]

On second thought: Is it necessary, or even useful, that the dummy variable is also generated as an actual gnuplot userspace variable during every plot?

Not that i would strongly advocate to change that, but I don't see any advantage in it.

[Ethan Merritt]

It is probably best to avoid x and y as variable names, because it is just asking for ambiguity.
Consider:
x = 2
plot x
Does that give you a horizontal line at y=2, or a diagonal line at y=x?

[Matthew Halverson]

Agreed. I just didn't know if these variables were supposed to be generated in "user space" overwriting user defined variables. It isn't a problem to use different variable names, however.

[Ethan Merritt]

There are FIXME notes in both the 2D and 3D code that say

    /* FIXME: This has the side effect of creating a named variable x */
    /* or overwriting an existing variable x.  Maybe it should save   */
    /* and restore the pre-existing variable in this case?            */

It's not clear to me how easy it would be to make such a change, and even if we did change it the issue of ambiguous intent is still unsolved. If the user puts an 'x' in a plot command, does it refer to a previously defined user variable or to the current x axis coordinate while plotting?

[Matthew Halverson]

I agree that your previous example would suggest some ambiguity, and works the way that it should (plot x plots the function f(x)=x not the constant equal to x, as it should). My concern was that when I do x = 2; plot "+" u 1:1 my value of x is overwritten even though I did not even refer to x in the plot command.

Either way, this is probably not a real high priority issue. It may be a good idea to put a note in the docs that "+" (and I'm sure "++" as well) will change the value of x (and probably y in the "++" case). That way it isn't a surprising effect.

[Karl Ratzsch]

Not only "+" and "++". Even a plot from a real data file initialises a variable "x" (to be 0.0)

undef x
plot dataf us 1:2
print x

Which is indeed a bit strange. With the special filename "+", you can use the dummy variable name in the using statement, btw.:

plot "+" using (x):(x**2)

Also here i don't see why the variable and its last value should appear in the gnuplot context afterwards. But, as you say, it's probably not worth the trouble changing that, as nobody should use the names of the dummy variables outside of a "plot" command anyway.

[Ethan Merritt]

Fixed in 5.1