gnuplot-beta

Re: String variables

[Hans-Bernhard B. <br...@ph...>]

On Thu, 8 Jul 2004, Ethan Merritt wrote:

> Or did you mean
> 
>     set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)

That one, mostly.  Generally, the "A = $A" syntax may seem simple, but
it's also of rather limited flexibility.   

This function-like syntax also extends more naturally to other operations
on strings (scanning a string, reading a string from an external file,
...).  I think we can take a hint from Java, here: Strings are native
datatypes, but the only operator they support is '+' for concatenation.
Everything else is done by functions.

> But I don't really see how either of these would work on the
> command line. The existing "userstrings" patch allows
> 
>     STYLE1 = "1:4 with lines lw 2"
>     plot 'datafile' using $STYLE1

In this context, the decision about $ vs. sprintf() would affect only the
first of these lines.  In my scheme, it might become:

   STYLE1 = sprintf("1:%d with lines lw %g", i, width)

We should probably foresee an interface to gprintf(), too, to give access 
to %l/%L from 'help format spec'.

> Admittedly the userstrings patch would probably better be
> described as implementing macro definitions rather string variables,

Exactly.  Just storing a fixed string in a variable is not very helpful.
The real power to be gained would lie in the methods for constructing such
strings from other elements.  Compare it to our user-defined variables.  
They would be of rather limited applicability if you couldn't use
arbitrary expressions to compute their value.

> > $ already being used for at 
> > least two entirely unrelated things in gnuplot
> 
> The primary use is for column numbers.
> The second use I know about is for the command line 
> variables ($1, $2, $3...).  

IIRC there's a feature request that we should $-expand environment
variables.  And TeX strings have to be able to contain literal $
characters.  And your own suggestions just introduced two independent uses
of it: to signal a string variable / macro to be expanded, and to signal a
number to be inserted inside a string.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: String variables

[Hans-Bernhard B. <br...@ph...>]

On Tue, 13 Jul 2004, Dave Denholm wrote:

> There is another question : should that evaluate the expression
> (sprintf...) once and store the resulting string value in the label,
> or should it store the expression and re-evaluate it for every plot ?

Depends on where the expression appears, I should think.  If we only
provide string variables, but not string-valued expression available
everwhere, this question won't arise.  

Generally, it should work like it does with numeric expressions vs.  
user-defined variables now:

	myfunx(x)=x**2
	a = myfunc(2)
	myfunc(x)=x**3
	plot a, myfunc(x)

will plot a constant 2 (not 8), and x**3.  I.e. all expression remain
to be evaluated when the command they appear in is executed.

> Here the analogy would be that
> 
>   set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)
> 
> evaluates it once and stores the result, but
> 
>   set label 1 (sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B))
> 
> stores it as an expression.

We'll need a different syntax, but the feature itself would probably be a
good idea.  And not only for strings, either.  Something like '$()' to
signify 'late expansion' (i.e. only when the value is actually needed),
maybe.

> I wonder if the parser is going to need help for identifying string
> expressions.

Quite definitely it will.  Technically, we'll need to extend
the is_string() function in some tricky way.  So far, my vague idea
was to require string-valued expressions to always start with a
string constant, for its benefit.  I.e. we would have
	
	plot f(x)   # numeric expr. --> function
	plot 'file' # string --> file name
	plot ''+g(p,q)  # string --> computed filename

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: String variables

[Petr M. <mi...@ph...>]

> >     set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)
>
> That one, mostly.  Generally, the "A = $A" syntax may seem simple, but
> it's also of rather limited flexibility.
>
> This function-like syntax also extends more naturally to other operations
> on strings (scanning a string, reading a string from an external file,
> ...).  I think we can take a hint from Java, here: Strings are native
> datatypes, but the only operator they support is '+' for concatenation.
> Everything else is done by functions.

I would also prefer this way of sprintf and '+' operator for strings.

---
PM

Re: String variables

[Dave D. <dde...@es...>]

Petr Mikulik <mi...@ph...> writes:

>> >     set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)
>>
>> That one, mostly.  Generally, the "A = $A" syntax may seem simple, but
>> it's also of rather limited flexibility.
>>
>> This function-like syntax also extends more naturally to other operations
>> on strings (scanning a string, reading a string from an external file,
>> ...).  I think we can take a hint from Java, here: Strings are native
>> datatypes, but the only operator they support is '+' for concatenation.
>> Everything else is done by functions.
>
> I would also prefer this way of sprintf and '+' operator for strings.
>

There is another question : should that evaluate the expression
(sprintf...) once and store the resulting string value in the label,
or should it store the expression and re-evaluate it for every plot ?


Should both be supported ?

Eg  the plot ... using (expression)  broke backwards compatibility
because previously, 'using' expected a constant expression which gave
a column number.

As I'm sure you'll all remember, the brackets were a compromise. But
it's a bit ugly. There's nothing to say that the constant expression
could not contain brackets.


Here the analogy would be that

  set label 1 sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B)

evaluates it once and stores the result, but

  set label 1 (sprintf( "After fitting, A = %3.2f, B = %3.2f", A, B))

stores it as an expression.


(I'm not suggesting this as a way forward - just hightlighting the
issue)


I wonder if the parser is going to need help for identifying string
expressions. gnuplot has always had a fairly lax syntax, with optional
bits of commands being detected automatically.

Eg

f(x,y)=sprintf( "After fitting, A = %3.2f, B = %3.2f", x,y)

set label 1 f(A,B)


Could so something like

 set label 1 """f(A,B)"""

which alerts the lexer that there's a string expression next.

Or I think tcl uses [...] to indicate an expression.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com