Menu
▾
▴
gnuplot-beta
|
From: Achim G. <Str...@ne...> - 2017-10-08 11:32:28
|
Is there some description how the variable scoping is supposed to work in blocks? It seems that they will need to be defined outside the block in order to be visible beyond the block and any set operations inside the block will be nixed when that block is left? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds |
|
From: sfeam <sf...@us...> - 2017-10-08 17:49:54
|
On Sunday, 08 October 2017 13:32:04 Achim Gratz wrote:
>
> Is there some description how the variable scoping is supposed to work
> in blocks? It seems that they will need to be defined outside the block
> in order to be visible beyond the block and any set operations inside
> the block will be nixed when that block is left?
With one exception, gnuplot variables are global.
There is a single, persistent, list of active variables indexed by name.
Assignment to a variable creates or replaces an entry in that list.
The only way to remove a variable from that list is the "undefine" command.
The one exception is the controlling variable of an iteration.
In that case the scope of the variable name is the iteration itself.
A previous instance of that variable name, if any, is saved at the
start of the iteration and restored at the end
Example:
j = "foo"
do for [j=1:3] {
plot for [j=5:6] x*j title "plot x*".j
}
print "j =", j # will report j = "foo"
Re-use of the name "j" in the do loop shadows the global
variable of that name, and re-use in the plot statement
shadows both of the outer uses.
Block structure is not relevant per se except that one use of a
block is to delineate the content of an iteration.
Ethan
>
>
> Regards,
> Achim.
>
|
|
From: Achim G. <Str...@ne...> - 2017-10-08 19:18:01
|
sfeam via gnuplot-beta writes:
> With one exception, gnuplot variables are global.
That is not what I was seeing (much to my surprise), although things may
have been complicated by my additional use of a call statement and
mixing with functions. So, I have a file that implements a callable
include:
--8<---------------cut here---------------start------------->8---
# call "scale.gp" linear|asinh knee
type = ((ARGC>0) ? ARG1 : "asinh")
knee = ((ARGC>1) ? ARG2 : 1e-5)
ticdef = ''
if (type eq "asinh") {
s(y) = asinh( 0.5*y/knee )
tic( s,u,n,v ) = sprintf( '"%s%i %s" %ss(%f),', s, n, u, ((s eq "±")?'':s), v );
omag = 1.
ticdef = tic( "±", "s", 0, 0 )
do for [unit in "s ms µs ns"] {
do for [mag = 0:2] {
m = 10**mag
v = omag*m
ticdef = ticdef . tic( "+", unit, m, v)
ticdef = ticdef . tic( "-", unit, m, v)
}
omag = omag / 1000.
}
ticdef = '(' . ticdef . ')'
}
if (type eq "linear") {
s(y) = y
}
set ytics @ticdef
--8<---------------cut here---------------end--------------->8---
The original version created ticdef inside the block and also set the
ytics there, but the result was never visible in the caller. This is
with gnuplot 5.0.7 from openSUSE.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
|
|
From: Achim G. <Str...@ne...> - 2017-10-10 16:28:55
|
Hans-Bernhard Bröker writes: >> This seems all unnecessarily involved, so maybe I should rather ask if >> there's a way to build up an explicit tics list piece by piece rather >> than having to feed everyting as one single giant string? > > You're looking for "set xtics add ..." Indeed. Thanks. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra |
|
From: sfeam <sf...@us...> - 2017-10-09 00:31:10
|
On Sunday, 08 October 2017 21:17:40 Achim Gratz wrote:
> sfeam via gnuplot-beta writes:
> > With one exception, gnuplot variables are global.
>
> That is not what I was seeing (much to my surprise), although things may
> have been complicated by my additional use of a call statement and
> mixing with functions. So, I have a file that implements a callable
> include:
Too complicated for me to work through in detail but one line
is waving a red flag. This line
set ytics @ticdef
is almost certainly not what you want to do.
The macro expansion operator @ is like a #define statement in C.
It causes a substitution at the time the file/block/clause/program unit
is read in. It is _not_ reevaluated at run time.
An example of evaluation at run time would be:
... loop that constructs ticdef ...
eval "set ytics " . ticdef
Ethan
>
> --8<---------------cut here---------------start------------->8---
> # call "scale.gp" linear|asinh knee
> type = ((ARGC>0) ? ARG1 : "asinh")
> knee = ((ARGC>1) ? ARG2 : 1e-5)
> ticdef = ''
> if (type eq "asinh") {
> s(y) = asinh( 0.5*y/knee )
> tic( s,u,n,v ) = sprintf( '"%s%i %s" %ss(%f),', s, n, u, ((s eq "±")?'':s), v );
> omag = 1.
> ticdef = tic( "±", "s", 0, 0 )
> do for [unit in "s ms µs ns"] {
> do for [mag = 0:2] {
> m = 10**mag
> v = omag*m
> ticdef = ticdef . tic( "+", unit, m, v)
> ticdef = ticdef . tic( "-", unit, m, v)
> }
> omag = omag / 1000.
> }
> ticdef = '(' . ticdef . ')'
> }
> if (type eq "linear") {
> s(y) = y
> }
> set ytics @ticdef
> --8<---------------cut here---------------end--------------->8---
>
> The original version created ticdef inside the block and also set the
> ytics there, but the result was never visible in the caller. This is
> with gnuplot 5.0.7 from openSUSE.
>
>
> Regards,
> Achim.
>
|
|
From: Achim G. <Str...@ne...> - 2017-10-09 18:20:03
|
sfeam via gnuplot-beta writes: > Too complicated for me to work through in detail but one line > is waving a red flag. This line > set ytics @ticdef > is almost certainly not what you want to do. Ah, OK. > The macro expansion operator @ is like a #define statement in C. > It causes a substitution at the time the file/block/clause/program unit > is read in. It is _not_ reevaluated at run time. I still can't quite figure out the consitions under which this was and wasn't working for my example in various stages of its development, but I think that must be the right explanation. > An example of evaluation at run time would be: > > ... loop that constructs ticdef ... > eval "set ytics " . ticdef This seems all unnecessarily involved, so maybe I should rather ask if there's a way to build up an explicit tics list piece by piece rather than having to feed everyting as one single giant string? Also, why is there no block "else if" or maybe even "elsif"? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2017-10-09 20:09:46
|
Am 09.10.2017 um 20:19 schrieb Achim Gratz: > This seems all unnecessarily involved, so maybe I should rather ask if > there's a way to build up an explicit tics list piece by piece rather > than having to feed everyting as one single giant string? You're looking for "set xtics add ..." |
|
From: Ethan A M. <sf...@us...> - 2017-10-09 20:13:34
|
On Monday, 09 October, 2017 20:19:43 Achim Gratz wrote:
> sfeam via gnuplot-beta writes:
> > Too complicated for me to work through in detail but one line
> > is waving a red flag. This line
> > set ytics @ticdef
> > is almost certainly not what you want to do.
>
> Ah, OK.
>
> > The macro expansion operator @ is like a #define statement in C.
> > It causes a substitution at the time the file/block/clause/program unit
> > is read in. It is _not_ reevaluated at run time.
>
> I still can't quite figure out the consitions under which this was and
> wasn't working for my example in various stages of its development, but
> I think that must be the right explanation.
>
> > An example of evaluation at run time would be:
> >
> > ... loop that constructs ticdef ...
> > eval "set ytics " . ticdef
>
> This seems all unnecessarily involved, so maybe I should rather ask if
> there's a way to build up an explicit tics list piece by piece rather
> than having to feed everyting as one single giant string?
Yes. The keyword "add" does what you want.
# x labels at 1 2 3 ... and also at certain interesting values
array label[4] = ["sqrt(2)", "sqrt(3)", "e", "pi"]
array value[4] = [1.414, 1.732, exp(1), pi]
set xtics 1.0
do for [i=1:4] {
set xtics add (label[i] value[i])
}
> Also, why is there no block "else if" or maybe even "elsif"?
No particular reason.
So far as I can see, all it would gain is to reduce the number of
required curly brackets by one pair.
Is there something more subtle I'm missing?
Ethan
>
> Regards,
> Achim.
>
|
|
From: Achim G. <Str...@ne...> - 2017-10-10 16:34:58
|
Ethan A Merritt via gnuplot-beta writes:
>> Also, why is there no block "else if" or maybe even "elsif"?
>
> No particular reason.
> So far as I can see, all it would gain is to reduce the number of
> required curly brackets by one pair.
> Is there something more subtle I'm missing?
Maybe. If the conditional expressions themselve need to be nested, you
will either end up with unwieldy formatting
--8<---------------cut here---------------start------------->8---
if (…) {
else {
if (…) {
else {
if (…) {
else {
if (…) {
else {
if (…) {
else {
if (…) {
--8<---------------cut here---------------end--------------->8---
or you'll need to explicitly repeat (and revert) the logical expression
from the former branches.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
|
|
From: Achim G. <Str...@ne...> - 2017-10-15 08:19:30
|
Achim Gratz writes:
> Ethan A Merritt via gnuplot-beta writes:
>>> Also, why is there no block "else if" or maybe even "elsif"?
>>
>> No particular reason.
>> So far as I can see, all it would gain is to reduce the number of
>> required curly brackets by one pair.
>> Is there something more subtle I'm missing?
>
> Maybe. If the conditional expressions themselve need to be nested, you
> will either end up with unwieldy formatting
>
> if (…) {
> else {
> if (…) {
> else {
> if (…) {
> else {
> if (…) {
> else {
> if (…) {
> else {
> if (…) {
>
> or you'll need to explicitly repeat (and revert) the logical expression
> from the former branches.
Example for that latter point:
--8<---------------cut here---------------start------------->8---
if (days <= 1/24.) {
set xtics 15/60.
set mxtics 3
}
if (days > 1/24. && days <= 4/24.) {
set xtics 1
set mxtics 12
}
if (days > 4/24. && days <= 2) {
set xtics 1
set mxtics 4
}
if (days > 12/24. && days <= 2) {
set xtics 2
set mxtics 8
}
if (days > 2 && days <= 6) {
set xtics 6
set mxtics 12
}
if (days > 6 && days <= 13) {
set xtics 12
set mxtics 12
}
if (days > 13 && days <= 27) {
set xtics 24
set mxtics 8
}
if (days > 27 && days <= 41) {
set xtics 24
set mxtics 4
}
if (days > 41) {
set xtics 7*24
set mxtics 14
}
--8<---------------cut here---------------end--------------->8---
So with that hypothetical elsif keyword, things would look a lot saner
and be less error-prone, I think:
--8<---------------cut here---------------start------------->8---
if (days <= 1/24.) {
set xtics 15/60.
set mxtics 3
} elsif (days <= 4/24.) {
set xtics 1
set mxtics 12
} elsif (days <= 2) {
set xtics 1
set mxtics 4
} elsif (days <= 2) {
set xtics 2
set mxtics 8
} elsif (days <= 6) {
set xtics 6
set mxtics 12
} elsif (days <= 13) {
set xtics 12
set mxtics 12
} elsif (days <= 27) {
set xtics 24
set mxtics 8
} elsif (days <= 41) {
set xtics 24
set mxtics 4
} else {
set xtics 7*24
set mxtics 14
}
--8<---------------cut here---------------end--------------->8---
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
|
|
From: sfeam <sf...@us...> - 2017-10-15 18:09:03
|
On Sunday, 15 October 2017 10:19:11 Achim Gratz wrote:
> Achim Gratz writes:
> > Ethan A Merritt via gnuplot-beta writes:
> >>> Also, why is there no block "else if" or maybe even "elsif"?
> >>
> >> No particular reason.
> >> So far as I can see, all it would gain is to reduce the number of
> >> required curly brackets by one pair.
> >> Is there something more subtle I'm missing?
> >
> > Maybe. If the conditional expressions themselve need to be nested, you
> > will either end up with unwieldy formatting
> >
> > if (…) {
> > else {
> > if (…) {
> > else {
> > if (…) {
> > else {
> > if (…) {
> > else {
> > if (…) {
> > else {
> > if (…) {
> >
> > or you'll need to explicitly repeat (and revert) the logical expression
> > from the former branches.
>
[snip]
> Example for that latter point:
> So with that hypothetical elsif keyword, things would look a lot saner
> and be less error-prone, I think:
>
> --8<---------------cut here---------------start------------->8---
> if (days <= 1/24.) {
> set xtics 15/60.
> set mxtics 3
> } elsif (days <= 4/24.) {
> set xtics 1
> set mxtics 12
> } elsif (days <= 2) {
> set xtics 1
> set mxtics 4
> } elsif (days <= 2) {
> set xtics 2
> set mxtics 8
> } elsif (days <= 6) {
> set xtics 6
> set mxtics 12
> } elsif (days <= 13) {
> set xtics 12
> set mxtics 12
> } elsif (days <= 27) {
> set xtics 24
> set mxtics 8
> } elsif (days <= 41) {
> set xtics 24
> set mxtics 4
> } else {
> set xtics 7*24
> set mxtics 14
> }
> --8A<---------------cut here---------------end--------------->8---
There are other possibilities using the existing syntax elements.
For example:
do for [i=0:0] {
if (days <= 1/24.) {
set xtics 15/60.
set mxtics 3
break
}
if (days <= 4/24.) {
set xtics 1
set mxtics 12
break
}
if (days <= 2) {
set xtics 1
set mxtics 4
break
}
if (days <= 2) {
set xtics 2
set mxtics 8
break
}
if (days <= 6) {
set xtics 6
set mxtics 12
break
}
if (days <= 13) {
set xtics 12
set mxtics 12
break
}
if (days <= 27) {
set xtics 24
set mxtics 8
break
}
if (days <= 41) {
set xtics 24
set mxtics 4
break
}
else {
set xtics 7*24
set mxtics 14
break
}
}
Essentially a switch/case construct.
Ethan
> Achim.
>
|
