#1977 Different handling of binary operators or output of word(str,i) in gnuplot 5.2

[Alexander Stangl]

Hey!

I have encountered that there's a different handling of the binary operators == and != on Win7.
The following example works in gnuplot 5.0 patchlevel 3, but gives an error in gnuplot 5.2
str="1"; if(word(str,2)==1) {print 1} else {print 2}
Gnuplot 5.2 gives this error
"Non-numeric string found where a numeric expression was expected"

Or the output of word(str,i) with i>words(str) has been changed. Because converting word(str,2) into a number by adding +0 doesn't help either.
Was this intended to be like this?

Thanks for you help.

[Ethan Merritt]

word() returns a string, so you cannot rely on testing the return value with the numeric equality operator ==. Instead use the string equality operator eq

 if (word(str,i) eq "1") ....

However in your example word("whatever", 2) is strictly speaking not defined at all, since there is no 2nd word to return. It happens that both versions 5.0.3 and 5.2.0 return an empty string in this case but that is not documented and not guaranteed,

If a string happens to contain a recognizable number gnuplot will attempt to convert it to a numeric value if it is used in a numeric expression. But the empty string "" is not recognized as being a number.

Are you requesting that in a numerical context the empty string should evaluate to 0? I don't like that idea because in a case like:

  string = "1 0 4"
  if (word(string,i) == 0) { ...}

you have lost the distinction between a substring that happens to be "0" and an invalid substring or null string.

[Alexander Stangl]

Thanks for your answer Ethan!
It seems like version 5.0.3 used to evaluated an empty string to 0:

string = ""
print string+0

worked, while it is not possible anymore in 5.2.0. In principle you're right, that you loose the possibility to dinstinguish - eventhough I don't know how to do it without producing an error, so maybe it's better if it evalutes to 0 as it used to?