gnuplot-beta — Developers and beta testers of new gnuplot code

Re: mouse zoom centred on mouse position.

[Tait <gnu...@t4...>]

> Are you saying that you are using some commonly used software that has a
> sufficiently large user-base  that it should be weighed into a
> discussion on finding some commonality ?
>
> If so , what is it?
>
> regards.

I didn't have any one particular software in mind, just a common theme
that seems to apply to programs I've used: mapping (e.g. Google Earth,
NGTE), VRML viewers (e.g. web browsers), document viewers for PDF
(e.g. Acrobat), image editing (e.g. Photoshop), and solid design (CAD
programs like AutoCad or SolidWorks).

A common exception seems to be using ctrl+wheel for radial/zoom control
(like Windows, Mathematica, web browsers).

Re: mouse zoom centred on mouse position.

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday, 20 June 2012, pl...@pi... wrote:
> On 06/20/12 14:27, Tait wrote:
> >> I would propose to revise mouse zooming to comply more with that used in map
> >> >software (maps.google.com, mapy.cz etc.). Thus:
> >> >- mouse wheel zooms around current mouse position (it could zoom around
> >> >   center if mouse is outside graph border)
> >> >- Shift-wheel would move graph up/down (as now without Shift)
> >> >- Ctrl-wheel would move graph left/right (now with Shift)
> 
> > I'm used to  [...]
> > the normal unmodified use of the scrollwheel for vertical and
> > horizontal scrolling
> 
> Are you saying that you are using some commonly used software that has a 
> sufficiently large user-base  that it should be weighed into a 
> discussion on finding some commonality ?
> 
> If so , what is it?

  Every web browser?

FWIW, I think that mouse "button events" 4+5 are in the X11 protocol
as up/down scroll, while button events 6+7 are left/right scroll.
Most mouse wheels send events 4+5, although sometimes you can 
reconfigure this in the mouse driver (or xconfig).  At Mojca's
suggestion, we added 6+7 as left/right scroll recently because it
seems that touch-screen devices use this same set of event codes
to indicate up/down left/right dragging.  I don't so much care 
what convention gnuplot uses for a "real" mouse wheel, but I
think it is important that it is interpreted as left/right up/down
scrolling on a touch screen.

	Ethan

Re: mouse zoom centred on mouse position.

[<pl...@pi...>]

On 06/20/12 14:27, Tait wrote:
>> I would propose to revise mouse zooming to comply more with that used in map
>> >software (maps.google.com, mapy.cz etc.). Thus:
>> >- mouse wheel zooms around current mouse position (it could zoom around
>> >   center if mouse is outside graph border)
>> >- Shift-wheel would move graph up/down (as now without Shift)
>> >- Ctrl-wheel would move graph left/right (now with Shift)

> I'm used to  ...

Are you saying that you are using some commonly used software that has a 
sufficiently large user-base  that it should be weighed into a 
discussion on finding some commonality ?

If so , what is it?

regards.

Re: mouse zoom centred on mouse position.

[Tait <gnu...@t4...>]

> I would propose to revise mouse zooming to comply more with that used in map
> software (maps.google.com, mapy.cz etc.). Thus:
> - mouse wheel zooms around current mouse position (it could zoom around
>   center if mouse is outside graph border)
> - Shift-wheel would move graph up/down (as now without Shift)
> - Ctrl-wheel would move graph left/right (now with Shift)

I'm used to shift+scrollwheel adjusting altitude, ctrl+scrollwheel
adjusting azimuth, and meta or alt+scrollwheel being zoom. In a 2D
environment, I suppose there's some logical sense to altitude being
vertical scroll and azimuth being horizontal scroll, but this overlaps
with the normal unmodified use of the scrollwheel for vertical and
horizontal scrolling. (On mice without a horizontal scrollwheel axis,
I guess just vertical scrolling?)

For consistency, wouldn't we want similar bindings for the arrow keys?

Re: mouse zoom centred on mouse position.

[<pl...@pi...>]

On 06/20/12 10:31, Mojca Miklavec wrote:
> On Wed, Jun 20, 2012 at 10:25 AM, Mojca Miklavec wrote:
>> On Wed, Jun 20, 2012 at 7:46 AM, Petr Mikulik wrote:
>>>
>>> I would propose to revise mouse zooming to comply more with that used in map
>>> software (maps.google.com, mapy.cz etc.). Thus:
>>> - mouse wheel zooms around current mouse position (it could zoom around
>>>   center if mouse is outside graph border)
>>> - Shift-wheel would move graph up/down (as now without Shift)
>>> - Ctrl-wheel would move graph left/right (now with Shift)
>>
>> You forgot that google maps allows you to "drag and drop" to move
>> around the map. I believe that is not an option for gnuplot
>
> I'm sorry. I mixed up left & right click. The right click zooms into
> the region, so the right click is already taken (not the left one),
> while left click doesn't seem to do anything. So the left click (drag
> and drop) could actually be used to move the graph around.

Yes, map style dragging may be a useful extension of mouse control and I 
don't think any of the mouse aware terms are using that kind of button1 
event.

One major defect I find with the current mouse control is the need to 
take my eye off the screen to find shift or cntl keys.

I see no reason why vert scroll should be privileged and monopolise the 
whole plot surface.

It may be an improvement if vert and horizontal scrolling were effected 
by mouse scroll on the areas between the relative axis and the window 
edge. This would leave the graph area itself free for zoom without the 
need for an additional keyboard interaction.

Thus both scroll actions and zoom would be freed of the need for 
keyboard. This would be a lot easier to use.

>
>> The program I'm using now allows to select a range on x axis (drag and
>> drop just next to the axis) and a range on y axis (separately) to zoom
>> into selected range. That is also a lot more intuitive (once you know
>> about the option) and allows for selecting the area of interest with
>> great precision.
>
> ... but that is already possible with the left mouse button anyway.
>
> Another nice gesture (in a different program that I'm using) is
> double-clicking bringing you back to original/default zoom & position.

There is already a button for that in wxt and dbl-clk event pastes 
current coords under mouse to paste board. This is a feature I have used 
quite a bit just this week.

The only drawback I have with this feature is that it does not get 
picked up by the X11 copy buffer that can be pasted with button-3 click 
(mouse wheel) which is so much faster than using context menus to find 
paste or dropping the mouse to do cntl-v.

I guess that may not be possible since the text copied is never on an 
Xwindow in the first place, unless there is a trick that could achieve 
that.

Peter.

Re: mouse zoom centred on mouse position.

[Mojca M. <moj...@gm...>]

On Wed, Jun 20, 2012 at 10:25 AM, Mojca Miklavec wrote:
> On Wed, Jun 20, 2012 at 7:46 AM, Petr Mikulik wrote:
>>
>> I would propose to revise mouse zooming to comply more with that used in map
>> software (maps.google.com, mapy.cz etc.). Thus:
>> - mouse wheel zooms around current mouse position (it could zoom around
>>  center if mouse is outside graph border)
>> - Shift-wheel would move graph up/down (as now without Shift)
>> - Ctrl-wheel would move graph left/right (now with Shift)
>
> You forgot that google maps allows you to "drag and drop" to move
> around the map. I believe that is not an option for gnuplot

I'm sorry. I mixed up left & right click. The right click zooms into
the region, so the right click is already taken (not the left one),
while left click doesn't seem to do anything. So the left click (drag
and drop) could actually be used to move the graph around.

> The program I'm using now allows to select a range on x axis (drag and
> drop just next to the axis) and a range on y axis (separately) to zoom
> into selected range. That is also a lot more intuitive (once you know
> about the option) and allows for selecting the area of interest with
> great precision.

... but that is already possible with the left mouse button anyway.

Another nice gesture (in a different program that I'm using) is
double-clicking bringing you back to original/default zoom & position.

Mojca

Re: mouse zoom centred on mouse position.

[Mojca M. <moj...@gm...>]

On Wed, Jun 20, 2012 at 7:46 AM, Petr Mikulik wrote:
>
> I would propose to revise mouse zooming to comply more with that used in map
> software (maps.google.com, mapy.cz etc.). Thus:
> - mouse wheel zooms around current mouse position (it could zoom around
>  center if mouse is outside graph border)
> - Shift-wheel would move graph up/down (as now without Shift)
> - Ctrl-wheel would move graph left/right (now with Shift)

You forgot that google maps allows you to "drag and drop" to move
around the map. I believe that is not an option for gnuplot (but being
able to move around without holding some mouse button is crucial for
me to make navigation on maps at least somewhat usable).

I never use mouse wheel to scroll in google maps since it is
impossible to control the amount of zoom (clicking +/- would use at
least 17 different zoom steps, while I can only get 6 with the
"wheel"). But maybe that's only the case on macs with high precision
scrolling which is not taken into account on google maps. And I would
probably get used to it quickly if implemented properly.

> I find the current behaviour counterintuitive and thus actually not using it
> at all :-(

On modern Macs the natural way to navigate with mouse is for example
the following:
a) "wheel equivalent" (two fingers sliding on trackpad): move up/down
(like in web browsers), but also left/right - same as now
b) "pinch gesture": zoom in (usually it is uniform zooming, but one
has the information about the angle and could use that information to
zoom over a single axis, for example when angle is between +/- 22.5
degrees; and zooming in uniformly when angle is between 22.5 and 67.5
degrees etc.)

I'm not arguing against the change (I would welcome revised code
actually), I only wanted to point out that "intuitive behaviour" might
not necessary be universal across different hardware & software. I
definitely do miss more control in mousing events (being able to
scroll in smaller steps for example, or support for zooming in with a
pinch), but on the other hand the data I'm constantly dealing with
nowadays typically have 10^9 points, so I need my own viewer anyway
(to allow navigation without being awfully slow and running out of
memory, based on assumptions I can afford to take into account in my
own implementation & for my own data, not applicable to generic case
in gnuplot). And it is also true that AquaTerm would not support any
mousing at all.

The program I'm using now allows to select a range on x axis (drag and
drop just next to the axis) and a range on y axis (separately) to zoom
into selected range. That is also a lot more intuitive (once you know
about the option) and allows for selecting the area of interest with
great precision.

Mojca

Re: mouse zoom centred on mouse position.

[<pl...@pi...>]

On 06/20/12 07:46, Petr Mikulik wrote:
>>> just a quick idea to throw into the air: I was using cntl-mouse_scroll
>>> to zoom in and out on  a long data series and found myself having to
>>> adjust left and right.
>>>
>>> What  some graphics programs (and ggogleearth) do in this situation is
>>> to zoom on the mouse position.  This is a major improvement.
>>>
>>> Put the mouse over the point of interest and zoom in and out. The point
>>> of focus under the mouse stays in the same position and the rest scales
>>> and shifts around it.
>>
>> There was a preliminary patch submitted that would do this:
>>     https://sourceforge.net/tracker/index.php?func=detail&aid=2972660&group_id=2055&atid=302055
>
> I would propose to revise mouse zooming to comply more with that used in map
> software (maps.google.com, mapy.cz etc.). Thus:
> - mouse wheel zooms around current mouse position (it could zoom around
>    center if mouse is outside graph border)
> - Shift-wheel would move graph up/down (as now without Shift)
> - Ctrl-wheel would move graph left/right (now with Shift)
>
> I find the current behaviour counterintuitive and thus actually not using it
> at all :-(
>
> ---
> Petr
>
>

Hi,

I'm not sure that one is more "intuitive" that the other but I have had 
the same experience. It may just be what I'm used to from another 
interface, may be not but I find the left/right scroll to be the 
opposite of what I expect.

It would seem to be preferable to have a de facto standard and in that 
sense I would suggest bowing to number of people who will be familiar 
the google interface.

I've been using the scrolling quite a bit this week and it is a great 
feature.  (Except for not mouse centring the zoom ;)  ).

I've just about retrained my brain to go the right was most of the time 
which probably means I'll mess up next time I use google.

Falling in line with big G would seem to be the way to go.

Peter.

Re: mouse zoom centred on mouse position.

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

> > just a quick idea to throw into the air: I was using cntl-mouse_scroll 
> > to zoom in and out on  a long data series and found myself having to 
> > adjust left and right.
> > 
> > What  some graphics programs (and ggogleearth) do in this situation is 
> > to zoom on the mouse position.  This is a major improvement.
> > 
> > Put the mouse over the point of interest and zoom in and out. The point 
> > of focus under the mouse stays in the same position and the rest scales 
> > and shifts around it.
> 
> There was a preliminary patch submitted that would do this:
>    https://sourceforge.net/tracker/index.php?func=detail&aid=2972660&group_id=2055&atid=302055

I would propose to revise mouse zooming to comply more with that used in map 
software (maps.google.com, mapy.cz etc.). Thus:
- mouse wheel zooms around current mouse position (it could zoom around 
  center if mouse is outside graph border)
- Shift-wheel would move graph up/down (as now without Shift)
- Ctrl-wheel would move graph left/right (now with Shift)

I find the current behaviour counterintuitive and thus actually not using it 
at all :-(

---
Petr

Re: mouse zoom centred on mouse position.

[Ethan A M. <sf...@us...>]

On Monday, June 18, 2012 10:17:36 am pl...@pi... wrote:
> Hi,
> 
> just a quick idea to throw into the air: I was using cntl-mouse_scroll 
> to zoom in and out on  a long data series and found myself having to 
> adjust left and right.
> 
> What  some graphics programs (and ggogleearth) do in this situation is 
> to zoom on the mouse position.  This is a major improvement.
> 
> Put the mouse over the point of interest and zoom in and out. The point 
> of focus under the mouse stays in the same position and the rest scales 
> and shifts around it.

There was a preliminary patch submitted that would do this:
   https://sourceforge.net/tracker/index.php?func=detail&aid=2972660&group_id=2055&atid=302055

But it was against an earlier version of gnuplot and the submitter did
not update it.  If someone wants to pursue this idea, that might be
a good place to start.

	Ethan


> 
> I guess this would not involve much change to the code since the zoom 
> and the scroll is already there but in terms of usability it is a great 
> help.
> 
> best regards, Peter.

mouse zoom centred on mouse position.

[<pl...@pi...>]

Hi,

just a quick idea to throw into the air: I was using cntl-mouse_scroll 
to zoom in and out on  a long data series and found myself having to 
adjust left and right.

What  some graphics programs (and ggogleearth) do in this situation is 
to zoom on the mouse position.  This is a major improvement.

Put the mouse over the point of interest and zoom in and out. The point 
of focus under the mouse stays in the same position and the rest scales 
and shifts around it.

I guess this would not involve much change to the code since the zoom 
and the scroll is already there but in terms of usability it is a great 
help.

best regards, Peter.

Re: problems interpretting missing data in csv data

[Ethan A M. <sf...@us...>]

On Thursday, June 14, 2012 04:17:56 am pl...@pi... wrote:
> Hi,
> 
> I have a csv file of about 2000 lines, which has some missing data, an 
> extract :
> 
> 25.12,141.99
> 25.14,141.91
> 25.16,141.71
> 25.18,
> 25.2,
> 25.22,
> 
> 
> I thought gnuplot was quite good at guessing formats but it does not 
> shine with csv, so to get it to read the csv it used
> set datafile separator ","
> 
> Now whenever it hits one of these lines with missing data it plots 
> points way off the the right in a way I have not managed to understand. 
> x values are in the range circa 6500

I suspect you have run into a very old, very strange, "feature" of gnuplot.
Fortunately, it has recently been banished in the CVS version.

Please read the section in the User Manual about "set datafile missing".
In particular please have a look at the figure and explanation on page
105 of the User Manual for 4.7:
   http://gnuplot.sourceforge.net/gnuplot_cvs.pdf

> Am I just missing a trick ?

You didn't actually show us the plot command.
I am guessing that you neglected to provide a "using" specifier in the
plot command.  As explained in the link above, this [used to] do bad things
if not all the input lines have the same number of data fields.

Switch to the current cvs version and/or add "using 1:2" in the plot command.

Re: dgrid3d not available online, but docs still try to refer to it

[Ethan A M. <sf...@us...>]

On Thursday, June 14, 2012 09:51:07 am Hans-Bernhard Bröker wrote:
> Hello everyone,
> 
> I was just made aware that there's a little glitch with the demo URLs in 
> gnuplot's documentation.  In particular, gnuplot.doc holds this:
> 
> ^ <a href="http://www.gnuplot.info/demo/dgrid3d.html">
>   dgrid3d.dem: dgrid3d demo.
> ^ </a>
> 
> But there is no dgrid3d.html on either www.gnuplot.info or gnuplot.sf.net.
> 
> So how to fix this: upload dgrid3d.html, or remove the link from 
> gnuplot.doc?

I will add dgrid3d to the Makefile for the online demo set,
and upload it to the SourceForge demo site.

dgrid3d not available online, but docs still try to refer to it

[Hans-Bernhard B. <HBB...@t-...>]

Hello everyone,

I was just made aware that there's a little glitch with the demo URLs in 
gnuplot's documentation.  In particular, gnuplot.doc holds this:

^ <a href="http://www.gnuplot.info/demo/dgrid3d.html">
  dgrid3d.dem: dgrid3d demo.
^ </a>

But there is no dgrid3d.html on either www.gnuplot.info or gnuplot.sf.net.

So how to fix this: upload dgrid3d.html, or remove the link from 
gnuplot.doc?

problems interpretting missing data in csv data

[<pl...@pi...>]

Hi,

I have a csv file of about 2000 lines, which has some missing data, an 
extract :

25.12,141.99
25.14,141.91
25.16,141.71
25.18,
25.2,
25.22,


I thought gnuplot was quite good at guessing formats but it does not 
shine with csv, so to get it to read the csv it used
set datafile separator ","

Now whenever it hits one of these lines with missing data it plots 
points way off the the right in a way I have not managed to understand. 
x values are in the range circa 6500

I wondered whether the lcocal was doing odd things with the commas but 
it looks OK

LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

why is gnuplot not correctly handling missing data in this case (and 
what is it actually reading to get x values around 6500) ?

I previously had problems with csv and think I ended up using awk to 
preprocess but it would be nice if gnuplot could make a better stab at 
this unless that compromises other things.

Am I just missing a trick ?

Thanks.

Re: In-line data [was multiple plot lines with plot '-']

[Allin C. <cot...@wf...>]

On Tue, 12 Jun 2012, Allin Cottrell wrote:

> On Tue, 12 Jun 2012, Ethan A Merritt wrote:
>
>> Revisiting a discussion from last month...
>> 
>> I had a go at implemented data blocks defined as a "here document".
>> The patch is on SourceForge
>> <https://sourceforge.net/tracker/?func=detail&aid=3534646&group_id=2055&atid=302055>
>
> This looks great to me. And it's impressive that your patch is only 18K, nice 
> and compact. I haven't tested it yet, but will do so soon.

I've now given this mechanism a "live" test, and it worked just 
fine. One of the reasons I like this idea I forgot to mention in the 
previous discussion: my program gretl offers a GUI for configuring 
gnuplot graphs, and for this to work the plot command file must be 
fairly readily parseable. This data-block setup makes it easier and 
more efficient to parse the data to be plotted out of such a file, 
as compared with chasing down a bunch of e-terminated "stdin" 
blocks.

Allin Cottrell

Re: In-line data [was multiple plot lines with plot '-']

[Allin C. <cot...@wf...>]

On Tue, 12 Jun 2012, Ethan A Merritt wrote:

> Revisiting a discussion from last month...
>
> I had a go at implemented data blocks defined as a "here document".
> The patch is on SourceForge
> <https://sourceforge.net/tracker/?func=detail&aid=3534646&group_id=2055&atid=302055>

This looks great to me. And it's impressive that your patch is 
only 18K, nice and compact. I haven't tested it yet, but will 
do so soon.

Allin Cottrell

In-line data [was multiple plot lines with plot '-']

[Ethan A M. <sf...@us...>]

Revisiting a discussion from last month...

I had a go at implemented data blocks defined as a "here document".
The patch is on SourceForge 
<https://sourceforge.net/tracker/?func=detail&aid=3534646&group_id=2055&atid=302055>

In brief it adds perl-like syntax

$Mydata << EOD
1 2 3
4 5 ?
7 8 9
# comments or anything else legal in a data file
10 11 12
EOD

stats $Mydata using 3
plot $Mydata using 1:3, $Mydata using 0:2, '' using 1:2



Notes:

- The data block name must begin with a '$'.  This allows the
  named data blocks to be tracked internally using the same code
  as other user-defined variables, but prevents a data block name
  from being used in an expression, function, or other places
  that a normal variable would be accepted.

- The end-of-data marker (EOD in the example) can be any
  arbitrary string of alphanumerics beginning with a letter.
  I'm don't know what advantage this gives over requiring a
  fixed character sequence like EOD, but this seems to be how
  here documents are defined in other programming languages.

- The in-line data is read with no interpretation or processing.
  It is simply stored for later use in a "plot" "splot" or "stats"
  command.

- Any plot command that works with a normal text input file should
  work also with an in-line data block.

- The "show variables" command will report
            $Mydata = <5 line datablock>

- Do you think there needs to be a special command to clear all
  existing datablocks?  Right now the only way to clear one is
  to redefine it as a zero-length block:
  $Mydata << EOD
  EOD

Known problems:

- It doesn't work to include a here document definition inside a
  curly-brace delimited clause.  Not that it should ever be necessary
  to do so, but the program should at least not crash if you try it.

- I didn't look into using a data block as input to "fit".
  Do you think this would be useful?

	- Ethan

Re: gp470 win32 portable

[Tatsuro M. <tma...@ya...>]

Hello

Since my condition is not always good these days, I do not have a plan to release zip archived package as before.

Sorry for inconvenience.

Regards

Tatsuro 

--- On Tue, 2012/6/5, hon fui lee  wrote:

> I know this is early... but I play with the development version on
> non-Administrator machine.
> Can we have portable (un-zip and run) win32 binary? Thanks.
> 
> 
> ---------- Forwarded message ----------
> From: hon fui lee
> Date: Tue, Jun 5, 2012 at 2:50 PM
> Subject: gp470
> To: tma...@ya...
> 
> 
> Hi Dr. Tatsuro MATSUOKA,
> 
> I regularly download gnuplot from your website
> (http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/)
> In the old version, I can just un-zip and run the gnuplot. But
> recently, the files provided are installer which requires Admnistrator
> rights.
> 
> Is it possible to provide the portable (un-zip and run) type of
> gnuplot file? Thanks.
> 
> 
> Regards,
> hon_fui
> 
> 
> -- 
> hon_fui
> 

Re: comment handling

[<pl...@pi...>]

On 05/25/12 02:46, Ethan A Merritt wrote:
> On Thursday, May 24, 2012 11:59:59 am pl...@pi... wrote:
>> On 05/24/12 17:43, sfeam (Ethan Merritt) wrote:
>>> On Thursday, 24 May 2012, pl...@pi... wrote:
>>>> On 05/23/12 23:24, Ethan A Merritt wrote:
>>>
>>>>> gnuplot>    help set datafile comment
>>>>>     The `set datafile commentschars` tells `gnuplot` what characters are used in a
>>>>>     data file to begin comment lines. If the first non-blank character on a line is
>>>>>     one of the specified characters then the rest of the input line is ignored.
>>>>>     Default value of the string is "#!" on VMS and "#" otherwise.
>>>>>
>>>
>>>> OK, my bad, but this does point out something that could be done better.
>>>>
>>>> gnuplot>    help set datafile comment
>>>>
>>>> but the following
>>>>         1 # 3 4
>>>>     produces rather unexpected plot unless
>>>>         set datafile missing '#'
>>>>     is specified as well.
>>>
>>> Er, what were you expecting?
>>
>> That is what gnuplot help said , not me. The help says it can produce
>> "unexpected" results , so I suppose you'd better ask that question of
>> the person who wrote the doc.
>
> I'm not sure what it's trying to say.
> Just that # doesn't act as a comment in that case.
> OK, I'll look at re-wording it.
>
>> I''ve already stated that I expected it skip the rest of the line as a
>> comment. That would be useful. It appears that currently there is no
>> facility have comments other than all plotted columns being already
>> satisfied.
>>
>> It would be useful when data is missing to be able to add a comment
>> saying why in the data file.
>>
>> eg.
>>
>> 21.05.12:23:20  96 72  65
>> 22.05.12:09:00  98                    # instrument failure on channels 2
>> and 3
>> 23.05.12:04:30 120 87  49
>>
>>>
>>>> Unexpected indeed. Is there a good reason why this needs to happen?
>
> What is "this"?   For most plot commands, if the expected numerical
> data columns are not present then the line will be skipped.
> You can construct pathological cases where that doesn't happen, but
> it's true in general. This doesn't depend on the presence or absence
> of any specific comment character, however.
>

The "this" was parsing the hash that would normally introduce a comment 
as data . This was what I originally described when opening this thread. 
Sorry if that was not clear.

>
>>>> Is there a context in which a valid data entry could begin with '#' ?
>>>
>>> Sure - why not?
>>> Data files can contain anything at all, not necessarily numeric.
>>>
>>
>> Yeah well, assuming that it is something that is going to be plotted it
>> has to be numerical somewhere along the way. You can't plot "hash" .
>
> Sure you can.  Here's a plot command that maps characters in a
> data field onto a numerical value and then plots the distribution.
>
> gnuplot>  category = "ABC#@*!"
> gnuplot>  COL = 4
> gnuplot>  plot 'charfile' using (strstrt(category,strcol(COL))) : (1)  \
>           smooth freq with impulses
>
> This command has the peculiarity that it fails for COL = 1
> unless you unmap # as a comment character. But it works for all other columns.

Thanks, that is the information I was seeking originally when I asked 
whether hash could be part of valid data input. Now I know why it is not 
parsed as a comment.

So, as you point out this does not work in column one where it is taken 
and the comment char. So currently this feature is buggy.

Now, my real life example of one or more missing data preventing me 
adding a comment is hardly "pathological".  Data files are rarely 
perfect and the need to add comments is real and useful. However, the 
category syntax you propose here to show the (only?) case where this 
would be valid input data does seems at least rather unusual and improbable.

Since this example case is inconsistent in that it does not work for 
column one but does for the rest , would it not be better simply to 
exclude hash from the possible values for 'category' and make the 
feature self-consistent (without the col 1 peculiarity) thus freeing up 
the hash mark to exclusively introduce comments , ie end the parsing of 
the input line, be it in command script or data input.

That would seem to be both useful and more consistent.

regards, Peter





>
>> Unless # can be part of a numeric input , or valid data is some other
>> way , I see no utility in not parsing it as indicating a comment and
>> ending parsing the line for data.
>>
>> Am I missing something useful?
>
> Data files can contain character data
> Character data can contain #
>
>

Re: comment handling

[Jonathan T. <jt...@as...>]

On Thu, 24 May 2012, pl...@pi... wrote:
> I''ve already stated that I expected it skip the rest of the line as a 
> comment. That would be useful. It appears that currently there is no 
> facility have comments other than all plotted columns being already 
> satisfied.
> 
> It would be useful when data is missing to be able to add a comment 
> saying why in the data file.
> 
> eg.
> 
> 21.05.12:23:20  96 72  65
> 22.05.12:09:00  98                    # instrument failure on channels 2 
> and 3
> 23.05.12:04:30 120 87  49

You can do this with current gnuplot, but the comment needs to start
in column 1, e.g.,

  21.05.12:23:20  96 72  65
  # next line has only 1 column due to instrument failure on channels 2 and 3
  22.05.12:09:00  98
  23.05.12:04:30 120 87  49

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam

Re: comment handling

[Ethan A M. <sf...@us...>]

On Thursday, May 24, 2012 11:59:59 am pl...@pi... wrote:
> On 05/24/12 17:43, sfeam (Ethan Merritt) wrote:
> > On Thursday, 24 May 2012, pl...@pi... wrote:
> >> On 05/23/12 23:24, Ethan A Merritt wrote:
> >
> >>> gnuplot>   help set datafile comment
> >>>    The `set datafile commentschars` tells `gnuplot` what characters are used in a
> >>>    data file to begin comment lines. If the first non-blank character on a line is
> >>>    one of the specified characters then the rest of the input line is ignored.
> >>>    Default value of the string is "#!" on VMS and "#" otherwise.
> >>>
> >
> >> OK, my bad, but this does point out something that could be done better.
> >>
> >> gnuplot>   help set datafile comment
> >>
> >> but the following
> >>        1 # 3 4
> >>    produces rather unexpected plot unless
> >>        set datafile missing '#'
> >>    is specified as well.
> >
> > Er, what were you expecting?
> 
> That is what gnuplot help said , not me. The help says it can produce 
> "unexpected" results , so I suppose you'd better ask that question of 
> the person who wrote the doc.

I'm not sure what it's trying to say.
Just that # doesn't act as a comment in that case.
OK, I'll look at re-wording it.

> I''ve already stated that I expected it skip the rest of the line as a 
> comment. That would be useful. It appears that currently there is no 
> facility have comments other than all plotted columns being already 
> satisfied.
> 
> It would be useful when data is missing to be able to add a comment 
> saying why in the data file.
> 
> eg.
> 
> 21.05.12:23:20  96 72  65
> 22.05.12:09:00  98                    # instrument failure on channels 2 
> and 3
> 23.05.12:04:30 120 87  49
> 
> >
> >> Unexpected indeed. Is there a good reason why this needs to happen?

What is "this"?   For most plot commands, if the expected numerical
data columns are not present then the line will be skipped.
You can construct pathological cases where that doesn't happen, but 
it's true in general. This doesn't depend on the presence or absence
of any specific comment character, however.


> >> Is there a context in which a valid data entry could begin with '#' ?
> >
> > Sure - why not?
> > Data files can contain anything at all, not necessarily numeric.
> >
> 
> Yeah well, assuming that it is something that is going to be plotted it 
> has to be numerical somewhere along the way. You can't plot "hash" .

Sure you can.  Here's a plot command that maps characters in a
data field onto a numerical value and then plots the distribution.

gnuplot> category = "ABC#@*!"
gnuplot> COL = 4
gnuplot> plot 'charfile' using (strstrt(category,strcol(COL))) : (1)  \
         smooth freq with impulses

This command has the peculiarity that it fails for COL = 1
unless you unmap # as a comment character. But it works for all other columns.

> Unless # can be part of a numeric input , or valid data is some other 
> way , I see no utility in not parsing it as indicating a comment and 
> ending parsing the line for data.
> 
> Am I missing something useful?

Data files can contain character data 
Character data can contain #

Re: comment handling

[<pl...@pi...>]

On 05/24/12 17:43, sfeam (Ethan Merritt) wrote:
> On Thursday, 24 May 2012, pl...@pi... wrote:
>> On 05/23/12 23:24, Ethan A Merritt wrote:
>
>>> gnuplot>   help set datafile comment
>>>    The `set datafile commentschars` tells `gnuplot` what characters are used in a
>>>    data file to begin comment lines. If the first non-blank character on a line is
>>>    one of the specified characters then the rest of the input line is ignored.
>>>    Default value of the string is "#!" on VMS and "#" otherwise.
>>>
>
>> OK, my bad, but this does point out something that could be done better.
>>
>> gnuplot>   help set datafile comment
>>
>> but the following
>>        1 # 3 4
>>    produces rather unexpected plot unless
>>        set datafile missing '#'
>>    is specified as well.
>
> Er, what were you expecting?

That is what gnuplot help said , not me. The help says it can produce 
"unexpected" results , so I suppose you'd better ask that question of 
the person who wrote the doc.

I''ve already stated that I expected it skip the rest of the line as a 
comment. That would be useful. It appears that currently there is no 
facility have comments other than all plotted columns being already 
satisfied.

It would be useful when data is missing to be able to add a comment 
saying why in the data file.

eg.

21.05.12:23:20  96 72  65
22.05.12:09:00  98                    # instrument failure on channels 2 
and 3
23.05.12:04:30 120 87  49

>
>> Unexpected indeed. Is there a good reason why this needs to happen?  I
>> suppose this falls into the category of "except in numbers" in 'help
>> comment'.
>>
>> I often need to add a comment at the end of some data lines. This is OK
>> if all expected columns are filled since gnuplot does not try to parse
>> the rest.
>>
>> Is there a context in which a valid data entry could begin with '#' ?
>
> Sure - why not?
> Data files can contain anything at all, not necessarily numeric.
>

Yeah well, assuming that it is something that is going to be plotted it 
has to be numerical somewhere along the way. You can't plot "hash" .

Unless # can be part of a numeric input , or valid data is some other 
way , I see no utility in not parsing it as indicating a comment and 
ending parsing the line for data.

Am I missing something useful?

Peter.

Re: comment handling

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday, 24 May 2012, pl...@pi... wrote:
> On 05/23/12 23:24, Ethan A Merritt wrote:

> > gnuplot>  help set datafile comment
> >   The `set datafile commentschars` tells `gnuplot` what characters are used in a
> >   data file to begin comment lines. If the first non-blank character on a line is
> >   one of the specified characters then the rest of the input line is ignored.
> >   Default value of the string is "#!" on VMS and "#" otherwise.
> >

> OK, my bad, but this does point out something that could be done better.
> 
> gnuplot>  help set datafile comment
> 
> but the following
>       1 # 3 4
>   produces rather unexpected plot unless
>       set datafile missing '#'
>   is specified as well.

Er, what were you expecting?

> Unexpected indeed. Is there a good reason why this needs to happen?  I 
> suppose this falls into the category of "except in numbers" in 'help 
> comment'.
> 
> I often need to add a comment at the end of some data lines. This is OK 
> if all expected columns are filled since gnuplot does not try to parse 
> the rest.
> 
> Is there a context in which a valid data entry could begin with '#' ?

Sure - why not?  
Data files can contain anything at all, not necessarily numeric.

Re: comment handling

[<pl...@pi...>]

On 05/23/12 23:24, Ethan A Merritt wrote:
> On Wednesday, May 23, 2012 01:50:43 pm pl...@pi... wrote:
>> Hi,
>>
>> I am getting some inconsistent behaviour from comment handling.
>>
>> gnuplot>  set timefmt "%d.%m.%y:%H:%M"; set xdata time; set ylab "mm Hg"
>> ; set grid
>>
>> 21.05.12:23:20  96 72  65           # wetday , not walking
>> 22.05.12:09:00                      # rise 9am 81kg
>> 23.05.12:04:30 120 87  49           # work late,bed
>>
>>
>> help says:
>>
>>    Comments are supported as follows: a `#` may appear in most places in
>> a line
>>    and `gnuplot` will ignore the rest of the line.  It will not have this
>> effect
>>    inside quotes, inside numbers (including complex numbers), inside command
>>    substitutions, etc.  In short, it works anywhere it makes sense to work.
>
> That section is refering to gnuplot command lines, not to data files.
> The very next line says "See also `set datafile commentschars`
> for specifying comment characters in data files".
>
> gnuplot>  help set datafile comment
>   The `set datafile commentschars` tells `gnuplot` what characters are used in a
>   data file to begin comment lines. If the first non-blank character on a line is
>   one of the specified characters then the rest of the input line is ignored.
>   Default value of the string is "#!" on VMS and "#" otherwise.
>
>
>
>>
>> However the middle line with the missing data tries to plot the comment !
>>
>> I'm using a plot that is essentially:
>>
>> plot datafile using 1:2, '' using 1:3 , '' using 1:4
>>
>> the first line joins 96 and120 with a straight line.
>> the second gets a break (this is what I expected for all three)
>> the last line tries to plot "9am" and so I get a line 65 9 49
>>
>> All this seems to indicate that it is parsing "#" and "rise" as NaN
>> rather than seeing the comment as a comment.
>>
>> Is this expected? If so the help needs to be changed.
>>
>> regards, Peter.
>>

OK, my bad, but this does point out something that could be done better.

gnuplot>  help set datafile comment

but the following
      1 # 3 4
  produces rather unexpected plot unless
      set datafile missing '#'
  is specified as well.

Unexpected indeed. Is there a good reason why this needs to happen?  I 
suppose this falls into the category of "except in numbers" in 'help 
comment'.

I often need to add a comment at the end of some data lines. This is OK 
if all expected columns are filled since gnuplot does not try to parse 
the rest.

Is there a context in which a valid data entry could begin with '#' ?

Peter.