Menu
▾
▴
gnuplot-beta
|
From: Teo S B. <teo...@gm...> - 2010-02-12 17:58:54
|
Problem:
Gnuplot script that set parameter repeatedly in plot command to address the
data index (within a data file) does not work when using gnuplot version
4.4.0-rc1.
It works in 4.2 version and, from memory, did also work in version 4.3. See
the below shortened example reproducing the error message:
# file: trial.gpl
f(x)=x
plot a=1, \
f(x)*a title "data from index a=1" w l lw 2 lt a , a=a+1, \
f(x)*a title "data from index a=2" w l lw 2 lt a , a=a+1, \
a=0
pause -1 "Continue?"
#
# gnuplot 4.2 patchlevel 5 accepts the above. I believe that also
# gnuplot 4.3 accepted this.
#
# gnuplot-4.4.0 patchlevel 0-rc1 give error:
# "trial.gpl", line 6: function to plot expected
#
#
# It works if I add a dummy curve after a=0, so that last line
# becomes:
# a=0, x/0
#
exit
Best regards
Teo
|
|
From: Ethan M. <merritt@u.washington.edu> - 2010-02-12 18:08:25
|
On Friday 12 February 2010 09:58:45 Teo S Bernhard wrote: > Problem: > Gnuplot script that set parameter repeatedly in plot command to address the > data index (within a data file) does not work when using gnuplot version > 4.4.0-rc1. > It works in 4.2 version and, from memory, did also work in version 4.3. See > the below shortened example reproducing the error message: > > > # file: trial.gpl > f(x)=x > plot a=1, \ > f(x)*a title "data from index a=1" w l lw 2 lt a , a=a+1, \ > f(x)*a title "data from index a=2" w l lw 2 lt a , a=a+1, \ > a=0 Please see Bug #2907028 https://sourceforge.net/tracker/?func=detail&aid=2907028&group_id=2055&atid=102055 So far as I can tell from running old versions of gnuplot (back to 3.7), it never did work correctly to increment a variable multiple times inside a plot command. The good news is that in version 4.4 you can do this easily using the construct plot for [a=1:2] f(x)*a title "data from index a=1" w l lw 2 lt a > pause -1 "Continue?" > > # > # gnuplot 4.2 patchlevel 5 accepts the above. I believe that also > # gnuplot 4.3 accepted this. > # > # gnuplot-4.4.0 patchlevel 0-rc1 give error: > # "trial.gpl", line 6: function to plot expected > # > # > # It works if I add a dummy curve after a=0, so that last line > # becomes: > # a=0, x/0 > # > exit > > Best regards > Teo > -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Teo S B. <teo...@gm...> - 2010-02-12 19:26:45
|
On Fri, Feb 12, 2010 at 7:07 PM, Ethan Merritt <merritt@u.washington.edu>wrote: > On Friday 12 February 2010 09:58:45 Teo S Bernhard wrote: > > Problem: > > Gnuplot script that set parameter repeatedly in plot command to address > the > > data index (within a data file) does not work when using gnuplot version > > 4.4.0-rc1. > > It works in 4.2 version and, from memory, did also work in version 4.3. > See > > the below shortened example reproducing the error message: > > > > > > # file: trial.gpl > > f(x)=x > > plot a=1, \ > > f(x)*a title "data from index a=1" w l lw 2 lt a , a=a+1, \ > > f(x)*a title "data from index a=2" w l lw 2 lt a , a=a+1, \ > > a=0 > > Please see Bug #2907028 > > https://sourceforge.net/tracker/?func=detail&aid=2907028&group_id=2055&atid=102055 > > So far as I can tell from running old versions of gnuplot (back to 3.7), > it never did work correctly to increment a variable multiple times inside > a plot command. > > Test of referred bug report: I have tested and it is is reproducible. There is however a subtle difference with my example and that of the bug report. Note that I initiate the counter variable first in the plot command. Then - the problem vanish. The parameter incrementation is then correct! You can convince yourself by trying the following: k=0 plot [0:1] [-1:] k=0, \ k*x t '0x' w lp lt 1, k=k+1, \ k*x t '1x' w lp lt 2, k=k+1, \ k*x t '2x' w lp lt 3 Now, if you remove the initial 'k=0, \' part of the plot-command - the '0x'-line is plotted as 2*x, the '1x'-line as 3*x and '2x'-line as 4*x. Can this be related to the two 'k=k+1' for some strange reason? In deed, adding a third 'k=k+1' leads the first '0x'-line to be plotted as 3*x! This is clearly a bug since k is expected as zero for the first line to be plotted, '0x'. I therefore think there are two issues here: 1) The issue reported as Bug #2907028 and 2) the issue reported by me here, that version 4.4 does not allow an increment as the last statement of a plot-command. This test on Ubuntu 8.04, gnuplot 4.2 patchlevel 2 and gnuplot 4.3 patchlevel 0. > pause -1 "Continue?" > > > > # > > # gnuplot 4.2 patchlevel 5 accepts the above. I believe that also > > # gnuplot 4.3 accepted this. > > # > > # gnuplot-4.4.0 patchlevel 0-rc1 give error: > > # "trial.gpl", line 6: function to plot expected > > # > > # > > # It works if I add a dummy curve after a=0, so that last line > > # becomes: > > # a=0, x/0 > > # > > exit > > > > Best regards > > Teo > > > > |
|
From: Ethan M. <merritt@u.washington.edu> - 2010-02-12 22:40:18
|
On Friday 12 February 2010 11:26:36 Teo S Bernhard wrote: > > > the below shortened example reproducing the error message: > > > > > > > > > # file: trial.gpl > > > f(x)=x > > > plot a=1, \ > > > f(x)*a title "data from index a=1" w l lw 2 lt a , a=a+1, \ > > > f(x)*a title "data from index a=2" w l lw 2 lt a , a=a+1, \ > > > a=0 > > > > Please see Bug #2907028 > > > > https://sourceforge.net/tracker/?func=detail&aid=2907028&group_id=2055&atid=102055 > > > > So far as I can tell from running old versions of gnuplot (back to 3.7), > > it never did work correctly to increment a variable multiple times inside > > a plot command. > > > > > Test of referred bug report: > I have tested and it is is reproducible. There is however a subtle > difference with my example and that of the bug report. Note that I initiate > the counter variable first in the plot command. Then - the problem vanish. > The parameter incrementation is then correct! > You can convince yourself by trying the following: > > k=0 > plot [0:1] [-1:] k=0, \ > k*x t '0x' w lp lt 1, k=k+1, \ > k*x t '1x' w lp lt 2, k=k+1, \ > k*x t '2x' w lp lt 3 > > Now, if you remove the initial 'k=0, \' part of the plot-command - the > '0x'-line is plotted as 2*x, the '1x'-line as 3*x and '2x'-line as 4*x. Can > this be related to the two 'k=k+1' for some strange reason? In deed, adding > a third 'k=k+1' leads the first '0x'-line to be plotted as 3*x! This is > clearly a bug since k is expected as zero for the first line to be plotted, > '0x'. > > I therefore think there are two issues here: > 1) The issue reported as Bug #2907028 and > 2) the issue reported by me here, that version 4.4 does not allow an > increment as the last statement of a plot-command. The 4.0 and 4.2 documentation gives: Syntax: plot {<ranges>} {<function> | {"<datafile>" {datafile-modifiers}}} {axes <axes>} {<title-spec>} {with <style>} {, {definitions,} <function> ...} which means that definitions can come before a function, but not after. So I think you have been depending on undocumented, probably unintended, behavior. It may well be that some earlier versions did accept a trailing definition, but since it was not documented no one was testing for this as the code evolved. If there were no better way to accomplish what you were doing, I would agree that it was a bug and should be fixed. But since this can now be done more conveniently in 4.4 using iteration, I don't see much incentive to go back and reconstruct how earlier versions worked on an undocumented command syntax. What do others think? Is there good reason to rework the code to allow this, and change the documentation to match? Ethan > > This test on Ubuntu 8.04, gnuplot 4.2 patchlevel 2 and gnuplot 4.3 > patchlevel 0. > > > pause -1 "Continue?" > > > > > > # > > > # gnuplot 4.2 patchlevel 5 accepts the above. I believe that also > > > # gnuplot 4.3 accepted this. > > > # > > > # gnuplot-4.4.0 patchlevel 0-rc1 give error: > > > # "trial.gpl", line 6: function to plot expected > > > # > > > # > > > # It works if I add a dummy curve after a=0, so that last line > > > # becomes: > > > # a=0, x/0 > > > # > > > exit > > > > > > Best regards > > > Teo > > > > > > > |
|
From: Tatsuro M. <tma...@ya...> - 2010-02-13 05:57:53
|
Hello
--- Ethan Merritt wrote:
> > k=0
> > plot [0:1] [-1:] k=0, \
> > k*x t '0x' w lp lt 1, k=k+1, \
> > k*x t '1x' w lp lt 2, k=k+1, \
> > k*x t '2x' w lp lt 3
> >
> > Now, if you remove the initial 'k=0, \' part of the plot-command - the
> > '0x'-line is plotted as 2*x, the '1x'-line as 3*x and '2x'-line as 4*x. Can
> > this be related to the two 'k=k+1' for some strange reason? In deed, adding
> > a third 'k=k+1' leads the first '0x'-line to be plotted as 3*x! This is
> > clearly a bug since k is expected as zero for the first line to be plotted,
> > '0x'.
> >
> > I therefore think there are two issues here:
> > 1) The issue reported as Bug #2907028 and
> > 2) the issue reported by me here, that version 4.4 does not allow an
> > increment as the last statement of a plot-command.
>
> The 4.0 and 4.2 documentation gives:
> Syntax:
> plot {<ranges>}
> {<function> | {"<datafile>" {datafile-modifiers}}}
> {axes <axes>} {<title-spec>} {with <style>}
> {, {definitions,} <function> ...}
>
> which means that definitions can come before a function, but not after.
> So I think you have been depending on undocumented, probably unintended,
> behavior.
>
> It may well be that some earlier versions did accept a trailing
> definition, but since it was not documented no one was testing for this
> as the code evolved.
>
> If there were no better way to accomplish what you were doing, I would
> agree that it was a bug and should be fixed. But since this can now be
> done more conveniently in 4.4 using iteration, I don't see much incentive
> to go back and reconstruct how earlier versions worked on an undocumented
> command syntax.
>
> What do others think? Is there good reason to rework the code to allow
> this, and change the documentation to match?
>
> Ethan
I have not know the such syntax can be used for gnuplot. I have been used external awk script, which
produce the gnuplot scripts, if iteration has been required.
The iteration feature of 4.4 is very nice and useful. In my idea, the old undocumented syntax needs
not to be fixed because there appears more convenient implementation for iteration. If one would like
to use the syntax, the fix should be done by oneself.
Regards
Tatsuro
--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/
|
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-02-14 14:05:43
|
Ethan Merritt wrote:
> On Friday 12 February 2010 11:26:36 Teo S Bernhard wrote:
>>>> the below shortened example reproducing the error message:
>>>>
>>>>
>>>> # file: trial.gpl
>>>> f(x)=x
>>>> plot a=1, \
>>>> f(x)*a title "data from index a=1" w l lw 2 lt a , a=a+1, \
>>>> f(x)*a title "data from index a=2" w l lw 2 lt a , a=a+1, \
>>>> a=0
I see no particularly compelling reason why this can't be changed to
a=0 ; plot \
f(x)*a title "data from index a=1" w l lw 2 lt a , a=a+1, \
f(x)*a title "data from index a=2" w l lw 2 lt a ; a = 0
Note the semicolons.
The whole purpose of changing variables' values in the plot command is
for that to take effect _between_ datasets/functions. There's no need
at all for that to be possible before the first, or after the last of them.
> So I think you have been depending on undocumented, probably unintended,
> behavior.
And there's no need for adding a feature that allows it now. A
semicolon instead of the comma achieves the same effect already.
> What do others think? Is there good reason to rework the code to allow
> this, and change the documentation to match?
IMHO, no.
|
|
From: Teo S B. <teo...@gm...> - 2010-02-14 19:08:16
|
2010/2/14 Hans-Bernhard Bröker <HBB...@t-...>:
> Ethan Merritt wrote:
>> On Friday 12 February 2010 11:26:36 Teo S Bernhard wrote:
>>>>> the below shortened example reproducing the error message:
>>>>> # file: trial.gpl
>>>>> f(x)=x
>>>>> plot a=1, \
>>>>> f(x)*a title "data from index a=1" w l lw 2 lt a , a=a+1, \
>>>>> f(x)*a title "data from index a=2" w l lw 2 lt a , a=a+1, \
>>>>> a=0
>
> I see no particularly compelling reason why this can't be changed to
>
> a=0 ; plot \
> f(x)*a title "data from index a=1" w l lw 2 lt a , a=a+1, \
> f(x)*a title "data from index a=2" w l lw 2 lt a ; a = 0
>
> Note the semicolons.
>
> The whole purpose of changing variables' values in the plot command is
> for that to take effect _between_ datasets/functions. There's no need
> at all for that to be possible before the first, or after the last of them.
Your suggestion breaks gridding/zooming/... capability in the plot.
This happens because the a-variable is not initiated within the plot statement.
I find when trying: a=0; plot [0:1] a*x, a=a+1, a*x
- while toggling the grid I see that the first plot shows '1x' and
2x, while the second version shows: '3x' and '4x'.
Note also that current gnuplot capability _does_ support initial
variable/function initiation, e.g.: plot [0:1] a=1, a*x, a=a+1,
a*x
- even according to documentation, see below.
>> So I think you have been depending on undocumented, probably unintended behavior.
The sole issue of mine is that gnuplot version 4.4 rc1 breaks backward
compatibility since it is
_not_ allowing trailing variable definitions as the last item of
plot-command. Such trailing definitions are
in much use here.
I certainly agree that there are fully functional workarounds even
with the suggested gnuplot 4.4-0 rc1 .
The downside is that any such workaround could imply reworking
historic scripts or other tools that
uses gnuplot as plotting engine and this particular feature. I claim
below - that it is gnuplot 4.4.0 rc1
that is at odds with the documentation.
>
>> What do others think? Is there good reason to rework the code to allow
>> this, and change the documentation to match?
>
I have been routinely using as _the_plotting_engine since 1999 and I
appreciate your great efforts in maintaining and further improving it.
Whatever your decision, I trust that it will be to the best for the
future of gnuplot.
As to the issue of "trailing definitions", the following is my
argument for why I think that a "trailing definition" should be
allowed:.
I believe that the suggested change is required by the documentation,
I read in gnuplot 4.4 rc 1 under 'help plot':
a) definitions can come initially in plot command, see the example
no. 3: plot f(x) = sin(x*a), a = .2, f(x), a = .4, f(x)
b) definitions can come between prior and subsequent functions if
separated by a comma, this is also explicitly said in the help text
c) In the briefer usage instruction (repeated below) I notice the
optional trailing comma after definitions {,}, I also notice the
replaceable <function>.
Considering the interpretation of item c), practical experience with
gnuplot versions 4.3, 4.2, 4.0,..., suggest that there is no need for
a trailing comma after a definition if there is no trailing
<function>, here <function> can be replaced by nothing. In my opinion,
the latter is a reasonable interpretation which is supported by
historic gnuplot implementations. See the brief usage instruction:
plot {<ranges>}
{<iteration>}
{<function> | {"<datafile>" {datafile-modifiers}}}
{axes <axes>} {<title-spec>} {with <style>}
{, {definitions{,}} <function> ...}
My claim is therefore that previous gnuplot version, prior to gnuplot
4.4 rc1, behaved according to this documentation whereas version 4.4
rc 1 does not behave according to the documentation regarding item c,
this causes gnuplot 4.4 rc1 to break backwards compatibility.
If you agree, please consider the following patch vs. gnuplot 4.4 rc1
for allowing trailing definitions in a plot command: plot [-1:1] k=0,
k*x, k=k+1, k*x, k=k+1
As can be seen, only one code line needs to be modified - in two
places. The modified if-statement is the one that causes an error
message.
With this modification, a trailing definition is silently accepted
whereas earlier syntax errors are triggered as before.
Best regards
Teo
(Linux, Ubuntu 9.10 and self-compiled gnuplot 4.4.0 rc1)
diff -r ca8b5fbc043a plot2d.c
--- a/plot2d.c Sun Feb 14 14:45:12 2010 +0100
+++ b/plot2d.c Sun Feb 14 16:45:27 2010 +0100
@@ -1459,7 +1459,7 @@
if (is_definition(c_token)) {
define();
- if (!equals(c_token,",")) {
+ if (!END_OF_COMMAND && !equals(c_token,",")) {
was_definition = TRUE;
continue;
}
@@ -2174,7 +2174,7 @@
if (is_definition(c_token)) {
define();
- if (!equals(c_token,",")) {
+ if (!END_OF_COMMAND && !equals(c_token,",")) {
was_definition = TRUE;
continue;
}
|
|
From: sfeam (E. Merritt) <eam...@gm...> - 2010-02-14 19:54:32
|
On Sunday 14 February 2010, Hans-Bernhard Bröker wrote: > > On Friday 12 February 2010 11:26:36 Teo S Bernhard wrote: > > >>>> the below shortened example reproducing the error message: > >>>> > >>>> > >>>> # file: trial.gpl > >>>> f(x)=x > >>>> plot a=1, \ > >>>> f(x)*a title "data from index a=1" w l lw 2 lt a , a=a+1, \ > >>>> f(x)*a title "data from index a=2" w l lw 2 lt a , a=a+1, \ > >>>> a=0 > > I see no particularly compelling reason why this can't be changed to > > a=0 ; plot \ > f(x)*a title "data from index a=1" w l lw 2 lt a , a=a+1, \ > f(x)*a title "data from index a=2" w l lw 2 lt a ; a = 0 > > Note the semicolons. The problem is that the two forms do not produce the same result. See Bug #2907028. If you place the "a=0" inside the plot statement, then a really is 0 during the first function evaluation. If you place the "a=0" before the plot statement, separated by a semicolon, then a has the value 1 during the first function evaluation. This is, to say the least, unexpected. |
|
From: Ethan M. <merritt@u.washington.edu> - 2010-02-14 20:26:09
|
On Sunday 14 February 2010, Teo S Bernhard wrote:
> c) In the briefer usage instruction (repeated below) I notice the
> optional trailing comma after definitions {,}, I also notice the
> replaceable <function>.
> Considering the interpretation of item c), practical experience with
> gnuplot versions 4.3, 4.2, 4.0,..., suggest that there is no need for
> a trailing comma after a definition if there is no trailing
> <function>, here <function> can be replaced by nothing. In my opinion,
> the latter is a reasonable interpretation which is supported by
> historic gnuplot implementations. See the brief usage instruction:
> plot {<ranges>}
> {<iteration>}
> {<function> | {"<datafile>" {datafile-modifiers}}}
> {axes <axes>} {<title-spec>} {with <style>}
> {, {definitions{,}} <function> ...}
You are not interpreting this BNF description correctly.
The meaning of the final line quoted immediately above is
"If you append a comma you must follow it with a function.
The function may optionally be preceded by a definition,
with or without a separating comma."
The <function> element is not in curly brackets, and hence is
not optional. There is no expansion of this set of BNF rules that
results in a trailing definition. So no, the documentation
has never stated that a trailing definition was valid syntax.
> My claim is therefore that previous gnuplot version, prior to gnuplot
> 4.4 rc1, behaved according to this documentation whereas version 4.4
> rc 1 does not behave according to the documentation regarding item c,
> this causes gnuplot 4.4 rc1 to break backwards compatibility.
>
> If you agree, please consider the following patch vs. gnuplot 4.4 rc1
> for allowing trailing definitions in a plot command: plot [-1:1] k=0,
> k*x, k=k+1, k*x, k=k+1
> As can be seen, only one code line needs to be modified - in two
> places. The modified if-statement is the one that causes an error
> message.
> With this modification, a trailing definition is silently accepted
> whereas earlier syntax errors are triggered as before.
I don't think it makes sense to do this without also doing one of
the following:
1) fix bug #2907028
2) document that it is not permissible to use a definition of
the form q = <expression involving q> inside a plot statment.
Otherwise it is nearly impossible to figure out how the program will
assign the instantaneous value of q is during the plot.
|
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-02-14 20:26:31
|
Teo S Bernhard wrote:
> Your suggestion breaks gridding/zooming/... capability in the plot.
> This happens because the a-variable is not initiated within the plot statement.
> I find when trying: a=0; plot [0:1] a*x, a=a+1, a*x
> - while toggling the grid I see that the first plot shows '1x' and
> 2x, while the second version shows: '3x' and '4x'.
So initialize it inside. That still doesn't constitute a need to do
something after the last of the data sets.
> The sole issue of mine is that gnuplot version 4.4 rc1 breaks backward
> compatibility
No, it doesn't. It's not an issue of compatibility if something that
was never promised to work, stops to.
> below - that it is gnuplot 4.4.0 rc1 that is at odds with the
> documentation.
I disagree with that claim. It was the earlier versions that were at
odds with the documentation, by allowing things that the documentation
said they didn't.
> c) In the briefer usage instruction (repeated below) I notice the
> optional trailing comma after definitions {,}, I also notice the
> replaceable <function>.
And that means that a function (or datafile), _has_ to be there. If
it's not, that's disallowed by the syntax of the command.
> Considering the interpretation of item c), practical experience with
> gnuplot versions 4.3, 4.2, 4.0,..., suggest that there is no need for
> a trailing comma after a definition if there is no trailing
> <function>, here <function> can be replaced by nothing. In my opinion,
> the latter is a reasonable interpretation which is supported by
> historic gnuplot implementations. See the brief usage instruction:
> plot {<ranges>}
> {<iteration>}
> {<function> | {"<datafile>" {datafile-modifiers}}}
> {axes <axes>} {<title-spec>} {with <style>}
> {, {definitions{,}} <function> ...}
Well, since you want to base claims on history, let's step back just one
release from 4.4-rc1, to 4.2pl5:
Syntax:
plot {<ranges>}
{<function> | {"<datafile>" {datafile-modifiers}}}
{axes <axes>} {<title-spec>} {with <style>}
{, {definitions,} <function> ...}
Note how that rather explicitly used to _require_ a comma after every
definition, thereby forbidding what you were doing. The only bug to be
fixed here is in the old versions not flagging this usage error.
|
|
From: Teo S B. <teo...@gm...> - 2010-02-14 22:38:31
|
I gave an argument for allowing trailing definitions at bottom of http://article.gmane.org/gmane.comp.graphics.gnuplot.devel/9253 2010/2/14 Hans-Bernhard Bröker <HBB...@t-...>: > Teo S Bernhard wrote: <snipped> >> - that it is gnuplot 4.4.0 rc1 that is at odds with the >> documentation. > > I disagree with that claim. It was the earlier versions that were at odds > with the documentation, by allowing things that the documentation said they > didn't. I can agree that we have error if there is mismatch between program behaviour and documentation. It is, however, a matter of philosophy if it is the help text or the implementation that is in error. In another reply I point to facts: 1) the BNF of the help text contradicts a certain help text example showing leading definitions, and 2) the help text and the actual implementation (the code) is much more liberal than the BNF-form in allowing definitions including trailing ones Here, I think the BNF is wrong. In the another reply I have suggested a more correct BNF that is consistent with program behaviour and the other help text. Teo |
|
From: Teo S B. <teo...@gm...> - 2010-02-14 22:18:06
|
I gave an argument for allowing trailing definitions at bottom of http://article.gmane.org/gmane.comp.graphics.gnuplot.devel/9253 On Sun, Feb 14, 2010 at 9:24 PM, Ethan Merritt <merritt@u.washington.edu> wrote: > On Sunday 14 February 2010, Teo S Bernhard wrote: >> historic gnuplot implementations. See the brief usage instruction: >> plot {<ranges>} >> {<iteration>} >> {<function> | {"<datafile>" {datafile-modifiers}}} >> {axes <axes>} {<title-spec>} {with <style>} >> {, {definitions{,}} <function> ...} > > You are not interpreting this BNF description correctly. > The meaning of the final line quoted immediately above is > "If you append a comma you must follow it with a function. > The function may optionally be preceded by a definition, > with or without a separating comma." > > The <function> element is not in curly brackets, and hence is > not optional. There is no expansion of this set of BNF rules that > results in a trailing definition. So no, the documentation > has never stated that a trailing definition was valid syntax. Agreed, but strict interpretation of this BNF does also tell that initial definitions are disallowed. This contradicts a given example of 'help plot' (version 4.2). plot f(x) = sin(x*a), a = .2, f(x), a = .4, f(x) Given also that the help text of gnuplot 4.2 says, from 'help plot': "It is also possible to define functions and parameters on the `plot` command itself. This is done merely by isolating them from other items with commas." The implementation of gnuplot 4.2 and 4.3 allows in a quite liberal form definitions at both leading and trailing end of the plot command as long a they are separated by comma, example: plot f(x) = sin(x*a), a = .2, f(x), a = .4, f(x), a=0.6 IMHO, the stated BNF contradicts other parts of the help text and also the actual code-implementation. For the historic (pre 4.4 rc1) gnuplot versions, a BNF consistent with other help text and code-implementation (considering definitions mainly) should be roughly: plot {<ranges>} {<iteration>} {definitions,}... { <function> | {"<datafile>" {datafile-modifiers}}} {axes <axes>} {<title-spec>} {with <style>} {,definitions}... {,<function>... } It is obviously a philosophical point, if implementation or documentation should govern. I think the historical implementation in this case. Teo |
|
From: Petr M. <mi...@ph...> - 2010-02-18 16:16:11
|
> plot f(x) = sin(x*a), a = .2, f(x), a = .4, f(x) > > plot f(x) = sin(x*a), a = .2, f(x), a = .4, f(x), a=0.6 > > IMHO, the stated BNF contradicts other parts of the help text and also > the actual code-implementation. > > I think the historical implementation in this case. I agree -- if it is easily possible to comply with previous versions of gnuplot, we should keep this compatibility. Morever, if users wish this. Imperfectins in documentation should then be improved. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2010-02-18 18:36:39
|
On Thursday 18 February 2010 08:15:59 Petr Mikulik wrote:
[re: modifying the code to allow a trailing definition inside a plot command]
> I agree -- if it is easily possible to comply with previous versions of
> gnuplot, we should keep this compatibility. Morever, if users wish this.
> Imperfectins in documentation should then be improved.
After applying the proposed patch (copied below), I get:
gnuplot> plot for [i=1:10] i,a=0
Segmentation fault
On Sunday 14 February 2010, Teo S Bernhard wrote:
diff -r ca8b5fbc043a plot2d.c
--- a/plot2d.c Sun Feb 14 14:45:12 2010 +0100
+++ b/plot2d.c Sun Feb 14 16:45:27 2010 +0100
@@ -1459,7 +1459,7 @@
if (is_definition(c_token)) {
define();
- if (!equals(c_token,",")) {
+ if (!END_OF_COMMAND && !equals(c_token,",")) {
was_definition = TRUE;
continue;
}
@@ -2174,7 +2174,7 @@
if (is_definition(c_token)) {
define();
- if (!equals(c_token,",")) {
+ if (!END_OF_COMMAND && !equals(c_token,",")) {
was_definition = TRUE;
continue;
}
|
|
From: Teo S B. <teo...@gm...> - 2010-02-18 20:02:09
|
On Thu, Feb 18, 2010 at 7:35 PM, Ethan Merritt <merritt@u.washington.edu> wrote: > After applying the proposed patch (copied below), I get: > gnuplot> plot for [i=1:10] i,a=0 > Segmentation fault The above parses and plots as expected here, using source from: http://sourceforge.net/projects/gnuplot/files/gnuplot/4.4.0-rc1/gnuplot-4.4.0-rc1.tar.gz - unmodifed plot2d.c, md5sum: c9fb6329e50c3b297fa63b9050b8c997 plot2d.c - plot2d.c after patch, md5sum: 089ab0441b088a21a6bc0914899a1bb1 plot2d.c Teo |
