Re: Plans for gnuplot version 5 [integer division]

[Tait <gnu...@t4...>]

The root question is, what do gnuplot's users expect?

The example of Python just illustrates one point in the landscape of
tools that are used for data analysis, graphing, and numerical
computation. My sense is that Python is one of gnuplot's "peers" in
this respect, and probably among the most-frequently-used alternatives
to gnuplot.

I don't think most gnuplot users are familiar with C, so while
gnuplot's mannerisms mirror C*, that's meaningless to many users.
Users expect division to promote-to-float as necessary because all the
other tools they are familiar with do it that way, from their paper
and pencil to their calculator to WolframAlpha to R. If gnuplot were
were not an anomaly, there would be no surprise and confusion at its
current behavior, but there is.

If you don't agree with the users-expect argument, consider
consistency. Imagine you have:
  f(x) = (x/2)**2 - x + 3
The return value f(x) will be different depending on x's type. That
is not C-like (where functions can have only a single return type) and
it makes it difficult to work with f(x), because f(1) is different
from f(1.0). (To make f(x) predictable, one must use: f(x) =
(1.0*x/2)**2 - 1.0*x + 3.)

Currently, function inputs tend to be floats because $1,$2,... return
a float, but if gnuplot gains array support it will less commonly true
that inputs are already float and so predictability of function output
will become more important.

Further, gnuplot built-in functions don't exhibit this same ambiguity.
For example log10() returns a float, even when it could return an int:
log10(100) => 2.0; real() always returns float, even with int
arguments: real(1) => 1.0. Users might be misled into expecting the
same consistency from user-defined functions.



* It's not even true that gnuplot's mannerisms mirror C. C is a
statically-typed language. Variables and arguments have a known and
unchanging type at the time of their declaration. Gnuplot has no such
facilities; types are undeclared and inferred dynamically, which is
all the more reason to expect dynamic, rather than static, typing
behaviors throughout.

> [shrug]
> Most of gnuplot's math syntax follows C, and the distinction between
> (int) and (float) also follows C. 
> I don't think that pulling in examples from python is relevant;
> languages all have their quirks and even a kitchen-sink tool like
> perl cannot simultaneous mimic all of them.