Re: Plans for gnuplot version 5 [integer division]

[Jonathan T. <jt...@as...>]

Tait wrote:
> I don't think most gnuplot users ...

I replied:
| The problem is that we don't have any *data* on what "most gnuplot
| users" expect, nor on "all the other tools they are familiar with".
| We only have conjecture.

Tait then asked:
> Indeed; I speak from my experience. Is your experience different?

Yes, my experience is different: all the gnuplot users I know come
from C/C++/Fortran backgrounds, where integer division truncates.
But I don't know the background of the "median gnuplot user".



A different point:

I suggested reviving an old suggestion of Dave Denholm:

: Date: Thu, 05 Aug 2004 17:50:43 +0100
: From: Dave Denholm <dde...@es...>
: Reply-To: gnu...@li...
: To: gnu...@li...
: Subject: Re: [Gnuplot-bugs] Interpretation of commandline numbers
:
: I wonder if it is worth putting in special
: code to detect division of two integer constants, and warn once per
: session. (every evaluation would obviously be too often)

Ethan Merritt pointed out a difficulty with this:

> Limiting this to integer constants would be tricky.
> By the time the evaluation code sees the division operation,
> the two operands have already been evaluated. I don't think there
> is any way to tell at that point whether these were "constants" or
> "result of integer expression" or "extracted from a user variable".

Dave Denholm's original message went on to say:

: Just a quick scan over the action table after parsing, to detect the
: sequence  (puchc int), (pushc int), div
: 
: gnuplot> show at x/3.0 + 10/3 
: 
:         push x
:         pushc 3.0
:         div
:         pushc 10
:         pushc 3
:         div
:         plus
: 
: 
: Or even - when appending the 'div' action, peek back at the previous
: two entries.
: 
: This isn't going to catch the sequence
: 
: x=13
: print x/3
: 
: but it might stop the user scratching their head for too long if they
: then resort to typing in things like
: 
:   print 13/3


Another alternative would be to warn the first time an integer division
yields a result which
(a) is not an integer or very close to an integer,
	[We could use the "set zero" value as a tolerance to
	define "very close to an integer", i.e.,
  	  very_close_to_integer(x)
	      := ( abs(x-nearest_integer_to_x) <= tolerance*max(1,abs(x)) )
	(This definition is borrowed from APL; the "max(1,"
	is to properly handle values close to zero.)]
    AND
(b) is *not* immediately passed to floor(), ceil(), or int()
	[these seem to be the only builtin functions which
	convert a real number to an integer.]

Implementing (b) would require the division operator to look back down
in the evaluation stack.  This is a kludge.  But it would warn on
  x = 4
  y = 5
  print x/y

If we did such a warning then probably the warning should mention that
taking int(), floor(), or ceil() of the integer-division-result would
silence the warning.  And having a separate control to disable the
warning altogether might also be useful.



But having said all this, my preference is to either
(a) leave the current behavior unchanged, or
(b) introduce a new global mode
      set integer_division [ truncates | promotes ]

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"