Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2012-01-21 09:24:00
|
Hi,
a further manifestation of the way iteration substitutions can be unhelpful.
plot for [date in "1894 1802"] "dataset-".date."+.hFFT.dat"
^
Bad data on line 2
in case that does not display consistently on various formats please
note that the caret is aligned under the double-quote following .date.
end before the plus sign.
It is clearly unhelpful that we don't know which manifestation of [date
in "1894 1802"] causes the problem.
Since messing with display of the caret and the command line may lead to
further confusion and may even be counter productive, perhaps it would
be useful for the error message to append information of the value of
the iteration value when iteration is present.
eg.
Bad data on line 2 , during iteration : date = "1894"
best regards, Peter.
|
|
From: Juhász P. <pet...@gm...> - 2012-01-21 10:53:29
|
On Sat, 2012-01-21 at 09:49 +0100, pl...@pi... wrote:
> Hi,
>
> a further manifestation of the way iteration substitutions can be unhelpful.
>
> plot for [date in "1894 1802"] "dataset-".date."+.hFFT.dat"
>
> ^
> Bad data on line 2
>
>
> in case that does not display consistently on various formats please
> note that the caret is aligned under the double-quote following .date.
> end before the plus sign.
>
> It is clearly unhelpful that we don't know which manifestation of [date
> in "1894 1802"] causes the problem.
>
> Since messing with display of the caret and the command line may lead to
> further confusion and may even be counter productive, perhaps it would
> be useful for the error message to append information of the value of
> the iteration value when iteration is present.
>
> eg.
>
> Bad data on line 2 , during iteration : date = "1894"
>
> best regards, Peter.
>
Actually, this error message would not be helpful at all.
AFAIK the "Bad data on line x" message tells you that there is bad data
*in your data file*.
Now if you were making the point that it would be helpful if the program
told you *which file* contained the bad data, you'd be right.
So perhaps a special provision could be made that in case of iteration
(where a single using spec can specify multiple plots, and a caret under
the line won't tell you which of them is at fault), the error message
should include the (expanded, evaluated) file name, e.g.
Bad data on line 2 , in file "dataset-1894+.hFFT.dat"
But even this would be tricky, because it's not only file names that you
can iterate over. Consider
plot for [i=0:10] "file.dat" index i
where file.dat has less than 11 blocks.
In this case including the file name in the error message would be
superfluous.
Anyway, the way iteration is currently implemented makes it hard to make
any of these proposed changes. The way it works: when the code that
parses the "plot" command senses the iteration construct (for [...]), it
initializes the iteration variable to its first possible value, then
goes on processing the plot command as usual. Then it jumps back to the
start of the plot command, increments the iteration variable and
processes the plot command again - and again, until it exhausts the list
of possible values for the iterator. The point is that from the
standpoint of the plot command (or any other part of the code) there is
nothing special about the iteration variable.
Péter Juhász
|
|
From: <pl...@pi...> - 2012-01-21 12:39:28
|
On 01/21/12 11:53, Juhász Péter wrote:
> On Sat, 2012-01-21 at 09:49 +0100, pl...@pi... wrote:
>> Hi,
>>
>> a further manifestation of the way iteration substitutions can be unhelpful.
>>
>> plot for [date in "1894 1802"] "dataset-".date."+.hFFT.dat"
>>
>> ^
>> Bad data on line 2
>>
>>
>> in case that does not display consistently on various formats please
>> note that the caret is aligned under the double-quote following .date.
>> end before the plus sign.
>>
>> It is clearly unhelpful that we don't know which manifestation of [date
>> in "1894 1802"] causes the problem.
>>
>> Since messing with display of the caret and the command line may lead to
>> further confusion and may even be counter productive, perhaps it would
>> be useful for the error message to append information of the value of
>> the iteration value when iteration is present.
>>
>> eg.
>>
>> Bad data on line 2 , during iteration : date = "1894"
>>
>> best regards, Peter.
>>
>
> Actually, this error message would not be helpful at all.
>
> AFAIK the "Bad data on line x" message tells you that there is bad data
> *in your data file*.
>
> Now if you were making the point that it would be helpful if the program
> told you *which file* contained the bad data, you'd be right.
>
Yes , that's exactly my point. I know it's a data error but I don't know
where to look.
> So perhaps a special provision could be made that in case of iteration
> (where a single using spec can specify multiple plots, and a caret under
> the line won't tell you which of them is at fault), the error message
> should include the (expanded, evaluated) file name, e.g.
>
> Bad data on line 2 , in file "dataset-1894+.hFFT.dat"
>
> But even this would be tricky, because it's not only file names that you
> can iterate over. Consider
>
> plot for [i=0:10] "file.dat" index i
>
> where file.dat has less than 11 blocks.
> In this case including the file name in the error message would be
> superfluous.
Which is why I suggest outputting the iteration variable's value at that
point rather than the expanded filename.
review my last post:
eg.
Bad data on line 2 , during iteration : date = "1894"
>
> Anyway, the way iteration is currently implemented makes it hard to make
> any of these proposed changes. The way it works: when the code that
> parses the "plot" command senses the iteration construct (for [...]), it
> initializes the iteration variable to its first possible value, then
> goes on processing the plot command as usual. Then it jumps back to the
> start of the plot command, increments the iteration variable and
> processes the plot command again - and again, until it exhausts the list
> of possible values for the iterator. The point is that from the
> standpoint of the plot command (or any other part of the code) there is
> nothing special about the iteration variable.
Thanks for the explanation. It helps to see what is happening.
This could easily be got around by storing a tmp variable that could be
accessible to any error trapping code that indicates, first of all if an
iteration is active (by its not being null), second the variable in
question and finally its value.
Then any and all error trapping could be made to output such a value as
I suggested in the case where an iteration is under way.
>
> Péter Juhász
>
>
Thanks
|
|
From: Ethan M. <merritt@u.washington.edu> - 2012-01-22 01:32:08
|
On Saturday, 21 January 2012, pl...@pi... wrote: > > AFAIK the "Bad data on line x" message tells you that there is bad data > > *in your data file*. > > > > Now if you were making the point that it would be helpful if the program > > told you which file contained the bad data, you'd be right. > > Yes , that's exactly my point. I know it's a data error but I don't know > where to look. OK. That much is easy to improve. We can easily report the name of the current data file as well as the current line. I'll add this to 4.5 CVS. Ethan |
