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

Re: Mouse coord lag (Re: An observation in animate demo.)

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

> In a surprising way, the faster response may have slowed down the
> mousing... but I don't think it is too critical.  What I'm seeing is
> that if one uses the mouse to select an area to zoom, a whole bunch of
> "position text redraws" get queued.  Then it can take a second or two
> for them all to finish drawing before the actual zooming action takes
> place.  To see this, try right-clicking the mouse to bring up the zoom
> box, then shake the mouse around a bit and quickly left-click the mouse.
>  It will take a few seconds for the positions to finish drawing.

I could't reproduce this.

--
PM

Mouse coord lag (Re: An observation in animate demo.)

[Daniel J S. <dan...@ie...>]

Ethan,

I'm observing something with mousing now that may have been affected by 
changing the time delay in this discussion from about a month back:

Ethan A Merritt wrote:

>On Sunday 09 May 2004 11:12 pm, Daniel J Sebald wrote:
>  
>
>>Ethan A Merritt wrote:
>>
>>    
>>
>>>I tentatively propose to modify the time delay to be
>>>#ifdef HAVE_USLEEP
>>>	usleep(100);
>>>#else
>>>	sleep(1);
>>>#endif
>>>

In a surprising way, the faster response may have slowed down the 
mousing... but I don't think it is too critical.  What I'm seeing is 
that if one uses the mouse to select an area to zoom, a whole bunch of 
"position text redraws" get queued.  Then it can take a second or two 
for them all to finish drawing before the actual zooming action takes 
place.  To see this, try right-clicking the mouse to bring up the zoom 
box, then shake the mouse around a bit and quickly left-click the mouse. 
 It will take a few seconds for the positions to finish drawing.

It isn't too bothersome, but it is noticeably different from the 
seemingly instantaneous response of a couple months ago.

I haven't pinpointed where the lag is coming from to confirm it is 
associated with the above change, so it could be a different change as well.

Oh, something peculiar though.  By doing the above jostling of the 
mouse, the dashed box seems to be fast responding.  Why would it be that 
the dashed box gets to its final position so quickly while the text 
keeps drawing away?

Dan

Re: y-axis reversed again

[Daniel J S. <dan...@ie...>]

Petr,


Petr Mikulik wrote:

>There seems to be again the bug of "y-axis gets reversed" in "set pm3d map"
>splots. Now, every 2nd splot zoomed by mouse has reversed y-axis. Can you
>please have a look to this?
>

Just to narrow this down, please try duplicating what you are seeing 
with "-nofeedback" at the command line.

Dan

Re: BSD libedit

[Lars H. <lhe...@us...>]

 
> 2) write an abstraction layer which allows to switch between native
>    readline / GNU libreadline / BSD libedit
 
 This is the prefered option.

y-axis reversed again

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

There seems to be again the bug of "y-axis gets reversed" in "set pm3d map"
splots. Now, every 2nd splot zoomed by mouse has reversed y-axis. Can you
please have a look to this?

---
PM

Re: [gnuplot-beta]set missing malfunctions

[Hans-Bernhard B. <br...@ph...>]

On Sat, 12 Jun 2004, Ethan A Merritt wrote:

> I think the documentation is wrong, and always was wrong, because
> the behavior it describes has nothing to do with whether the data field 
> contains the "missing" flag or not.  It simply describes what happens if the 
> field is *illegal*, which to my mind is a different thing from being 
> "missing".

Intent is hard to be certain about, this far into the project's 
lifetime...  

> By contrast to version 3.7, the test for missing data in 4.0 actually
> does something useful.

I'm not convinced that this is true.  Note that there are a total of 
about 12 distinct cases to consider:  the data entry in question can be a 
number, unparseable garbage, something contained in quotes, or the marker
defined by 'set misssing', and the plot can have no using specification at 
all, a simple one ("using 1:2" style) or an extended one ("using 
($1):($2)") for the column in question.

In version 3.7, it seems the main the effect of 'set missing' was to
change the behaviour in the case of non-numeric input in the face of
simple using specs.  Without it, they would would be treated as undefined
data (--> break in 'with lines' plots), but if they matched a defined 'set
missing' string, they would treat them like in the case of no using
specification: they'ld ignore it (--> no break, because there's no trace
left of that entire data point).

We may have over-done the matter in the 3.8 series, rendering 'set
missing' useless, or at least giving it an entirely different meaning than
it used to have.  E.g., the whole idea that quoted entries in datafile get
special treatment is new.

> As the documentation says, the first plot will incorrectly draw
> a line through (2,3) because the 2nd field is an illegal numerical
> value.   With "*" set as a missing data flag, however, the second
> plot is drawn correctly.  

To be precise, it's drawn in one of two possible ways that could be
called "correct" here: it has a break in it, because the datapoint
was kept in the internal lists, but flagged as DF_UNDEFINED.

> This didn't used to happen.

For the case of no using spec at all, it didn't.  I suspect 'set missing'
simply never had any effect on such plots, in 3.7.  So arguing over their
behaviour may be pointless.

The compatibility we should worry about is what happens in those case
where 3.7 did behave at least marginally sensibly, i.e. the 'using 1:2'
and 'using ($1):($2)' ones.

> > > I am open to the suggestion that 'plot with lines' in particular
> > > should be modified so that missing data does not produce
> > > breaks in the line.
> >
> > As long as missing data output DF_UNDEFINED from datafile.c, it must.
> > Otherwise we'ld be changing the behaviour of piecewise functions
> > in a seriously broken manner, e.g.
> >
> > 	plot [-10:10] abs(x)>5?abs(x):0/0 w l
> >
> > would suddenly have a connection between points (-5,-5) and (5,5), which
> > we quite definitely don't want.
> 
> I don't quite follow you here.  There was no such connection before the
> change (in 3.7) and no such connection after the change (in 4.0).

Exactly.  But as of your October 2002 change, flagged "missing" input ends
up as datapoint with DF_UNDEFINED in the internal point lists, just like
the points on the gap of the above function do.  So a change to let 'plot
with lines' continue across DF_UNDEFINED points would change the function
plot's behaviour, and we don't want that.

> I have just modified the code in cvs so that df_readline() passes the
> DF_MISSING up to the callers.   

I have serious doubts about that being the right idea, but don't have the
time right now to investigate it fully, sorry.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [gnuplot-beta]set missing malfunctions

[Ethan A M. <merritt@u.washington.edu>]

On Thursday 10 June 2004 01:50 pm, Hans-Bernhard Broeker wrote:

I think the documentation is wrong, and always was wrong, because
the behavior it describes has nothing to do with whether the data field 
contains the "missing" flag or not.  It simply describes what happens if the 
field is *illegal*, which to my mind is a different thing from being 
"missing".

By contrast to version 3.7, the test for missing data in 4.0 actually
does something useful.

Consider the following example (modified from the docs)

       set style data lines
       plot '-'
          1 10
          2 20
          3 *
          4 40
          5 50
          e
       set datafile missing "*"
       plot '-'
          1 10
          2 20
          3 *
          4 40
          5 50
          e

As the documentation says, the first plot will incorrectly draw
a line through (2,3) because the 2nd field is an illegal numerical
value.   With "*" set as a missing data flag, however, the second
plot is drawn correctly.  This didn't used to happen.

> > I am open to the suggestion that 'plot with lines' in particular
> > should be modified so that missing data does not produce
> > breaks in the line.
>
> As long as missing data output DF_UNDEFINED from datafile.c, it must.
> Otherwise we'ld be changing the behaviour of piecewise functions
> in a seriously broken manner, e.g.
>
> 	plot [-10:10] abs(x)>5?abs(x):0/0 w l
>
> would suddenly have a connection between points (-5,-5) and (5,5), which
> we quite definitely don't want.

I don't quite follow you here.  There was no such connection before the
change (in 3.7) and no such connection after the change (in 4.0).
If I put in an explicit test for DF_MISSING it won't add a connection then
either.

I have just modified the code in cvs so that df_readline() passes the
DF_MISSING up to the callers.   There only three callers (in plot2d.c
plot3d.c and fit.c), and all three continue to treat this case as they
have been by falling through to the DF_UNDEFINED handler.  But 
if people want 'plot with lines' to draw lines through missing data
then I can add a simple test so that the code section in plot2d.c
looks like this:

        case DF_MISSING:
	    if (current_plot->plot_style == LINES)
		continue;
            /* Otherwise missing data is treated the same as undefined */
        case DF_UNDEFINED:
            /* bad result from extended using expression */
            current_plot->points[i].type = UNDEFINED;
            i++;
            continue;

That is OK with me, or at least I don't object very strongly.
I suppose logically we would test also for LINESPOINTS.

I was just trying to point out that this returns us to the case (for
"plot with lines") that there is no difference between setting or not
setting the missing data flag.  Why have a flag if it doesn't make any
difference which way it is set?  If the user doesn't want to make a
distinction between missing and undefined points, then he doesn't
have to use the "set datafile missing <char>" option at all.
If he wants to indicate missing data then he can set the flag, 
and the resulting plot will show a break in the line where there is
missing data. That seems better to me, but either way it is up to
the user to choose which he wants.

I hope I have explained my thoughts better this time.  

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

BSD libedit

[Thimo N. <th...@de...>]

Hi,

a bit later than I originally planned but here are my results of
checking if NetBSDs libedit can be used as license-compatible
libreadline replacement:

First of all, the capabilities have much improved, now it feels just
like GNU readline and is heavily configurable. It's also used by
Heimdal and asterisk. However, the native interface is quite
different. To use libedit in gnuplot there are two possibilities:

1) use the readline compatibility layer of libedit

2) write an abstraction layer which allows to switch between native
   readline / GNU libreadline / BSD libedit

As the GNU readline-calls are widely spread through the source and I
haven't got enough overview I've tried 1). This worked quite well,
with just a couple of lines changed the compilation works until the
linking where several special libreadline-functions are missing. That
may be a special problem as the libedit2 in Debian unstable is quite
old. I've asked the maintainer to build a newer version (the current
CVS-version seems to contain more readline compatibility) and will
tell you new results when it's ready.

If you, however, think that 2) may be a good idea I would offer my
help. Otherwise, stay tuned for new results in a couple of weeks :)

Cheers
   Thimo

Re: metapost terminal

[Andrzej <wa...@ga...>]

Ethan A Merritt <merritt <at> u.washington.edu> writes:
> Thanks to Andrzej Wąsowski and Dan Luecking, [...]
> 
> With their guidance I have patched the terminal to support text rotation
> and filled boxes.  I do not know how to add pattern-fill, but for the moment
> I have dummied it up with different solid fill densities.

I got some time to make the pattern stuff, but I got a bit lost against what
ptach should I code. Should I grab your "integrated" patch you posted some days
ago? or perhaps you have made some other changes in potentially conflictful
places in the metapost driver and want to repost? Or should I just cvs up and
code against that?

Andrzej

Re: metapost terminal

[Ethan A. M. <merritt@u.washington.edu>]

On Thursday 10 June 2004 00:58, Andrzej W=C4=85sowski wrote:
> I guess that I should add pattern-filled polygons to this function:
>
> TERM_PUBLIC void MP_filled_polygon __PROTO((int, gpiPoint *));

Correct.

> But what is the interface for filled curves?

The patch (#908456) adds a "style" parameter to the above function.
The core routines all know about the current style already, via
"set style fill <options>",  so it's just a matter of teaching individual
drivers to pay attention to this style when filling a polygon.=20

> Oh, and I will have to learn using pm3d to test this :).

pm3d doesn't use pattern fill, so this is a separate question.
To test the code you would use something like
	set style fill pattern 1
	set style function filledcurve
	plot func1, func2, ....

Re: [gnuplot-beta]metapost terminal

[Hans-Bernhard B. <br...@ph...>]

On Wed, 9 Jun 2004, Daniel H. Luecking wrote:

> On Tue, 8 Jun 2004, Hans-Bernhard Broeker wrote:
> 
> > On Tue, 8 Jun 2004, Daniel H. Luecking wrote:
> >
> > > Well, I did seek guidence when I chose the colors.  The best I could get
> > > was the advice that they should be distinguishable, and black is easy to
> > > distinguish from almost anything.
> >
> > But we're already using black for the borders, tick marks,  and all kinds
> > of text in the graph.  You usually want to be distinguishable from those,
> > too.
> 
> You don't need color to distinguish a plotted curve from those things.

I disagree.  Curves can come asymptotically close to the borders, or do
other strange things that make it hard to find them if the whole diagram
is black, as a plot of only one dataset in metapost would currently be,
from what has been said here.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [gnuplot-beta]set missing malfunctions

[Hans-Bernhard B. <br...@ph...>]

On Wed, 9 Jun 2004, Ethan Merritt wrote:

> Here is the entirety of the change at issue:
>         /*
>          * EAM - Oct 2002 Distinguish between DF_MISSING and DF_BAD.
>          * Previous versions would never notify caller of either case.
>          * Now missing data will be noted. Bad data should arguably be
>          * noted also, but that would change existing default behavior.
>          */
>          else if ((column <= df_no_cols) && (df_column[column - 1].good == DF_MISSING))
>               return DF_UNDEFINED;
> 
> The comment was correct. Without this change the code was IMHO broken,
> and worked as it did only by accident.

It did match the documentation, though, which I don't think was an
accident.  

> With the change, the missing data is explicitly reported as such by
> the code in datafile.c.   

Not quite.  df_tokenize() reports DF_MISSING, but df_readline now
translates that into DF_UNDEFINED instead of 'no data'.  The effect is
that of an empty line, not a missing line, in the case of 'with lines'.

> As I recall, the reason I noticed the original problem was that with the
> version 3.7 code it was not possible to guarantee reasonable behavior
> from missing data for box plots or candlesticks. I don't know that I can 
> reproduce an example of the failure quickly, but I can try if needed.

Please do.

> The other problem was that you could not tell gnuplot that '0' or 'NaN'
> or some other numerically-parsable flag indicated missing data.

NaN, if scanf() supports it at all will quite certainly do that in 4.0,
because there's now an additional sanity check between datafile reading
and datapoints being used.

And if you want to use '0' for that, I don't agree 'set missing' is
the way to do that.  That's what we have using 1:($3==0?0/0:$3)
or similar constructs for.

> This was a problem for tabular data that used 0 as a place-holder.

Such tabular data is IMHO broken by design. 

> > So: which do we change: the code or the docs?
> 
> I think the docs should be changed.  


> should be modified so that missing data does not produce
> breaks in the line.  

As long as missing data output DF_UNDEFINED from datafile.c, it must.
Otherwise we'ld be changing the behaviour of piecewise functions 
in a seriously broken manner, e.g.

	plot [-10:10] abs(x)>5?abs(x):0/0 w l

would suddenly have a connection between points (-5,-5) and (5,5), which
we quite definitely don't want.


-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: metapost terminal

[Hans-Bernhard B. <br...@ph...>]

On Wed, 9 Jun 2004, Andrzej [utf-8] W=C4=85sowski wrote:

> Hans-Bernhard Broeker <broeker <at> physik.rwth-aachen.de> writes:
> =20
> > Not necessarily.  The general method for platforms that don't sup=
port
> > patterns in some native way is to draw them as lots of individual=
 lines.
> > That's possible because we do pattern-filling only for boxes.
>=20
> Do you mean that there is some software level option that can be se=
t in
> the terminal driver to make the calling code use primitive line dra=
wing
> commands of the terminal to draw the patterns?

No --- although arguably there should be.  What I was getting at is t=
hat
each terminal driver is on its own how to do it, but those that aren'=
t as
sophisticated as to allow masking a large pattern to the inside of a =
given
curve,  usually achieve pattern filling by just drawing the hatch lin=
es
directly.  Check out how existing drivers do it, and you'll see.

> The main issue for me now is to know what are the patterns to be dr=
awn.

Your choice.  You may want to imitate some existing driver's behaviou=
r
for consistency, but you don't have to.

> > Not necessary.  As long as the grid line style is noticably light=
er than
> > the borders, you're OK.  Some terminals dot it, some draw it in g=
ray, some
> > others combine those two.
>=20
> The distinction between grid line style and other lines is fairly g=
ood
> with on screen postscript previewers, but it is much less clear on =
the
> printout IMHO.=20

That'll depend heavily on the kind of printer you use, I guess.  'set=
 term
postscript colour solid' output will print badly on a b/w laser anywa=
y,
regardless of what you do with the grid lines.  On a colour printer, =
the
current method should work very nicely.


--=20
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: metapost terminal

[Andrzej <wa...@ga...>]

Ethan Merritt <merritt <at> u.washington.edu> writes:
> I found a pattern-fill extension to metapost on the web, but it requires
> a whole new wrapper layer on top of metapost which is probably more
> trouble than it is worth for this purpose.
> 	http://www.tug.org/tex-archive/graphics/metapost/macros/mpattern/
> Also there is this document, which I am sure you can evaluate
> better than I can 
> 	http://www.gust.org.pl/PDF/BIUL/09/06-pb.pdf

I have seen these sites last weekend, in my initial investigation on what is
available around. But know I have seen what kind of patterns we are talking
about (like those at the output of test in x11 terminal aren't we?). I think
drawing such simple pattern is sufficiently easy with basic commands, to avoid
dependency on this extra packages.

> > What is the chance that gnuplot will support pattern filling for other
> > shapes than boxes in future?
> 
> There's already a patch on SourceForge (#908456) that extends
> it to general polygons and filled curves.  But has only been implemented
> for the cgm gd pdf post svg and x11 terminal types.

Then I think I will do my "pattern" patch so that it is easily used for filling
other shapes. In MetaPost one basically needs to fill in a bounding box instead
of the box, and then clip. 

I guess that I should add pattern-filled polygons to this function:

TERM_PUBLIC void MP_filled_polygon __PROTO((int, gpiPoint *));

But what is the interface for filled curves? 

Oh, and I will have to learn using pm3d to test this :).

Andrzej

Re: [gnuplot-beta]Re: metapost terminal

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

> The rationale is that if you compose a figure interactively
> and then change terminal types to save a permanent copy
> you want the colors to stay more or less as you saw them on
> the screen.  But not all terminal types agree on colors anyhow,
> and I will leave them alone if metapost users prefer it that way.

Colors in most/some terminals were reorganized in previous year(s) to match
postscript as much as possible. You are welcome to match it for those still
unchanged terminals as well.

---
PM

Re: [gnuplot-beta]set missing malfunctions

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

> I am open to the suggestion that 'plot with lines' in particular
> should be modified so that missing data does not produce
> breaks in the line.  I don't have any strong opinion about that,
> other than to note that if we do that it will be harder to cause
> a break in the line if you *do* want one.

I agree; the only break between scans should be forced by an empty line.

---
PM

Re: [gnuplot-beta]Re: metapost terminal

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 09 June 2004 02:30 pm, Arun Persaud wrote:
> Hi,
>
> Andrzej Wa;sowski wrote:
> > [...]I think it is better to have consistent colors, although I find
> > metapost driver colors much, much, much, oh so much, more appealing
> > than postscript colors (at least the first 8). [...] I hope that
> > current metapost colors are among these.
>
> Me too, is there a way to keep the metapost colors somewhere in the
> colormap?

I wasn't proposing to change the nature of the colors, just
re-arrange them into the order (names approximate)
	red green blue magenta cyan brown yellow 
to match other terminals like x11, png, and so on.
I'd probably add an 8th color since black is removed from 
the list.

The rationale is that if you compose a figure interactively
and then change terminal types to save a permanent copy
you want the colors to stay more or less as you saw them on
the screen.  But not all terminal types agree on colors anyhow,
and I will leave them alone if metapost users prefer it that way.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: [gnuplot-beta]Re: metapost terminal

[Arun P. <ape...@lb...>]

Hi,

Andrzej Wa;sowski wrote:
> [...]I think it is better to have consistent colors, although I find metapost driver
> colors much, much, much, oh so much, more appealing than postscript colors (at
> least the first 8). [...] I hope that current metapost colors are among these.

Me too, is there a way to keep the metapost colors somewhere in the 
colormap?

As for the filled pattern it shouldn't be too hard to have the metapost 
driver add some code to the output that generates a pattern and clips it 
to the path (either box or polygon) if needed.

just my two cents

	ARUN

Re: [gnuplot-beta]metapost terminal

[Daniel H. L. <lue...@ua...>]

On Tue, 8 Jun 2004, Hans-Bernhard Broeker wrote:

> On Tue, 8 Jun 2004, Daniel H. Luecking wrote:
>
> > Well, I did seek guidence when I chose the colors.  The best I could get
> > was the advice that they should be distinguishable, and black is easy to
> > distinguish from almost anything.
>
> But we're already using black for the borders, tick marks,  and all kinds
> of text in the graph.  You usually want to be distinguishable from those,
> too.

You don't need color to distinguish a plotted curve from those things.


-- 
Dan Luecking                           Dept. of Mathematical Sciences
lue...@ua...                      University of Arkansas
http://comp.uark.edu/~luecking/        Fayetteville, AR 72101

Re: metapost terminal

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 09 June 2004 10:15 am, Andrzej W=C4=85sowski wrote:
>
> Do you mean that there is some software level option that can be set in
> the terminal driver to make the calling code use primitive line drawing
> commands of the terminal to draw the patterns?

No. That's too hard.
I found a pattern-fill extension to metapost on the web, but it requires
a whole new wrapper layer on top of metapost which is probably more
trouble than it is worth for this purpose.
	http://www.tug.org/tex-archive/graphics/metapost/macros/mpattern/
Also there is this document, which I am sure you can evaluate
better than I can :-)
	http://www.gust.org.pl/PDF/BIUL/09/06-pb.pdf


> What is the chance that gnuplot will support pattern filling for other
> shapes than boxes in future?

There's already a patch on SourceForge (#908456) that extends
it to general polygons and filled curves.  But has only been implemented
for the cgm gd pdf post svg and x11 terminal types.

> Personally I prefer solid grid to the dotted one, but I
> would make it slightly thinner.

That sounds fine.


=2D-=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: [gnuplot-beta]set missing malfunctions

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 09 June 2004 04:41 am, Hans-Bernhard Broeker wrote:
> As you can see, the difference is that in 3.7 the '?' point is actually
> treated as missing, i.e. as if it simply wasn't there, whereas 4.0
> treats it as an undefined datapoint. The culprit modification appears to
> be the datafile.c:1161 ff., stamped by Ethan in October 2002.  It seems
> the rationale given in Ethan's comment is at odds with the documentation
> and with traditional behaviour.

Here is the entirety of the change at issue:
        /*
         * EAM - Oct 2002 Distinguish between DF_MISSING and DF_BAD.
         * Previous versions would never notify caller of either case.
         * Now missing data will be noted. Bad data should arguably be
         * noted also, but that would change existing default behavior.
         */
         else if ((column <= df_no_cols) && (df_column[column - 1].good == DF_MISSING))
              return DF_UNDEFINED;

The comment was correct. Without this change the code was IMHO broken,
and worked as it did only by accident.
datafile.c: df_tokenise() would internally set either DF_BAD or DF_MISSING,
but the only test made in determining the returned value was for whether
the point had been marked DF_GOOD or not.  That is, there was no
distinction in practice between missing data and unparsable data.
This behavior is identical to what you still get in version 4.0 if you specify
the "wrong" missing data character.

With the change, the missing data is explicitly reported as such by
the code in datafile.c.   It is debatable exactly what different plot modes
should do in the presence of missing data,  and if we are to revisit this
question I suggest that the code that would need to be changed is not
the section above, but rather the plot-style-specific code in plot2d.c
As I recall, the reason I noticed the original problem was that with the
version 3.7 code it was not possible to guarantee reasonable behavior
from missing data for box plots or candlesticks.  I don't know that I can 
reproduce an example of the failure quickly, but I can try if needed.

The other problem was that you could not tell gnuplot that '0' or 'NaN'
or some other numerically-parsable flag indicated missing data.
This was a problem for tabular data that used 0 as a place-holder.

> So: which do we change: the code or the docs?

I think the docs should be changed.  The current description 
correctly describes the behavior in the absence of an active
missing data character. What it really is describing is the behavior
in the presence of an unrecognized value in a numeric data field.
The whole point of having a "missing" flag is to get some different
behavior from this, right?

I suggest changing the section in the docs to be 
	
 Example:
       set datafile missing "NONE"
       set style data lines
       plot '-'
      [...  existing three cases with commentary]

       set datafile missing "?"
       plot '-'
      [... add comment that the explicit missing character flag
           will now cause all three of the above plot commands 
           to behave identically]


I am open to the suggestion that 'plot with lines' in particular
should be modified so that missing data does not produce
breaks in the line.  I don't have any strong opinion about that,
other than to note that if we do that it will be harder to cause 
a break in the line if you *do* want one.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: metapost terminal

[Andrzej <wa...@ga...>]

Hans-Bernhard Broeker <broeker <at> physik.rwth-aachen.de> writes:
 
> Not necessarily.  The general method for platforms that don't support
> patterns in some native way is to draw them as lots of individual lines.
> That's possible because we do pattern-filling only for boxes.

Do you mean that there is some software level option that can be set in the
terminal driver to make the calling code use primitive line drawing commands of
the terminal to draw the patterns?

If this less automatic, i.e. the driver has to do it itself, then indeed it
should be fairly easy to write metapost macros filling boxes with patterns. In
fact in metapost it is not that much harder to do it for any shapes. The main
issue for me now is to know what are the patterns to be drawn. 

What is the chance that gnuplot will support pattern filling for other shapes
than boxes in future?

> > I have noticed also another difference. The grid lines are solid in
> > metapost output and dashed (dotted?) in postscript output. Shall I look
> > into making those the same?
> 
> Not necessary.  As long as the grid line style is noticably lighter than
> the borders, you're OK.  Some terminals dot it, some draw it in gray, some
> others combine those two.

The distinction between grid line style and other lines is fairly good with on
screen postscript previewers, but it is much less clear on the printout IMHO.
Personally I prefer solid grid to the dotted one, but I would make it slightly
thinner.


Andrzej

The list tag (was Re: [gnuplot-beta]metapost terminal)

[Hans-Bernhard B. <br...@ph...>]

On Wed, 9 Jun 2004, Lars Hecking wrote:

>  Who switched on the "[gnuplot-beta]" tag in the subject: line (and did
>  it wrong)?

I did.  All the other mailing lists at SF.net use one, so I thought this
one should have one, too.  It helps to keep things organized in a messy
inbox, IMHO.

Ah well, I'll disable it again.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [gnuplot-beta]metapost terminal

[Lars H. <lhe...@us...>]

 Who switched on the "[gnuplot-beta]" tag in the subject: line (and did
 it wrong)?

 Please remove it.

[gnuplot-beta]set missing malfunctions

[Hans-Bernhard B. <br...@ph...>]

Hello, guys,

someone just filed a bug that 'set datafile missing' is misbehaving, both
compared to both 'set missing' in 3.7 and to the documentation, if used
with simple using specs (the 'using 1:2' example in 'help missing').

Digging into this a little reveals that this must have been broken for
quite some time (at least 2 years).  The difference becomes obvious if
you run that example with the table terminal:

# using 3.7:
> env GNUTERM=table /usr/bin/gnuplot tmiss.gpl
#Curve 0, 4 points
#x y type
1 10 i
2 20 i
4 40 i
5 50 i

#compared to 4.0:
> env GNUTERM=table gnuplot tmiss.gpl
#Curve 0, 5 points
#x y type
 1  10  i
 2  20  i
 0  0  u
 4  40  i
 5  50  i


As you can see, the difference is that in 3.7 the '?' point is actually
treated as missing, i.e. as if it simply wasn't there, whereas 4.0 treats
it as an undefined datapoint. The culprit modification appears to be the
datafile.c:1161 ff., stamped by Ethan in October 2002.  It seems the 
rationale given in Ethan's comment is at odds with the documentation and 
with traditional behaviour.  So: which do we change: the code or the docs?

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.