Re: unexpected behavior of "do for"

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday, 03 May 2012, pl...@pi... wrote:
> On 03/05/12 20:24, Ethan A Merritt wrote:
> > Tait<gnu...@t4...>  wrote>
> >>> So yes, there is an inconsistency.  There are currently three "for"
> >>> constructs
> >>>    do for
> >>>    set for
> >>>    plot for
> >>>
> >>> The first two of these always iterate at least once; the third one does not.
> >>> The documentation is silent on the intended behavior.
> >>> So which to change, "plot for" or both the others?
> >>
> >> Given that it's called "for" I'd say the principle of least surprise
> >> dictate that it act consistently with "for" as used in most programming
> >> languages (e.g. C).
> >
> > Well, C doesn't really have an automatic iterator of this form; you have to
> > provide an explicit initialization, an explicit while condition, and an
> > explicit iteration operation.
> >
> > FWIW, here is what you get in R, whose syntax is close to that of gnuplot.
> >
> > R>   for (i in 4:1) { print(i) }
> > [1] 4
> > [1] 3
> > [1] 2
> > [1] 1
> 
> The R example is rather artificial. It is not the 'for' structure that 
> automatically takes a negative increment. That is the result of the 
> definition of the "range"  4:1 , which rightly defines a series 4 3 2 1 
> , that is unique and unambiguous.
> 

The "for" construct in gnuplot can be viewed this way also.
It has two forms:
   do for [i = N:M]
   do for [i in "FOO BAZ ARGL"]
You can view N:M in the first form as representing the set of integers 
bounded by N and M, just as "FOO BAZ ARGL" in the second form represents
the set of strings "FOO" "BAZ" and "ARGL". 

The fact that we iterate over the set in the specific order
N N+1 N+2 ... M is an implementation detail.

Mind you, I'm not arguing strongly that R has it right and other
languages have it wrong[*].  I'm just questioning the notion that
there's a single "obvious" or "least surprising" way to interpret
this statement. 

Just for the heck of it, I'll point out that this same argument
waxed hot back in the lead-up to Fortran77.   Earlier versions
of Fortran would always execute a loop at least once regardless
of the bounds in the DO statement.  This was, after much argument,
changed in Fortran77 so that the DO statement had a 
"minimum trip count" of zero.  Unfortunately this meant that the
very same statement would produce different results if compiled
using successive versions of Fortran.  Fun, eh?

I don't want to use FortranIV as a model, so I agree we
should change the code so that an explicit out-of-range iteration 
like [i = 5:-5:1] executes zero times.  But I think the discussion
is worthwhile as to whether [i = 0:5] and [i = 5:0] should both
iterate over the same set of six integers, although not necessarily
in the same order.  

As to "least surprise", consider that gnuplot users are already 
familiar with the idea that 'set xrange [0:5]' and 'set xrange [5:0]'
both span the same range, but in a different order.  It should not
be a big surprise if [i = 0:5] and [i = 5:0] also span the same
range but in a different order.

	Ethan

[*] Though I think we agree that python really does have it wrong.



> 
> 
> The idea that way the code is compiled varies dependant on the values of 
> the data seems an aberration to me.  This sort of thing should be 
> reserved for AI languages.
> 
> Perhaps someone could suggest how this would be advantageous.
> 
> If it is truly useful perhaps the idea of a range as a variable 
> structure needs to implemented as in R. Though this would probably lead 
> to an ambiguous syntax in for-loops which would have to have alternative 
> code paths for conventional integer args and ranges.
> 
> 
> Peter.