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

Re: Missing/invalid data points

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

NB:   This discussion is with regard to possible changes
      or extensions _after_ 4.2

On Tuesday 29 August 2006 10:25 am, Hans-Bernhard Br=F6ker wrote:
> Ethan Merritt wrote:
> > The second case keeps the point, marking it as undefined.
> > That is better, but it would be better yet if the information
> > stored was
> >    0.3 NaN 3.33 u
> > If nothing else, that would allow the tabular output line
> > to match the original input line.  Beyond that, the extra
> > info may be of use in auto-scaling the axes,
>
> Hardly --- autoscaling should never react to points that aren't
> actually on the plot.

I am not so sure.  Consider the "using 1:2:3 with pm3d" plots that
are being discussed.  Because of the oddities in missing/NaN
handling, the limits of the grid are not determined correctly.=20
The coordinate information may be necessary for gridding, even
if some of the points were unmeasured ('missing') or mis-measured
(NaN or Inf).

> But that's not the actual point.  The core issue is that there's
> only *one* "undefined" flag per data point.  To use the non-NaN
> data values safely, datafile.c would have to record which of them are
> usable, i.e. which caused the DF_UNDEFINED, and which didn't.  And it
> would have to continue reading / filling after a NaN or missing
> column.
>
> That's a rewrite from scratch of datafile.c and a good portion of all
> the code using it you've just outlined.

Nevertheless, that is what I am proposing.
I already said up-thread that this requires changes throughout
datafile.c

However, it is not quite as bad as you make it sound.
The change can be incremental.=20

1) The current code in datafile.c is prepared to fill in all the
relevant columns for return to the caller.
The issue is whether it bails out before doing so, or after doing so.
We can first change it to fill in all columns possible before
returning.  The caller will still see the DF_UNDEFINED return code,
and will continue to behave as before.

2) Individual callers, for example the gridding code, can then be
taught to use the additional information that is passed back to them.

By the way, the histogram code also suffers from a similar problem.
The current code contains work-arounds to try to handle the problem,
but a cleaner protocol for returning information from get_data()=20
would allow cleanup in the higher-level histogram code, and=20
additional flexibility in specifying the x-coordinate for histogram
plot mode (the subject of past feature requests and a contributed
patch).=20

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Missing/invalid data points

[<br...@ph...>]

Ethan Merritt wrote:

> The second case keeps the point, marking it as undefined.
> That is better, but it would be better yet if the information
> stored was
>    0.3 NaN 3.33 u
> If nothing else, that would allow the tabular output line
> to match the original input line.  Beyond that, the extra
> info may be of use in auto-scaling the axes, 

Hardly --- autoscaling should never react to points that aren't
actually on the plot.

But that's not the actual point.  The core issue is that there's
only *one* "undefined" flag per data point.  To use the non-NaN
data values safely, datafile.c would have to record which of them are 
usable, i.e. which caused the DF_UNDEFINED, and which didn't.  And it 
would have to continue reading / filling after a NaN or missing column.

That's a rewrite from scratch of datafile.c and a good portion of all 
the code using it you've just outlined.

Re: fill pattern

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

On 8/29/06, Dhiman Barman wrote:
> Hi Dan,
>       Thanks for all help. I solved the problem other day by using
> .png format as Ethan suggested.
> You can have a look at http://www.caida.org/~dhiman/c3.png
>
>      But then I had to use some unknown font as I could not use fonts
> that enhanced postscript was using. Now if I use rgbcolor, I
> can use enhanced postscript. But it would be great if gnuplot has
> the same set of patterns as xfig has....

If you would like to use arbitrary (system) fonts, have configurable
colors and keep vector format, take a look at
    http://pub.mojca.org/gnuplot/sample/histogram/data.pdf

I tried some pseudo-random data on a similar plot than yours, I used
"Antykwa Torunska" font for it and took colors from PNG terminal, but
all that can be changed arbitrary.

Mojca

(you probably need some additional instructions about how to do that,
so tell me if you're interested)

To Ethan: thanks for noting the dashed pattern, I had no idea what it
was either ;)

Re: Missing/invalid data points

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

> However, I think we very definitely should fix the currently broken
> behavior of
> 	splot 'foo' using 1:2:3
> in the presence of nonsense or NaN strings

It seems that Inf is handled, so why not NaN?

0.1 10 1.111
0.2 20 2.222
0.3 Inf 3.333
0.4 40 4.444


set table
plot 'a'

#Curve 0 of 1, 4 points
#x y type
  0.1  10  i
  0.2  20  i
  0.3  0.3  u
  0.4  40  i

---
PM

Re: fill pattern

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

>>       Thanks for all help. I solved the problem other day by using
>> .png format as Ethan suggested.
>> You can have a look at http://www.caida.org/~dhiman/c3.png
>
> Oooo!  (We should have an annual "graphies"... awards for the "best plot 
> produced by gnuplot for a journal", "best plot for a report", "best plot 
> for a web page".)

There are sections "Gnuplot in daily use" and "Gnuplot in publications" at 
http://www.gnuplot.info/screenshots/index.html#demos

---
PM

Re: fill pattern

[Dhiman B. <dh...@ca...>]

sorry, eps terminal (not postscript) does not have many colors as png has. 
all these are so confusing...it was evident from the fact that I was not 
able to rotate xlabels by -45. you suggested to use png and not eps enhanced. 


On Mon, Aug 28, 2006 at 04:41:23PM -0700, Ethan Merritt wrote:
> On Monday 28 August 2006 04:07 pm, Dhiman Barman wrote:
> > I solved the problem other day by using .png format 
> > You can have a look at http://www.caida.org/~dhiman/c3.png
> >
> >      But then I had to use some unknown font as I could not use fonts
> > that enhanced postscript was using.
> 
> I do not understand this.  Any font that postscript could use,
> the png terminal could also use.  Unless you mean that you chose
> a PostScript font that was present in the hardware of your printer
> but not installed on your computer?
> 
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle WA

Re: fill pattern

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

On Monday 28 August 2006 04:07 pm, Dhiman Barman wrote:
> I solved the problem other day by using .png format 
> You can have a look at http://www.caida.org/~dhiman/c3.png
>
>      But then I had to use some unknown font as I could not use fonts
> that enhanced postscript was using.

I do not understand this.  Any font that postscript could use,
the png terminal could also use.  Unless you mean that you chose
a PostScript font that was present in the hardware of your printer
but not installed on your computer?


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: fill pattern

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

Dhiman Barman wrote:
> Hi Dan,
>       Thanks for all help. I solved the problem other day by using 
> .png format as Ethan suggested.
> You can have a look at http://www.caida.org/~dhiman/c3.png

Oooo!  (We should have an annual "graphies"... awards for the "best plot produced by gnuplot for a journal", "best plot for a report", "best plot for a web page".)


>      But then I had to use some unknown font as I could not use fonts
> that enhanced postscript was using. Now if I use rgbcolor, I 
> can use enhanced postscript. But it would be great if gnuplot has 
> the same set of patterns as xfig has.... 
> 	
>      I am not sure why 4th column from right was shorter, either 
> something was getting trimmed off from the top or I was missing something 
> in program or datafile. But now it seems ok.

Your new plot doesn't have that; the top entry in the fourth column was "blank" in previous examples and brown here.

Dan

Re: fill pattern

[Dhiman B. <dh...@ca...>]

Hi Dan,
      Thanks for all help. I solved the problem other day by using 
.png format as Ethan suggested.
You can have a look at http://www.caida.org/~dhiman/c3.png

     But then I had to use some unknown font as I could not use fonts
that enhanced postscript was using. Now if I use rgbcolor, I 
can use enhanced postscript. But it would be great if gnuplot has 
the same set of patterns as xfig has.... 
	
     I am not sure why 4th column from right was shorter, either 
something was getting trimmed off from the top or I was missing something 
in program or datafile. But now it seems ok.

Thanks,
Dhiman

On Mon, Aug 28, 2006 at 04:45:46PM -0500, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> >On Monday 28 August 2006 01:25 pm, Daniel J Sebald wrote:
> >
> >>Well, colors seems to be a good alternative.  Is there some way to
> >>use defined rgb colors with the fill to expand the allowable number?
> >
> >
> >That works now, so far as I know.
> >Did you have a particular example where is doesn't?
> 
> No.  I wasn't sure.  Perhaps that is the solution for Dhiman, who said the 
> first attempt was with colors but that also repeated.  (The example Dhiman 
> gave had three instances of red.)
> 
> 
> >The thing is, pattern-fill is mostly used in cases where you
> >_can't_ use colors,  e.g. black+white figures for publication.
> 
> That's true, but I don't think that was a limitation for Dhiman, otherwise 
> color wouldn't have been attempted in the first place.  It seems to me that 
> pattern is useful, but just for a small number of classes.
> 
> Maybe an histogram example with "rgbcolor" would be a nice addition to 
> 'histograms2.dem'.  Rather than the basic colors, choose some far out 
> colors that would catch the viewer's attention, i.e., "How did they get 
> those colors?" kind of thing.  In the attached patch I attempted the 
> gaudiest colors I could.
> 
> Does this help Dhiman?
> 
> Dan
> 
> PS:  Any ideas as to why that fourth from right column in Dhiman's example 
> is shorter than the others?  Dhiman, you might be able to make the best 
> guess.
> 
> PPS:  I notice some slight overlap and blending of colors in the 
> histogram2.dem examples.  (I didn't look beyond X11.)

Re: Missing/invalid data points

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

On Monday 28 August 2006 02:52 pm, Ethan Merritt wrote:
>
> However, I think we very definitely should fix the currently broken
> behavior of
> 	splot 'foo' using 1:2:3
> in the presence of nonsense or NaN strings

Here is the essence of the problem:

# Data file junk.dat
0.1 10 1.111
0.2 20 2.222
0.3 NaN 3.333
0.4 40 4.444



gnuplot> splot 'junk.dat' using 1:2:3 with pm3d

#IsoCurve 0, 3 points
#x y z type
 0.1  10  1.111 i
 0.2  20  2.222 i
 0.4  40  4.444 i

gnuplot> splot 'junk.dat' using ($1):($2):($3) with pm3d

#IsoCurve 0, 4 points
#x y z type
 0.1  10  1.111 i
 0.2  20  2.222 i
 0  0  0 u
 0.4  40  4.444 i


The first case (using 1:2:3) omits the line altogether,
which unfortunately messes up the gridding and produces
a distorted surface.

The second case keeps the point, marking it as undefined.
That is better, but it would be better yet if the information
stored was
   0.3 NaN 3.33 u
If nothing else, that would allow the tabular output line
to match the original input line.  Beyond that, the extra
info may be of use in auto-scaling the axes, auto-gridding 
(not in this case, but if it were the Z value that was bad),
interpolation of color values, and probably things I haven't
thought of.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Missing/invalid data points

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

Ethan Merritt wrote:

> However, I think we very definitely should fix the currently broken
> behavior of
> 	splot 'foo' using 1:2:3
> in the presence of nonsense or NaN strings
> Unfortunately, I have not found a simple fix for this yet.
> I can make it work, but only be substantially re-writing the 
> input code in datafile.c.

I propose it should be a post 4.2 major redo.  Again, I suspect that not a lot of thought was put into the original behavior for this and any documentation came about as an after thought.  We'd want to keep as much compatibility as possible but I'm guessing that if people had a really nice flexible alternative they'd be happy enough.

Recall, I also raised the issue of flexibility to define how the "datum" should act when finding a "missing" point.  Some times one would like to increment, some times not.

>   The presence of the binary read
> routines is an additional complication. 

I think the binary case can be addressed after the fact, once a nice set up is done in ASCII.  We can have analogous concepts, e.g., specifying that a certain number represents "missing", or "NaN", etc.  (This is something that people often do in practice, e.g., in a data stream they might define 0x8000 of a 16 bit number to represent something special, say saturation.)

Dan

Re: Missing/invalid data points

[<br...@ph...>]

Petr Mikulik wrote:
>> In the non-($n) case, the plot should be the same as if you remove these
>> junk lines from the datafile.
> 
> I think datafiles should not have "stupid" values, but, amazingly, gnuplot 
> does not ignore such lines; try this:
> 
> 0.1 10 1.111
> 0.2 20 2.222
> 0.3 bla 3.333
> 0.4 40 4.444
> 
> gnuplot>  set table; plot 'bla1'

You partly missed Dan's point.  By 'non-($n) case', I think he was 
referring to "plot 'bla1' u 1:2:3".  And yes, that's supposed to behave
differently from "plot 'bla1'".  The documentation even says so, right 
there in 'help using'.

> Further, the first example in 'help missing' + its description seems to be 
> wrong.

No, the example matches the 2D case of your example quite nicely.  It 
doesn't match the 3D case as well.  I suspect that's because splot never
used to have a 2-column default case back in the days when 'missing' and 
'using' still worked as documented (before pm3d, among other things), so 
there's nothing for using-less splot to fall back to, seeing a data 
record with 2 usable entries.

Re: Missing/invalid data points

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

On Monday 28 August 2006 12:43 pm, Petr Mikulik wrote:
> I think datafiles should not have "stupid" values, but, amazingly,
> gnuplot does not ignore such lines; try this:
>
> 0.1 10 1.111
> 0.2 20 2.222
> 0.3 bla 3.333
> 0.4 40 4.444
>
> gnuplot>  set table; plot 'bla1'
>
> #Curve 0 of 1, 4 points
> #x y type
>   0.1  10  i
>   0.2  20  i
>   2  0.3  i
>   0.4  40  i

That is exactly what is documented in the help file.
I agree it is stupid, but it has been that way since forever.
In the absence of a 'using' keyword, the program re-evaluates
the intended meaning of the columns all over again for each line
in the input file. The line
 0.2 20 2.222
is interpreted as having 3 valid columns, therefore the 1st 
column is used for x=0.2 and the second column for y=20.
The line
 0.3 bla 3.333
is interpreted as having only 1 valid column. Therefore the
1st column is interpreted as y=0.3 (*NOT X*) and the x=2 value
is taken as being implicitly determined by the input line #,
equivalent to 'column 0'.


> gnuplot>  set table; splot 'bla1'
>
> #Surface 0 of 1 surfaces
>
> #IsoCurve 0, 4 points
> #x y z type
>   0.1  10  1.111 i
>   0.2  20  2.222 i
>   2  0  0.3 i
>   0.4  40  4.444 i
>
> Even that this has no relation to "set datafile missing", the
> "replacement" values are strange -- 'help missing' even says
> "erroneously".

Again, this is exactly what is documented.
Only 1 valid number is read from the line
  0.3 bla 3.333
So that value is assumed to mean z=0.3, while the x=2 and y=0
values are generated implicitly from the line number
and the isocurve number, respectively.

> Further, the first example in 'help missing' + its description seems
> to be wrong.

It looks correct to me.  

I believe we have reached the point where we should just say
the a 'using' keyword is required.  For backwards compatibility,
in the absence of a 'using' specifier the code will behave as
the documents have always stated, and you show above. 

Therefore, odd as the behavior may be, I think we should not change
the documented behavior for no using spec.

However, I think we very definitely should fix the currently broken
behavior of
	splot 'foo' using 1:2:3
in the presence of nonsense or NaN strings
Unfortunately, I have not found a simple fix for this yet.
I can make it work, but only be substantially re-writing the 
input code in datafile.c.   The presence of the binary read
routines is an additional complication. 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: fill pattern

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

Ethan Merritt wrote:
> On Monday 28 August 2006 01:25 pm, Daniel J Sebald wrote:
> 
>>Well, colors seems to be a good alternative.  Is there some way to
>>use defined rgb colors with the fill to expand the allowable number?
> 
> 
> That works now, so far as I know.
> Did you have a particular example where is doesn't?

No.  I wasn't sure.  Perhaps that is the solution for Dhiman, who said the first attempt was with colors but that also repeated.  (The example Dhiman gave had three instances of red.)


> The thing is, pattern-fill is mostly used in cases where you
> _can't_ use colors,  e.g. black+white figures for publication.

That's true, but I don't think that was a limitation for Dhiman, otherwise color wouldn't have been attempted in the first place.  It seems to me that pattern is useful, but just for a small number of classes.

Maybe an histogram example with "rgbcolor" would be a nice addition to 'histograms2.dem'.  Rather than the basic colors, choose some far out colors that would catch the viewer's attention, i.e., "How did they get those colors?" kind of thing.  In the attached patch I attempted the gaudiest colors I could.

Does this help Dhiman?

Dan

PS:  Any ideas as to why that fourth from right column in Dhiman's example is shorter than the others?  Dhiman, you might be able to make the best guess.

PPS:  I notice some slight overlap and blending of colors in the histogram2.dem examples.  (I didn't look beyond X11.)

Re: fill pattern

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

On Monday 28 August 2006 01:25 pm, Daniel J Sebald wrote:
> Well, colors seems to be a good alternative.  Is there some way to
> use defined rgb colors with the fill to expand the allowable number?

That works now, so far as I know.
Did you have a particular example where is doesn't?

The thing is, pattern-fill is mostly used in cases where you
_can't_ use colors,  e.g. black+white figures for publication.



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: fill pattern

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

Ethan Merritt wrote:

> Beyond that it's a losing battle.
> Dots are particularly bad, however, unless you can scale them
> up or down to match the printer resolution.

True.

>  The default "dot"
> on a high-resolution printer is effectively invisible.

True.

> Diagonal lines are also problematic, because they lead to 
> odd visual effects.  Adjacent rectangles with opposite diagonal
> fill give the optical illusion of leaning toward or away from
> each other.

True.  Even nausiating some times.


> We don't have to invent this stuff from scratch, however.
> There are many collections of fill patterns on the web, and
> serious publications evaluating whether they are good or
> bad. For example:
>     portal.acm.org/ft_gateway.cfm?id=192438&type=pdf
>     ieeexplore.ieee.org/iel2/1131/8046/00347511.pdf?arnumber=347511
> 
> Note that one school of thought says that fill patterns of any
> sort are bad, and it is usually preferable to label the interior
> of the area with a text or symbolic description of its contents.

Well, colors seems to be a good alternative.  Is there some way to use defined rgb colors with the fill to expand the allowable number?

Dan

Re: fill pattern

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

On Monday 28 August 2006 12:48 pm, Daniel J Sebald wrote:
>
> I'd say "blank" should not be a pattern.  Could it instead by a
> pattern of dots or circles?  (Dots would give more variety and be
> distinguishable from lines, even for small boxes.)

No. The maximal difference in fill patterns is the difference
between solid background and solid foreground; that is,
"empty" and "solid".   These should clearly be among the first few 
patterns provided.  After that it is not so obvious, but the
criss-cross hash pattern is probably the safest, so two different
densities of that are my preference for numbers #3 and #4.

Beyond that it's a losing battle.
Dots are particularly bad, however, unless you can scale them
up or down to match the printer resolution.  The default "dot"
on a high-resolution printer is effectively invisible.
Diagonal lines are also problematic, because they lead to 
odd visual effects.  Adjacent rectangles with opposite diagonal
fill give the optical illusion of leaning toward or away from
each other.

We don't have to invent this stuff from scratch, however.
There are many collections of fill patterns on the web, and
serious publications evaluating whether they are good or
bad. For example:
    portal.acm.org/ft_gateway.cfm?id=192438&type=pdf
    ieeexplore.ieee.org/iel2/1131/8046/00347511.pdf?arnumber=347511

Note that one school of thought says that fill patterns of any
sort are bad, and it is usually preferable to label the interior
of the area with a text or symbolic description of its contents.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: fill pattern

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

On Monday 28 August 2006 12:57 pm, Dhiman Barman wrote:
> Hi All,
>        Another challenge I am facing, how to arrange the legends
> from bottom to top. 

Please use the "help" utility.

"help set key" will tell you that the option you are asking
about is
	set key invert




> So, if red is the first color used 
> in the leftmost bar (similarly for a pattern), I want it to be
> bottom most legend and not the top most as you might have seen
> in the figs, c.eps or c2.eps.
>
> Thanks,
> Dhiman
>
> On Mon, Aug 28, 2006 at 02:48:52PM -0500, Daniel J Sebald wrote:
> > Ethan Merritt wrote:
> > >On Friday 25 August 2006 04:04 pm, Dhiman Barman wrote:
> > >> Two items with legends w and m have the same fill pattern. The
> > >> plot is at http://www.caida.org/~dhiman/c.eps
> > >>
> > >> What could be the reason ? Is it a feature or bug ?
> > >
> > >There are only 8 patterns.  Successive plots cycle through them.
> >
> > First, 8 is rather low, but hey, how many patterns can there be,
> > right? So, a combination of patterns and colors should cover enough
> > I would think. (And there might even be an argument for not having
> > so many patterns because if the box is small, it is kind of
> > difficult to tell exactly what the pattern is.)
> >
> > However, if one looks at the example
> >
> > 	http://www.caida.org/~dhiman/c.eps
> >
> > you'll see that the w/m (second 'm' of 'm s i g') confusion is a
> > result of the pattern being blank, i.e., no pattern.  The problem
> > with that even though the color may be modulating with the pattern
> > "blank" has no color to modulate.
> >
> > I'd say "blank" should not be a pattern.  Could it instead by a
> > pattern of dots or circles?  (Dots would give more variety and be
> > distinguishable from lines, even for small boxes.)
> >
> > Dan
> >
> > PS:  Another question about this example:  Why does the fourth
> > column from the right not reach as high as the rest?
>
> ---------------------------------------------------------------------
>---- Using Tomcat but need to do more? Need to support web services,
> security? Get stuff done quickly with pre-integrated technology to
> make your job easier Download IBM WebSphere Application Server
> v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121
>642 _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: fill pattern

[Dhiman B. <dh...@ca...>]

Hi All,
       Another challenge I am facing, how to arrange the legends 
from bottom to top. So, if red is the first color used 
in the leftmost bar (similarly for a pattern), I want it to be 
bottom most legend and not the top most as you might have seen 
in the figs, c.eps or c2.eps. 

Thanks,
Dhiman	
       


On Mon, Aug 28, 2006 at 02:48:52PM -0500, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> >On Friday 25 August 2006 04:04 pm, Dhiman Barman wrote:
> >
> >> Two items with legends w and m have the same fill pattern. The plot
> >>is at http://www.caida.org/~dhiman/c.eps
> >>
> >> What could be the reason ? Is it a feature or bug ?
> >
> >
> >There are only 8 patterns.  Successive plots cycle through them.
> 
> First, 8 is rather low, but hey, how many patterns can there be, right?  
> So, a combination of patterns and colors should cover enough I would think. 
> (And there might even be an argument for not having so many patterns 
> because if the box is small, it is kind of difficult to tell exactly what 
> the pattern is.)
> 
> However, if one looks at the example
> 
> 	http://www.caida.org/~dhiman/c.eps
> 
> you'll see that the w/m (second 'm' of 'm s i g') confusion is a result of 
> the pattern being blank, i.e., no pattern.  The problem with that even 
> though the color may be modulating with the pattern "blank" has no color to 
> modulate.
> 
> I'd say "blank" should not be a pattern.  Could it instead by a pattern of 
> dots or circles?  (Dots would give more variety and be distinguishable from 
> lines, even for small boxes.)
> 
> Dan
> 
> PS:  Another question about this example:  Why does the fourth column from 
> the right not reach as high as the rest?

Re: Missing/invalid data points

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

I have noticed that if there is at least one blank line at the end of a 
datafile, then
         set table; plot 'bla1'
shows a dummy undefined point at the end:

#Curve 0 of 1, 5 points
#x y type
  1  10  i
  2  20  i
  2  30  i
  4  40  i
  0  0  u

That dummy "0 0 u" does not appear for
         splot 'bla1'
It probably does not hurt anything?

***

> In the non-($n) case, the plot should be the same as if you remove these
> junk lines from the datafile.

I think datafiles should not have "stupid" values, but, amazingly, gnuplot 
does not ignore such lines; try this:

0.1 10 1.111
0.2 20 2.222
0.3 bla 3.333
0.4 40 4.444

gnuplot>  set table; plot 'bla1'

#Curve 0 of 1, 4 points
#x y type
  0.1  10  i
  0.2  20  i
  2  0.3  i
  0.4  40  i

gnuplot>  set table; splot 'bla1'

#Surface 0 of 1 surfaces

#IsoCurve 0, 4 points
#x y z type
  0.1  10  1.111 i
  0.2  20  2.222 i
  2  0  0.3 i
  0.4  40  4.444 i

Even that this has no relation to "set datafile missing", the "replacement" 
values are strange -- 'help missing' even says "erroneously".

Further, the first example in 'help missing' + its description seems to be 
wrong.


---
PM

Re: fill pattern

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

Ethan A Merritt wrote:

>>http://pub.mojca.org/gnuplot/temp/data.plt
>>http://pub.mojca.org/gnuplot/temp/data.dat
> 
> 
> At first I could not reproduce your plot; I got only the
> expected hash-mark patterns.
> 
> Eventually I realized that the unusual visual effect in your
> original plot comes from drawing the patterns with dashed lines.  
> I don't know whether to consider that a bug or a feature :-)

It is some interesting patterns, unfortunately it is unique to PostScript terminal, isn't it?  Otherwise it would be a feature.

Dan

Re: fill pattern

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

Ethan Merritt wrote:
> On Friday 25 August 2006 04:04 pm, Dhiman Barman wrote:
> 
>>  Two items with legends w and m have the same fill pattern. The plot
>>is at http://www.caida.org/~dhiman/c.eps
>>
>>  What could be the reason ? Is it a feature or bug ?
> 
> 
> There are only 8 patterns.  Successive plots cycle through them.

First, 8 is rather low, but hey, how many patterns can there be, right?  So, a combination of patterns and colors should cover enough I would think.  (And there might even be an argument for not having so many patterns because if the box is small, it is kind of difficult to tell exactly what the pattern is.)

However, if one looks at the example

	http://www.caida.org/~dhiman/c.eps

you'll see that the w/m (second 'm' of 'm s i g') confusion is a result of the pattern being blank, i.e., no pattern.  The problem with that even though the color may be modulating with the pattern "blank" has no color to modulate.

I'd say "blank" should not be a pattern.  Could it instead by a pattern of dots or circles?  (Dots would give more variety and be distinguishable from lines, even for small boxes.)

Dan

PS:  Another question about this example:  Why does the fourth column from the right not reach as high as the rest?

Re: Missing/invalid data points in PM3D

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

Petr Mikulik wrote:
>>>With your patch of plot3d.c, all scans have the number of points as
>>>intended. The rectangle(s) contaning a point with NaN are not drawn. This

This is related, I think, to what we discussed not too long ago on missing and invalid points, i.e., the patch I created illustrating the various behaviors with a new "demo".  If I recall correctly, I fixed up a couple things (but this particular goto issue doesn't ring a bell) and then reached the point where it seemed we would have to make some decisions as to how missing/invalid should behave.  I advocated a default behavior with the ability to redefine behavior.

Dan

Re: raise and <space> on KDE

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

On Monday 28 August 2006 09:17 am, Petr Mikulik wrote:
> I've got a report that neither of "set term x11 raise", "raise" and
> the <space> hotkey is raising the respective window on KDE unless
> user switches KDE Control Panel =3D> Desktop =3D> Window Behaviour =3D>
> Advanced =3D> Focus stealing prevention level: None (default is Low).

=46rom your description, everything is working as expected.
If KDE is set to enforce a global policy, then it does so.

> I tried to define an "exception" for gnuplot in the Desktop =3D>
> Window-Specific Settings, but without success. Is somebody
> successful?

I suspect that this is related to Feature Request #1376595
"Class and name strings of X Window".  KDE's exception policy may
be failing to find any windows with the class name "gnuplot".


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

raise and <space> on KDE

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

I've got a report that neither of "set term x11 raise", "raise" and the 
<space> hotkey is raising the respective window on KDE unless user switches 
KDE Control Panel => Desktop => Window Behaviour => Advanced => Focus 
stealing prevention level: None (default is Low).

I tried to define an "exception" for gnuplot in the Desktop => 
Window-Specific Settings, but without success. Is somebody successful?

Are similar problems also with other x11 window managers?

(Note: this problem is mentioned in gnuplot.doc: 'help bind'; I think it 
should probably be also mentioned in 'help raise').

---
PM