Re: Should gnuplot become a programming environment?

[Ethan A M. <sf...@us...>]

On Friday, 31 October, 2014 17:38:00 pl...@pi... wrote:
> On 10/30/14 22:42, Ethan A Merritt wrote:
> >
> > On Thursday, 30 October, 2014 12:58:54 pl...@pi... wrote:
> >>   Also the odd need to use commas in place of the usual semicolon
> >>   in defining functions seems inconsistent and could be limiting as
> >>   things move forwards.
> >
> > Are you referring to the comma operator for serial evaluation?
> > That is taken straight from C, C++, perl, javascript and no doubt
> > other languages as well.
> >
> >      http://en.wikipedia.org/wiki/Comma_operator
> >
> >
> > 	Ethan
> >
> 
> My apologies, apparently I was successfully using this feature without 
> realising its correct syntax definition. Where is it documented? 

gnuplot> help expressions operators binary

> help comma does not seem relevant.

True, but we don't have sections for "help plus sign" or "help equals" either.

I think it is covered best by the first  sentences of "help expressions"

gnuplot> help expression
     In general, any mathematical expression accepted by C, FORTRAN, 
     Pascal, or BASIC is valid.  The precedence of these operators is
     determined by the specifications of the C programming language.  

But this statement is not entirely true.  Pascal  operators  <>  div  mod
are not recognized.   And gnuplot only learned about the bit shift operators
>> and << recently.

	Ethan

> I was thinking the following two uses were the same thing. It seems the 
> first is a separator, second is an operator:
> 
> gnuplot> plot a=1,b=2, sin(x)
> fn(x)=( a=1,b=2, sin(x) )
> 
> Peter.