Re: Plans for gnuplot version 5 [integer division]

[sfeam <sf...@us...>]

On Thursday, 17 April 2014 09:50:14 PM Jonathan Thornburg wrote:
> 
> 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.

Ugh.  Seriously?   That amounts to examining every partial expression 
in the stack on the off chance that one of them matches a known pattern.
And it would still fail on the logically equivalent case
gnuplot> show at 10/(1+2) 
        pushc 10
        pushc 1
        pushc 2
        plus
        div

> : 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

Heh.  It would probably just add to any confusion.
"Given A=10; B=3;  Why does A/B  not equal 10/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 ]

>From the perspective of designing a well-behaved syntax,
I'd rather introduce a new operator:
	10 / 4 = 2
    10 ➗ 4 = 2.5

Of course that has several serious downsides.
- The same people who didn't understand why 10/4 == 2 won't
  understand when/why they need to use a different operator.
- It would be more conventional to flip the meanings,
  since ➗ is normally taught in the context of integer arithmetic.
- Most people don't have their keyboard set up to type ➗ easily.

	Ethan