Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2012-01-16 15:13:11
|
Hi,
I am wanting to run fit on each section of a long, indexed datafile.
While the symmetry of the syntax between plot and fit means this is
syntactically possible, it is in fact useless since only the final
fitted parameters are retained.
A similar problem occurs if I split the data file into separate files
and use the iteration feature.
help fit states:
<datafile> is treated as in the `plot` command. All the `plot datafile`
modifiers (`using`, `every`,...) except `smooth` and the deprecated `thru`
are applicable to `fit`. See `plot datafile`.
help plot | datafile :
Syntax:
plot '<file_name>' {binary <binary list>}
{{nonuniform} matrix}
{index <index list> | index "<name>"}
{every <every list>}
{thru <thru expression>}
{using <using list>}
{smooth <option>}
{volatile} {noautoscale}
One work around would be to try to process the fit log but since there
are other calls to fit this seems error prone and cumbersome.
>>
Final set of parameters Asymptotic Standard Error
======================= ==========================
Td = -0.294853 +/- 0.003685 (1.25%)
>>
A more optimal solution that would take full advantage of what is
possible in the syntax but seems currently in-exploitable would be if
the final fit results were stored in an internal array in the variable
name space for each call to fit.
Thus a call to fit with an iteration or an indexed datafile would
produce an array of all the fit results (presumably with NaN if the fit
fails).
regards, Peter.
|
|
From: Peter J. <pet...@gm...> - 2012-01-16 15:41:48
|
On Mon, Jan 16, 2012 at 10:50 AM, <pl...@pi...> wrote:
> Hi,
>
> I am wanting to run fit on each section of a long, indexed datafile.
> While the symmetry of the syntax between plot and fit means this is
> syntactically possible, it is in fact useless since only the final
> fitted parameters are retained.
> [...]
With the soon-to-be-released new version it is possible to do the following:
do for [i=0:10] {
fit a*x+b 'data.dat' index i via a,b
# do whatever you want with a,b, for example
eval(sprintf("a_%d=a;b_%d=b",i,i))
}
Péter Juhász
}
|
|
From: <pl...@pi...> - 2012-01-16 18:36:31
|
On 01/16/12 16:41, Peter Juhasz wrote:
> On Mon, Jan 16, 2012 at 10:50 AM,<pl...@pi...> wrote:
>> Hi,
>>
>> I am wanting to run fit on each section of a long, indexed datafile.
>> While the symmetry of the syntax between plot and fit means this is
>> syntactically possible, it is in fact useless since only the final
>> fitted parameters are retained.
>> [...]
>
> With the soon-to-be-released new version it is possible to do the following:
>
> do for [i=0:10] {
> fit a*x+b 'data.dat' index i via a,b
> # do whatever you want with a,b, for example
> eval(sprintf("a_%d=a;b_%d=b",i,i))
> }
>
> Péter Juhász
> }
>
Hey , I can already do it !
I have a recent cvs build , I just thought this was still in long term
future planning. Brilliant.
I see it is under 'help do' but not 'help for'.
gnuplot> help for
Ambiguous request 'for'; possible matches:
format
fortran
Probably helpful to include it there too.
Thanks to the team for including this already , this opens up a word of
possibilities.
thanks Péter for bringing me upto date.
Is there any overall documentation for the new block structures or do I
have to guess the keywords to get individual syntax?
regards, Peter.
|
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-01-17 02:02:32
|
On Monday, 16 January 2012, pl...@pi... wrote:
> On 01/16/12 16:41, Peter Juhasz wrote:
> > On Mon, Jan 16, 2012 at 10:50 AM,<pl...@pi...> wrote:
> >> Hi,
> >>
> >> I am wanting to run fit on each section of a long, indexed datafile.
> >> While the symmetry of the syntax between plot and fit means this is
> >> syntactically possible, it is in fact useless since only the final
> >> fitted parameters are retained.
> >> [...]
> >
> > With the soon-to-be-released new version it is possible to do the following:
> >
> > do for [i=0:10] {
> > fit a*x+b 'data.dat' index i via a,b
> > # do whatever you want with a,b, for example
> > eval(sprintf("a_%d=a;b_%d=b",i,i))
> > }
> >
> > Péter Juhász
> > }
> >
>
> Hey , I can already do it !
>
> I have a recent cvs build , I just thought this was still in long term
> future planning. Brilliant.
>
> I see it is under 'help do' but not 'help for'.
>
> gnuplot> help for
> Ambiguous request 'for'; possible matches:
> format
> fortran
>
> Probably helpful to include it there too.
>
> Thanks to the team for including this already , this opens up a word of
> possibilities.
> thanks Péter for bringing me upto date.
>
> Is there any overall documentation for the new block structures or do I
> have to guess the keywords to get individual syntax?
There's an introduction under "help new-features".
The inclusion of a New Features section works better in the printed
docs than it does in the on-line help.
|
|
From: Peter J. <pet...@gm...> - 2012-01-17 09:14:36
|
On Tue, Jan 17, 2012 at 3:02 AM, sfeam (Ethan Merritt)
<eam...@gm...> wrote:
> On Monday, 16 January 2012, pl...@pi... wrote:
>> On 01/16/12 16:41, Peter Juhasz wrote:
>> > On Mon, Jan 16, 2012 at 10:50 AM,<pl...@pi...> wrote:
>> >> Hi,
>> >>
>> >> I am wanting to run fit on each section of a long, indexed datafile.
>> >> While the symmetry of the syntax between plot and fit means this is
>> >> syntactically possible, it is in fact useless since only the final
>> >> fitted parameters are retained.
>> >> [...]
>> >
>> > With the soon-to-be-released new version it is possible to do the following:
>> >
>> > do for [i=0:10] {
>> > fit a*x+b 'data.dat' index i via a,b
>> > # do whatever you want with a,b, for example
>> > eval(sprintf("a_%d=a;b_%d=b",i,i))
>> > }
>> >
>> > Péter Juhász
>> > }
>> >
>>
>> Hey , I can already do it !
>>
>> I have a recent cvs build , I just thought this was still in long term
>> future planning. Brilliant.
>>
>> I see it is under 'help do' but not 'help for'.
>>
>> gnuplot> help for
>> Ambiguous request 'for'; possible matches:
>> format
>> fortran
>>
>> Probably helpful to include it there too.
>>
>> Thanks to the team for including this already , this opens up a word of
>> possibilities.
>> thanks Péter for bringing me upto date.
>>
>> Is there any overall documentation for the new block structures or do I
>> have to guess the keywords to get individual syntax?
>
> There's an introduction under "help new-features".
> The inclusion of a New Features section works better in the printed
> docs than it does in the on-line help.
>
Perhaps the pointer to 'help new-features' could be added to the
splash screen, at least for the first 4.6 series release.
Péter Juhász
|
|
From: <pl...@pi...> - 2012-01-20 10:53:55
|
Hi, in experiment with new iteration feature I found it does not seem to be applied correctly (ie usefully) to the automatic title in the key plot for [date in "1881 1883"] "dataset-".date.".dat" unless I explicitly set a title both plots get an identical entry in the legend : "dataset-".date.".dat" This would seem to render the legend key entries somewhat useless. It also seems illogical that it expands the filename to be plotted but does not expand the entry in the legend. Is this an oversight or am I missing some cunningly useful feature? Best regards, Peter. |
|
From: Ethan M. <merritt@u.washington.edu> - 2012-01-20 17:33:39
|
On Friday, 20 January 2012, pl...@pi... wrote:
> Hi,
>
> in experiment with new iteration feature I found it does not seem to be
> applied correctly (ie usefully) to the automatic title in the key
>
> plot for [date in "1881 1883"] "dataset-".date.".dat"
>
> unless I explicitly set a title both plots get an identical entry in the
> legend : "dataset-".date.".dat"
>
> This would seem to render the legend key entries somewhat useless. It
> also seems illogical that it expands the filename to be plotted but does
> not expand the entry in the legend.
>
> Is this an oversight or am I missing some cunningly useful feature?
I can see arguments either way.
Take the very simple case
x = 5
plot sin(x)/x
Do you expect the plot key to show "sin(x)/x" or "-0.19178"?
Or, closer to your example,
Data(year) = "dataset-".date.".dat"
plot Data(1881)
Do you expect the plot key to show "dataset-1881.dat" or "Data(1881)"?
>
> Best regards, Peter.
|
|
From: <pl...@pi...> - 2012-01-20 18:19:29
|
On 01/20/12 13:24, Peter Juhasz wrote: > On Fri, Jan 20, 2012 at 10:40 AM,<pl...@pi...> wrote: >> Hi, >> >> in experiment with new iteration feature I found it does not seem to be >> applied correctly (ie usefully) to the automatic title in the key >> >> plot for [date in "1881 1883"] "dataset-".date.".dat" >> >> unless I explicitly set a title both plots get an identical entry in the >> legend : "dataset-".date.".dat" >> >> This would seem to render the legend key entries somewhat useless. It >> also seems illogical that it expands the filename to be plotted but does >> not expand the entry in the legend. >> >> Is this an oversight or am I missing some cunningly useful feature? >> >> Best regards, Peter. > > The automatic title for data files is the file name plus the using > spec, as a string. > Perhaps it could be arranged that the iteration variable(s) (but not > other variables) are substituted in, but for now, you have to set the > title explicitly. > See the bright side of it: you are free to set a more informative > title, e.g. "Data for the year ".date". A.D.". I'd say that's useful, > even if not cunningly. > > Péter Juhász > Thanks, so bug rather than feature. Not a major problem but I thought I'd flag it. Oddly if I put the same thing as title it does get expanded. plot for [date in "1881 1883"] "dataset-".date.".dat" tit "dataset-".date.".dat" Just seems rather pointless (and verbose) repetition to achieve what it standard behaviour without iteration. Probably a detail that got missed. regards. |
|
From: <pl...@pi...> - 2012-01-20 18:44:37
|
On 01/20/12 18:32, Ethan Merritt wrote: > On Friday, 20 January 2012, pl...@pi... wrote: >> Hi, >> >> in experiment with new iteration feature I found it does not seem to be >> applied correctly (ie usefully) to the automatic title in the key >> >> >> >> unless I explicitly set a title both plots get an identical entry in the >> legend : "dataset-".date.".dat" >> >> This would seem to render the legend key entries somewhat useless. It >> also seems illogical that it expands the filename to be plotted but does >> not expand the entry in the legend. >> >> Is this an oversight or am I missing some cunningly useful feature? > > I can see arguments either way. > > Take the very simple case > x = 5 > plot sin(x)/x > Do you expect the plot key to show "sin(x)/x" or "-0.19178"? > > Or, closer to your example, > Data(year) = "dataset-".date.".dat" > plot Data(1881) > Do you expect the plot key to show "dataset-1881.dat" or "Data(1881)"? > > > >> >> Best regards, Peter. > Ethan , I don't think you understood what I was reporting. None of those examples seems to have anything to do with iteration. What I was expecting to see was that the substitution done by for [...] would be applied to the file name and each file name would be used as the default title , as is usually the case without iteration. having a legend that looks like: "dataset-".date.".dat" "dataset-".date.".dat" "dataset-".date.".dat" "dataset-".date.".dat" is certainly of no use , so one is obliged to set it explicitly . plot for [date in "1881 1883"] "dataset-".date.".dat" tit "dataset-".date.".dat" No harm done but its a bit messy. regards. |
|
From: Ethan M. <merritt@u.washington.edu> - 2012-01-20 19:32:19
|
On Friday, 20 January 2012, pl...@pi... wrote: > On 01/20/12 18:32, Ethan Merritt wrote: > > On Friday, 20 January 2012, pl...@pi... wrote: > >> Hi, > >> > >> in experiment with new iteration feature I found it does not seem to be > >> applied correctly (ie usefully) to the automatic title in the key > >> > >> > > >> > >> unless I explicitly set a title both plots get an identical entry in the > >> legend : "dataset-".date.".dat" > >> > >> This would seem to render the legend key entries somewhat useless. It > >> also seems illogical that it expands the filename to be plotted but does > >> not expand the entry in the legend. > >> > >> Is this an oversight or am I missing some cunningly useful feature? > > > > I can see arguments either way. > > > > Take the very simple case > > x = 5 > > plot sin(x)/x > > Do you expect the plot key to show "sin(x)/x" or "-0.19178"? > > > > Or, closer to your example, > > Data(year) = "dataset-".date.".dat" > > plot Data(1881) > > Do you expect the plot key to show "dataset-1881.dat" or "Data(1881)"? > > > > > > > >> > >> Best regards, Peter. > > > > Ethan , I don't think you understood what I was reporting. > > None of those examples seems to have anything to do with iteration. Correct. But the behaviour you were reporting is not specific to iteration. The point is that in order to generate the key title, the program takes the expression being plotted as a literal string, _without evaluation_. I gave two examples where this is (I think) the correct thing to do, but I can easily imagine that there are other cases where it is not necessarily the best thing to do. Perhaps being inside an iteration loop is one of these cases. > What I was expecting to see was that the substitution done by for [...] > would be applied to the file name and each file name would be used as > the default title , as is usually the case without iteration. Can you give an example? I can't think of a case where such substitution is done in the case without iteration. E.g. A = "filename.dat" plot A This will use "A" as the plot title, not "filename.dat". Ethan > > > having a legend that looks like: > > "dataset-".date.".dat" > "dataset-".date.".dat" > "dataset-".date.".dat" > "dataset-".date.".dat" > > is certainly of no use , so one is obliged to set it explicitly . > > plot for [date in "1881 1883"] "dataset-".date.".dat" tit > "dataset-".date.".dat" > > No harm done but its a bit messy. > > regards. > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: <pl...@pi...> - 2012-01-20 21:09:32
|
On 01/20/12 20:29, Ethan Merritt wrote: > I gave two examples where this is (I think) the correct thing > to do, but I can easily imagine that there are other cases where > it is not necessarily the best thing to do. Perhaps being > inside an iteration loop is one of these cases. The two examples you gave make sense. this has been the case previously and works well. The iteration loop would probably create equally unexpected results if it started doing full evaluation. All I was suggesting is that the substitutions that are made by iteration are also applied to the title plot "datafile1", "datafile2" , "datafile3" creates a legend datafile1 ------- datafile2 ------- datafile3 ------- I am suggesting that plot for [i in "1 2 3"] "datefile".i does the same instead of: "datefile".i ------ "datefile".i ------ "datefile".i ------ Peter. |
|
From: Ethan M. <merritt@u.washington.edu> - 2012-01-20 20:17:41
|
On Friday, 20 January 2012, pl...@pi... wrote: > On 01/20/12 20:29, Ethan Merritt wrote: > > I gave two examples where this is (I think) the correct thing > > to do, but I can easily imagine that there are other cases where > > it is not necessarily the best thing to do. Perhaps being > > inside an iteration loop is one of these cases. > > The two examples you gave make sense. this has been the case previously > and works well. > > The iteration loop would probably create equally unexpected results if > it started doing full evaluation. All I was suggesting is that the > substitutions that are made by iteration are also applied to the title > > plot "datafile1", "datafile2" , "datafile3" > > creates a legend > > datafile1 ------- > datafile2 ------- > datafile3 ------- > > I am suggesting that > > plot for [i in "1 2 3"] "datefile".i > > does the same instead of: > > "datefile".i ------ > "datefile".i ------ > "datefile".i ------ But how do you suggest that the program would do this partial evaluation? There is no mechanism for saying "evaluate this expression only to the extent of terms that involve a particular variable". I understand the issue you are raising, but I still don't think it has anything in particular to do with iteration. If you say (no iteration) i = 3 plot "datafile.".i then the autogenerated title is not 'datafile.3', it is '"datafile.".i'. That's probably not what you want, but how is the program to guess this? In the equally plausible case File(x) = "datafile.".x plot File(3) then the autogenerated title "File(3)" _is_ what you probably want. So in one case you want evaluation but in the other case you do not. How can the program distinguish the two cases automatically? Ethan |
|
From: <pl...@pi...> - 2012-01-21 10:34:01
|
On 01/20/12 21:15, Ethan Merritt wrote: > On Friday, 20 January 2012, pl...@pi... wrote: >> On 01/20/12 20:29, Ethan Merritt wrote: >>> I gave two examples where this is (I think) the correct thing >>> to do, but I can easily imagine that there are other cases where >>> it is not necessarily the best thing to do. Perhaps being >>> inside an iteration loop is one of these cases. >> >> The two examples you gave make sense. this has been the case previously >> and works well. >> >> The iteration loop would probably create equally unexpected results if >> it started doing full evaluation. All I was suggesting is that the >> substitutions that are made by iteration are also applied to the title >> >> plot "datafile1", "datafile2" , "datafile3" >> >> creates a legend >> >> datafile1 ------- >> datafile2 ------- >> datafile3 ------- >> >> I am suggesting that >> >> plot for [i in "1 2 3"] "datefile".i >> >> does the same instead of: >> >> "datefile".i ------ >> "datefile".i ------ >> "datefile".i ------ > > But how do you suggest that the program would do this partial > evaluation? There is no mechanism for saying "evaluate this > expression only to the extent of terms that involve a particular > variable". > > I understand the issue you are raising, but I still don't think > it has anything in particular to do with iteration. > If you say (no iteration) > i = 3 > plot "datafile.".i > then the autogenerated title is not 'datafile.3', > it is '"datafile.".i'. > > That's probably not what you want, but how is the program to > guess this? In the equally plausible case > File(x) = "datafile.".x > plot File(3) > then the autogenerated title "File(3)" _is_ what you probably want. > So in one case you want evaluation but in the other case you do not. > How can the program distinguish the two cases automatically? > > Ethan > I don't intend to participate in another interminable discussion. I have raised the issue, if you don't wish to fix it or regard it as a "feature", fine. It's not preventing me from working or enjoying life. I just posted another instance where iteration error reports are unhelpful. I think as more people use this new feature other aspects of the problem will arise and maybe it will be seen as useful to see whether iteration requires special treatment. Until then, I'm off to get on with plotting. Peter. |
