A string that contains an integer is not converted to integer but floating point variable if used as a numerical expression, contrary to what the help on "expressions" says.
gp> print "1"+1
funnily, "index" accepts floating point numbers (but not strings).
"word("1 2",n)" on the other hand gives an error if n is a real instead of an integer, so you have to use "word("1 2",int(n))" if n is a string.
auto-promotion of string to INTGR rather than CMPLX fixed in cvs for 4.6 and 4.7
index accepts strings but interprets them as referring to a delimiter in the data dile. See "help index". Auto-promoting the string to a number would make the command ambiguous.
I consider that behaviour of "word" to be correct, but you are welcome to go ahead and make an argument for something different. What would you expect from passing a non-integer? Rounded value? Truncated value?
no, the behaviour of word() is correct, imho.
i merely wondered about "index" accepting a float. i say i doesn´t hurt, but neither would passing a counter=1.0 to word(). Just feels strange.
Ah, OK. That's the reverse of what I understood from your original comment.
The routine that parses "index" calls uses a helper routine int_expression() to read the values from the input line. The same helper routine is used when parsing most [all?] other commands. So the treatment of numerical input is consistent. Changing that one helper routine to enforce truly integer input would affect all input, not just the values used by "index". I don't see a strong reason to make this change, but maybe I'm missing something.