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

Re: postscript dash patterns in parametric vs data plots

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

Jonathan Thornburg wrote:
> I have stumbled on what looks to me like a bug in postscript dash
> patterns when using parametric mode.  In particular, when using
> 'set term postscript eps', the 'with lines linetype 2' dash pattern
> seems to differ between
> (a) plotting a certain horizontal line (about 3 dashes long) using a
>     pair of of parametric functions to specify x and y, versus
> (b) plotting that same horizontal line using '-' inline data to explicitly
>     specify the endpoint coordinates of the line.

I'll venture a guess, then: the difference disappears if you use the 
same number of points for both lines, right?  I.e. if you 'set samples 
2' for (a), the two plots will be the same.  Or if you output the 
sampled function to a data file (--> help table), and plot that in place 
of the inline data, the two plots will again be the same.

Re: postscript dash patterns in parametric vs data plots

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

On Mon, Mar 29, 2010 at 21:31, Jonathan Thornburg wrote:
> Hi,
>
> Ok, I have done this, it's sourceforge bug id #2978743, description
> "postscript dash patterns differ between parametric & data pl"
> (it looks like they truncated my description string),
> https://sourceforge.net/tracker/?func=detail&aid=2978743&group_id=2055&atid=102055
> I have attached 3 files to the bug report:
> * my gnuplot script 'par-dash.gnuplot'
> * the eps output produced by gnuplot 4.2.6 on my computer, 'par-dash.eps'
> * an X windows screen dump (from 'xwd', converted to a jpeg image via
>  'xwdtopnm | pnmtojpeg -quality 95') showing 'gv' on my computer viewing
>  the eps file (with antialiasing turned OFF so as not to confuse things),
>  with the wierd dash pattern visible on the left and the normal dash
>  pattern visible on the right

On my viewer (Preview.app on Mac; conversion done by Mac OS X) it
looks OK. After conversion with ps2pdf and using the same viewer for
PDF it shows a weird patterns - most probably the same as yours.

Mojca

Re: postscript dash patterns in parametric vs data plots

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

Hi,

On Sunday 28 March 2010 10:13:12 I wrote:
| I have stumbled on what looks to me like a bug in postscript dash
| patterns when using parametric mode.  In particular, when using
| 'set term postscript eps', the 'with lines linetype 2' dash pattern
| seems to differ between
| (a) plotting a certain horizontal line (about 3 dashes long) using a
|     pair of of parametric functions to specify x and y, versus
| (b) plotting that same horizontal line using '-' inline data to explicitly
|     specify the endpoint coordinates of the line.

On Sun, 28 Mar 2010, Ethan Merritt wrote:
> Thank you for your detailed bug report.
> Unfortunately, I cannot reproduce it the problem.
> Using either 4.2.6 or current CVS, the two lines produced by your example
> script are indistinguishable to my eyes even at 10x magnification. Perhaps
> in the CVS output one of the component dashes is ever so slightly longer,
> but if so it is at the very edge of perceptible difference.
> 
> Could you please file this report on SourceForge, and attach an
> output PostScript file demonstrating the problem?

Ok, I have done this, it's sourceforge bug id #2978743, description
"postscript dash patterns differ between parametric & data pl"
(it looks like they truncated my description string),
https://sourceforge.net/tracker/?func=detail&aid=2978743&group_id=2055&atid=102055
I have attached 3 files to the bug report:
* my gnuplot script 'par-dash.gnuplot'
* the eps output produced by gnuplot 4.2.6 on my computer, 'par-dash.eps'
* an X windows screen dump (from 'xwd', converted to a jpeg image via
  'xwdtopnm | pnmtojpeg -quality 95') showing 'gv' on my computer viewing
  the eps file (with antialiasing turned OFF so as not to confuse things),
  with the wierd dash pattern visible on the left and the normal dash
  pattern visible on the right


> Notwithstanding my failure to reproduce this, I'm going to guess that
> the problem lies in the PostScript implementation.  From your description,
> I'm guessing that the dot-dash pattern associated with the line is re-started
> for each line segment, so if you draw a line made up of multiple segments
> (as is likely for a parametric curve) the pattern is discontinuous at each
> break point.

That does seem plausible.  And maybe there's an uninitialized variable
or suchlike hiding in the code to explain why the output is different
on my computer than on your computer.


> But I could be wrong.  Let's see whether your output file looks the same
> as the one I get here.

Yes, I'm interested in what your postscript viewer shows when pointed
at my eps file -- this should at least resolve the question of whether
the problem I see is in my gnuplot or in my postscript viewer ('gv').

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy, 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: Fwd: Re: unix epoch data wrapping

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

On 03/29/10 16:49, Ethan Merritt wrote:
> On Monday 29 March 2010, pl...@pi... wrote:
>
>> If gnuplot could work around the instability in the libraries it uses,
>> this would seem preferable to burdening users with playing around with
>> specific string handling. I'd regard that as a workaround rather than a
>> solution.
>
> You have missed, or misunderstood, an earlier posting.
> The gnuplot time code does not depend on an external library.
> I posted the code (from time.c) that it uses to interpret the %y format.
> The gnuplot code was written last century, and adheres to the closest
> thing to a "standard" that was available at the time.  It has not
> changed since then, which one can view as backwards consistency or
> continued foolishness as the case may be.
>
> I pointed out the shifting sands of time-handling in libc not to
> explain gnuplot's behaviour, but just as a additional bit of evidence
> that the whole area is frought with inconsistency.
>
> 	Ethan
>

OK , apologies, I apparently was not paying enough attention. I did see 
the post.

Tait has just come up with a very simple work around. Reading data as %Y 
interprets data like 68 AD but produces labels like 14/05/59 which looks 
fine in the context. I could also add 1900 to this value in the plot 
command. That does what I need.

At this point only data spanning a century boundary would present 
problems. It may be argued that if such data is not explicit , it should 
be.

I would still maintain that the current somewhat arbitrary behaviour is 
flawed and it would be better if my rollover variable solution provided 
a way to define this without having to resort to Tait's workaround , 
which presumably will never be documented.

I don't have time to dig into the source and submit a patch so I'll just 
have to settle for contribution a possible solution and having got some 
way to improving the %y documentation.

Thanks to those who have helped.

Peter.

Re: unix epoch data wrapping

[wino <wi...@pi...>]

On 03/29/10 11:10, Tait wrote:
>> I have just tried a quick plot of some historical C14 data and got the
>> the plot split in two.
>> ...
>> I'm reading it with :
>> set timefmt  "%d-%b-%y"
>> ...
>> This presumably has something to do with unix year zero. ...
>
> Perhaps the most sensible thing to do -- both for gnuplot and for
> Peter -- is to simply change the format to %Y. Gnuplot will, I assume,
> interpret this as the literal year 68 (as in the first century),
> and the user can add 1900 years (or 2000 years, or 1800, or whatever)
> in the using statement. For data sets spanning a century division, a
> (condition? true-cond : false-cond) will work in the using statement to
> make the division.
>
> Tait
>
>
Excellent idea , I'll give it a try. ;)

In the context maybe just letting gnuplot label the axis in two digits 
would be fine.

Thanks for the bright idea.

Peter.

Re: Fwd: Re: unix epoch data wrapping

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

On Monday 29 March 2010, pl...@pi... wrote:

> If gnuplot could work around the instability in the libraries it uses, 
> this would seem preferable to burdening users with playing around with 
> specific string handling. I'd regard that as a workaround rather than a 
> solution.

You have missed, or misunderstood, an earlier posting.
The gnuplot time code does not depend on an external library.
I posted the code (from time.c) that it uses to interpret the %y format.
The gnuplot code was written last century, and adheres to the closest
thing to a "standard" that was available at the time.  It has not
changed since then, which one can view as backwards consistency or
continued foolishness as the case may be.

I pointed out the shifting sands of time-handling in libc not to 
explain gnuplot's behaviour, but just as a additional bit of evidence
that the whole area is frought with inconsistency.

	Ethan

Re: unix epoch data wrapping

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

> I have just tried a quick plot of some historical C14 data and got the
> the plot split in two.
> ...
> I'm reading it with :
> set timefmt  "%d-%b-%y"
> ...
> This presumably has something to do with unix year zero. ...

Perhaps the most sensible thing to do -- both for gnuplot and for
Peter -- is to simply change the format to %Y. Gnuplot will, I assume,
interpret this as the literal year 68 (as in the first century),
and the user can add 1900 years (or 2000 years, or 1800, or whatever)
in the using statement. For data sets spanning a century division, a
(condition? true-cond : false-cond) will work in the using statement to
make the division.

Tait

Re: Fwd: Re: unix epoch data wrapping

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

On 03/29/10 00:22, sfeam (Ethan Merritt) wrote:
> On Sunday 28 March 2010, pl...@pi... wrote:
>
>
>> what I asked for was for the software to behave as indicated in the
>> doc : help for timefmt %y.
>> There is no mention of this idiocy in help timefmt.
>>
>> That is a gnuplot shortcoming that has just been rectified thanks to my
>> pointing it out and someone else providing a patch.
>>
>> "Thanks ?". Don't mention it , just carry on with the rant and insults.
>> It's what you do so well.
>>
>> Software should not expect humans to know the subtle , unstable
>> meanderings of an underlying library's internals and adapt their
>> behaviour to the illogical software.
>
> Please, both of you, let's keep the discussion civil.
> Sniping at each other will not help, although bemoaning the sorry
> state of software design in general is a time-honored tradition.
>
> To the extent that there is any standard, the code follows it.
> As is often the case, we may argue that the standard is crazy, but
> where is there a better option?

I'm not sure this can in anyway be regarded as a "standard". Primarily 
because it keeps changing. There also seem to a number of choices about 
doing this all of which seem pretty arbitrary choices.


>
> It's 50 years too late to avoid the original mistake of encoding dates
> electronically as 2-digit characters.  And it's probably 50 years too
> early to expect software to be intelligent enough to figure out on its
> own that a particular data file refers specifically to dates in the
> 20th century as opposed to the current or some other century.
>
> On the bright side, gnuplot's string handling should now be good
> enough to work around the problem once you are aware that your particular
> data files will trigger it.  If that isn't the case, then a bug report
> with an example of the difficulty would be appreciated.
>
I don't recall you commenting on my suggestion of providing a rollover 
date to gnuplot.

This would cover all bases. If someone wants to adopt MS excel 
convention they feed in 2039. If they want humanly logical results they 
give it 2000. If they were born in 1969 they can use 1969 ;)

Though I feel 2000 should be the logical default behaviour,  I'm pretty 
sure you'd want to ensure this is backwards compatible. Since current 
behaviour seems to depend on what version of certain libs is installed , 
it seems not supplying a value has to default to the current anarchic 
situation in the hope that this will prompt the user to refer to the doc 
when the plot comes out arse about face.

The doc should then have some comment about why it happens and document 
the variable usage.

To avoid having to code all the possible date/time options currently in 
there maybe gnuplot could call strptime internally with some test dates 
to sniff it's rollover behaviour then adjust the data read in. The sniff 
should be as trivial as the adjustment to code.

If gnuplot could work around the instability in the libraries it uses, 
this would seem preferable to burdening users with playing around with 
specific string handling. I'd regard that as a workaround rather than a 
solution.

regards. Peter.

Re: Fwd: Re: unix epoch data wrapping

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

On Sunday 28 March 2010, pl...@pi... wrote:


>what I asked for was for the software to behave as indicated in the
>doc : help for timefmt %y.
>There is no mention of this idiocy in help timefmt.
>
>That is a gnuplot shortcoming that has just been rectified thanks to my
>pointing it out and someone else providing a patch.
>
>"Thanks ?". Don't mention it , just carry on with the rant and insults.
>It's what you do so well.
>
> Software should not expect humans to know the subtle , unstable
> meanderings of an underlying library's internals and adapt their
> behaviour to the illogical software.

Please, both of you, let's keep the discussion civil.
Sniping at each other will not help, although bemoaning the sorry
state of software design in general is a time-honored tradition.

To the extent that there is any standard, the code follows it.
As is often the case, we may argue that the standard is crazy, but
where is there a better option? 

It's 50 years too late to avoid the original mistake of encoding dates
electronically as 2-digit characters.  And it's probably 50 years too 
early to expect software to be intelligent enough to figure out on its
own that a particular data file refers specifically to dates in the
20th century as opposed to the current or some other century.

On the bright side, gnuplot's string handling should now be good 
enough to work around the problem once you are aware that your particular
data files will trigger it.  If that isn't the case, then a bug report
with an example of the difficulty would be appreciated.

Re: postscript dash patterns in parametric vs data plots

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

On Sunday 28 March 2010 10:13:12 Jonathan Thornburg wrote:
> I have stumbled on what looks to me like a bug in postscript dash
> patterns when using parametric mode.  In particular, when using
> 'set term postscript eps', the 'with lines linetype 2' dash pattern
> seems to differ between
> (a) plotting a certain horizontal line (about 3 dashes long) using a
>     pair of of parametric functions to specify x and y, versus
> (b) plotting that same horizontal line using '-' inline data to explicitly
>     specify the endpoint coordinates of the line.

Thank you for your detailed bug report.
Unfortunately, I cannot reproduce it the problem.
Using either 4.2.6 or current CVS, the two lines produced by your example
script are indistinguishable to my eyes even at 10x magnification. Perhaps
in the CVS output one of the component dashes is ever so slightly longer,
but if so it is at the very edge of perceptible difference.

Could you please file this report on SourceForge, and attach an
output PostScript file demonstrating the problem?

Notwithstanding my failure to reproduce this, I'm going to guess that
the problem lies in the PostScript implementation.  From your description,
I'm guessing that the dot-dash pattern associated with the line is re-started
for each line segment, so if you draw a line made up of multiple segments
(as is likely for a parametric curve) the pattern is discontinuous at each
break point.

But I could be wrong.  Let's see whether your output file looks the same
as the one I get here.

	Ethan



> (b) produces the usual dash pattern, while (in my test case) (a) seems
> to be broken.
> 
> In particular, consider the gnuplot script given below.  (This is
> abstracted from a larger "real-world" script.)  Notice that this draws
> two dashed lines of the same length, both 'with lines linetype 2'.
> 
> Using gnuplot 4.2.6 compiled from source ('show version long' output
> also given below), this produces an eps file showing a pair of labelled
> dashed lines.  Viewing the eps file with gv (version 3.5.8p5, based on
> ghostscript 8.63p7), the left dashed line (the one specified by a pair
> of parametric functions) has a dash pattern which looks like this:
>         -------    ------- -------
> This does not match the dash pattern of other 'with lines linetype 2'
> plots in my real-world script. :(  In contrast, the right dashed line
> (the one specified by explicit endpoint coordinates) has a dash pattern
> which looks like this:
>         -------    -------    -------
> This *does* match the dash pattern of other 'with lines linetype 2' plots.
> 
> To me, this (the left dash line's wierd dash pattern) looks like a bug.
> I have checked that the wierd dash pattern is unchanged when I disable
> antialiasing in gv.
> 
> --- begin gnuplot script ---
> set term postscript eps enhanced monochrome 18 size 8cm,8cm
> set output 'par-dash.eps'
> 
> unset key
> 
> set lmargin 9.0
> set rmargin 2.5
> 
> unset xtics
> unset ytics
> unset x2tics
> unset y2tics
> 
> unset xlabel
> unset ylabel
> 
> set border 0
> 
> set xrange [20:40]
> set yrange [0.0:1.0]
> 
> set parametric
> set dummy ell
> set trange [0:1]
> 
> # map t=[0:1] --> [a:b]
> map(a,b,t) = a + (b-a)*t
> 
> f6_x    = 20.00
> f8_x    = 33.00
> dash_dx = 1.00
> dash_y  = 0.1625
> label_dx = 1.50
> label_dy = 0.00
> 
> set label "f_6(ell) parametric fn" at f6_x+label_dx, dash_y+label_dy
> set label "f_6(ell) data"          at f8_x+label_dx, dash_y+label_dy
> 
> plot f6_x+map(0,dash_dx,ell), dash_y					\
> 	notitle								\
> 	with lines linetype 2 linewidth 3.0 linecolor -1,		\
>      '-'								\
> 	notitle								\
> 	with lines linetype 2 linewidth 3.0 linecolor -1
> 
> # data for '-' plot above
> 33.00	0.1625
> 34.00	0.1625
> eof
> 
> set output
> --- end gnuplot script ---
> 
> --- begin 'show version long' output ---
> gnuplot> show version long
> 
>         G N U P L O T
>         Version 4.2 patchlevel 6 
>         last modified Sep 2009
>         System: OpenBSD 4.6
> 
>         Copyright (C) 1986 - 1993, 1998, 2004, 2007 - 2009
>         Thomas Williams, Colin Kelley and many others
> 
>         Type `help` to access the on-line reference manual.
>         The gnuplot FAQ is available from http://www.gnuplot.info/faq/
> 
>         Send bug reports and suggestions to <http://sourceforge.net/projects/gnuplot>
> 
> Compile options:
> -READLINE  +LIBREADLINE  -HISTORY  +BACKWARDS_COMPATIBILITY  +BINARY_DATA  
> +GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  
> -NOCWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +USE_MOUSE  +HIDDEN3D_QUADTREE  
> +DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE  
> 
> DRIVER_DIR     = "/usr/local/libexec/gnuplot/4.2"
> GNUPLOT_PS_DIR = "/usr/local/share/gnuplot/4.2/PostScript"
> HELPFILE       = "/usr/local/share/gnuplot/4.2/gnuplot.gih"
> 
> gnuplot>
> --- end 'show version long' output ---
> 
> ciao,
> 
> -- 
> -- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
>    Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
>    "C++ is to programming as sex is to reproduction. Better ways might
>     technically exist but they're not nearly as much fun." -- Nikolai Irgens
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



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

Fwd: Re: unix epoch data wrapping

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

-------- Original Message --------
Subject: Re: unix epoch data wrapping
Date: Sun, 28 Mar 2010 18:52:15 +0200
From: pl...@pi...
To: Hans-Bernhard Bröker <HBB...@t-...>

On 03/28/10 12:58, Hans-Bernhard Bröker wrote:
> pl...@pi... wrote:
>
>
>> OK, that is certainly the source of what is happening. That seems a
>> pretty arbitrary and dumb way to define behaviour that for no good
>> reason is based on the otherwise irrelevant unix year dot.
>
> What you're still not getting is that the arbitrariness in gnuplot is a
> _necessary_consequence_ of the equally arbitrary assumption needlessly
> built into your data format. One might have thought that all the fuss
> and borderline panic about the Y2K issue might have taught people once
> and for all that it's utterly foolish to save digits on the year number
> for the price of confusions like this. Well, hope survives in the face
> of contrary evidence...

There is no arbitrary assumption in the data. It all relates to 20th c.
, it would be "needless" to put 19 in every data line of every data file.

If the data does not span y2k it is not "utterly foolish" but normal.

>
>> This dependancy on "current century" is a beauty. Any program
>> dependant on this behaviour would have gone tits-up in y2k roll-over.
>
> No program being forced by _you_, the user, to deal with 2-digit year
> numbers has the slightest chance to _avoid_ falling over on some
> occasions, be they Y2K, Y2K38 or the Unix epoch.

If the data spanned y2k that would be a valid comment. I see no reason a
scientist would start to wonder if someone would want to use a plotting
tool that  would be using a libc that for some unfathomable reason
decides to parse input on based on a relative rather than absolute
condition like "current century" and use this to switch the
interpretation of data on an equally unfathomable date , apparently
1969. Somebody's birthday maybe ? WTF?

>
> In a nutshell, you got what you asked for.
>
No,  what I asked for was for the software to behave as indicated in the
doc : help for timefmt %y.
There is no mention of this idiocy in help timefmt.

That is a gnuplot shortcoming that has just been rectified thanks to my
pointing it out and someone else providing a patch.

"Thanks ?". Don't mention it , just carry on with the rant and insults.
It's what you do so well.

>> I find this behaviour so inherently stupid that maybe gnuplot should
>> be coding around it.
>
> Pardon the French, but the only truly stupid behaviour I can see here is
> your (or whoever's) choice of data format. 2-digit years are totally,
> inexcusably stupid.

All _you_ can see indeed, since you have not followed the thread. I said
this was not my data , I also said it was historical data.

It was collected by scientists with the incredible , inexcusable
stupidity to be working and  living in the 20th century. The data spans
1945- 1990.

In this context two digits seems a sensible rather than stupid choice.
In fact is was very common practice in life before y2k.

Software should not expect humans to know the subtle , unstable
meanderings of an underlying library's internals and adapt their
behaviour to the illogical software.

>
>> This must be a pretty typical situation to hit since the turn of the
>> century
>
> No. The typical reaction to the Y2K was for people to (finally) come to
> their senses and switch to 4-digit years. I.e. the typical situation
> _was_ that for data to be in 2-digit year format. Since the turn of the
> century, that's no longer the case.
>
>  > , is there no better solution than pre-parse all my data files
>> with awk?!
>
> The better solution is not to write data files in such a silly format in
> the first place.
>
>

The stupidity does not lie in gnuplot , it is in glibc apparently. It
would be useful if gnuplot worked around problem rather than propagating
it and passing the buck when issues crop up.

I suggested a method for providing a stable solution to this sort of
case by providing a variable to gnuplot to define the roll-over year
rather than propagating the inherent unstable situation in the
underlying libs.

For the sake of backwards compat, this should default to the current
behaviour although y2k would be the logical human default for the rollover.

At least if such a feature was available and documented , anyone hitting
such a problem and consulting the help topic would instantly find the
cause and the solution.

So if we can put the abuse to one side and consider the merits of a
solution which seems clean and painless to implement , that would
probably be more productive.


best regards, Peter.

Re: postscript dash patterns in parametric vs data plots

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

On Sun, 28 Mar 2010, Jonathan Thornburg wrote:
> I have stumbled on what looks to me like a bug in postscript dash
> patterns when using parametric mode.  [[...]]

In hindsight, that E-mail came out quite officious (not to mention
repeating itself a bit).  I apologise for this -- it was sloppy editing
on my part.  I've been using gnuplot since sometime in the 1980s
(I remember 2.* versions), I'm actually very happy with it.

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
   "C++ is to programming as sex is to reproduction. Better ways might
    technically exist but they're not nearly as much fun." -- Nikolai Irgens

postscript dash patterns in parametric vs data plots

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

I have stumbled on what looks to me like a bug in postscript dash
patterns when using parametric mode.  In particular, when using
'set term postscript eps', the 'with lines linetype 2' dash pattern
seems to differ between
(a) plotting a certain horizontal line (about 3 dashes long) using a
    pair of of parametric functions to specify x and y, versus
(b) plotting that same horizontal line using '-' inline data to explicitly
    specify the endpoint coordinates of the line.

(b) produces the usual dash pattern, while (in my test case) (a) seems
to be broken.

In particular, consider the gnuplot script given below.  (This is
abstracted from a larger "real-world" script.)  Notice that this draws
two dashed lines of the same length, both 'with lines linetype 2'.

Using gnuplot 4.2.6 compiled from source ('show version long' output
also given below), this produces an eps file showing a pair of labelled
dashed lines.  Viewing the eps file with gv (version 3.5.8p5, based on
ghostscript 8.63p7), the left dashed line (the one specified by a pair
of parametric functions) has a dash pattern which looks like this:
        -------    ------- -------
This does not match the dash pattern of other 'with lines linetype 2'
plots in my real-world script. :(  In contrast, the right dashed line
(the one specified by explicit endpoint coordinates) has a dash pattern
which looks like this:
        -------    -------    -------
This *does* match the dash pattern of other 'with lines linetype 2' plots.

To me, this (the left dash line's wierd dash pattern) looks like a bug.
I have checked that the wierd dash pattern is unchanged when I disable
antialiasing in gv.

--- begin gnuplot script ---
set term postscript eps enhanced monochrome 18 size 8cm,8cm
set output 'par-dash.eps'

unset key

set lmargin 9.0
set rmargin 2.5

unset xtics
unset ytics
unset x2tics
unset y2tics

unset xlabel
unset ylabel

set border 0

set xrange [20:40]
set yrange [0.0:1.0]

set parametric
set dummy ell
set trange [0:1]

# map t=[0:1] --> [a:b]
map(a,b,t) = a + (b-a)*t

f6_x    = 20.00
f8_x    = 33.00
dash_dx = 1.00
dash_y  = 0.1625
label_dx = 1.50
label_dy = 0.00

set label "f_6(ell) parametric fn" at f6_x+label_dx, dash_y+label_dy
set label "f_6(ell) data"          at f8_x+label_dx, dash_y+label_dy

plot f6_x+map(0,dash_dx,ell), dash_y					\
	notitle								\
	with lines linetype 2 linewidth 3.0 linecolor -1,		\
     '-'								\
	notitle								\
	with lines linetype 2 linewidth 3.0 linecolor -1

# data for '-' plot above
33.00	0.1625
34.00	0.1625
eof

set output
--- end gnuplot script ---

--- begin 'show version long' output ---
gnuplot> show version long

        G N U P L O T
        Version 4.2 patchlevel 6 
        last modified Sep 2009
        System: OpenBSD 4.6

        Copyright (C) 1986 - 1993, 1998, 2004, 2007 - 2009
        Thomas Williams, Colin Kelley and many others

        Type `help` to access the on-line reference manual.
        The gnuplot FAQ is available from http://www.gnuplot.info/faq/

        Send bug reports and suggestions to <http://sourceforge.net/projects/gnuplot>

Compile options:
-READLINE  +LIBREADLINE  -HISTORY  +BACKWARDS_COMPATIBILITY  +BINARY_DATA  
+GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  
-NOCWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +USE_MOUSE  +HIDDEN3D_QUADTREE  
+DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE  

DRIVER_DIR     = "/usr/local/libexec/gnuplot/4.2"
GNUPLOT_PS_DIR = "/usr/local/share/gnuplot/4.2/PostScript"
HELPFILE       = "/usr/local/share/gnuplot/4.2/gnuplot.gih"

gnuplot>
--- end 'show version long' output ---

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
   "C++ is to programming as sex is to reproduction. Better ways might
    technically exist but they're not nearly as much fun." -- Nikolai Irgens

Re: gnuplot Problem

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

mirza klimenta wrote:

> I tried to plot the graph from the sample data (.txt file attached), but
> I encounter problems with the output. Note that there are 12 rows(points),
> but the program shows 13. Any clues on how to avoid this problem?

You forgot to present the commands you used to plot this, but I'll 
venture a guess.  You plotted your datafile in the "with points" 
(default) style, and mistook the key sample for a data point.  To check 
this, re-try after

	set key below

and you'll find that the extra point has moved outside the graph area, 
along with the legend.

Re: unix epoch data wrapping

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

On 03/28/10 01:18, Ethan Merritt wrote:
> On Saturday 27 March 2010, Jonathan Thornburg wrote:
>> If I write the 2-digit year "50", does it mean 1950 or 2050?
>>          [Let's leave aside the possibility of other centuries.]
>> In the original poster's case, I gather that 1950 would have been the
>> correct interpretation.  But if I were plotting future values of a
>> retirement portfolio, 2050 would probably be the better choice.
>> Fundamentally, there is no way for gnuplot to know the "correct"
>> choice, so it has to make an arbitrary choice (which will be wrong
>> a fair number of times).
>
> Indeed.
> And if you are plotting a timeline of Roman emperors, "68" really
> does mean 68, the year of Nero's death.
>
> There is no end to this quagmire.  The behaviour of a program may even
> depend on which library version it is linked against. Consider this
> lovely bit from the man page for strptime:
>     The  'y' (year in century) specification is taken to specify a year in
>     the 20th century by libc4 and libc5. It is taken to be a year  in  the
>     range  1950-2049  by  glibc 2.0. It is taken to be a year in 1969-2068
>     since glibc 2.1.
>

Argh , what a mess. Can someone explain the meaning of backwards 
compatibile to gnu.org ?!

In view of the ugly truth would it be better to use , or make available 
, a different way to parse this data rather than relying on the moving 
sand algorithm ?

In order to get stable behaviour this type of data could be read in as a 
string and parsed by gnuplot rather than strptime.

I recall quite a while back you commented this area was a bit hairy , 
I'm starting to see what your were refering to.


> So yes, I'll add a note in the documentation.  But better by far not to
> use two-digit dates.

I agree, but I did not design the data format .  I suppose awk may be 
the short answer , though it would be good to have a more stable 
implementation that would give some insurance against the next arbitrary 
change to glibc et al.

regards.


>
> 	Ethan
>
>

Re: timefmt specifier

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

On Saturday 27 March 2010, pl...@pi... wrote:
> Hi,
> 
> I have an additional problem/suggestion relating to a similar set of data
> 
> F-00238    378  700323-700330     511.0  -28.8    516.6    11
> 
> the date (range) is contained in $3 this one being 23rd March 1970 - 
> 30th March 1970
> 
> Unless I have missed a trick it does not seem possible to read this in 
> with gnuplot (more awking required?)

I have never figured out how to use gnuplot's builtin time/date routines
effectively.  I suggest you read in the relevant field of the input file
as a string or a pure integer and do the date formatting yourself
using strptime()/strftime(). 

> What would be useful is a dead text specifier. The useful data matches 
> %y%m%d but I can't tell it to ignore the rest.
> 
> A new specifier like %i to ignore the rest of the string would be useful 
> (and easy to add ).
> 
>   "%y%m%d-%i"
> 
> Have I missed an easy way to handle this?

See above. Read it as a string and chop it into the pieces you need.

 mystartdate(i) = strcol(i)[5:6]."-".strcol(i)[3:4]."-19".strcol(i)[1:2]

plot foo using  (mystartdate(3)): ....

will turn your 700323-700330 into "23-03-1970", which you can now do with
whatever you like.  Of course this particular function forces all your
dates into C20.  You'd need a more complicated function to match a 
different convention of input dates. 

	Ethan



	Ethan

Re: timefmt specifier

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

On 03/28/10 01:03, pl...@pi... wrote:
> Hi,
>
> I have an additional problem/suggestion relating to a similar set of data
>
> F-00238    378  700323-700330     511.0  -28.8    516.6    11
>
> the date (range) is contained in $3 this one being 23rd March 1970 -
> 30th March 1970
>
> Unless I have missed a trick it does not seem possible to read this in
> with gnuplot (more awking required?)
>
> What would be useful is a dead text specifier. The useful data matches
> %y%m%d but I can't tell it to ignore the rest.
>
> A new specifier like %i to ignore the rest of the string would be useful
> (and easy to add ).
>
>    "%y%m%d-%i"
>
> Have I missed an easy way to handle this?
>
> TIA, Peter.
>

Oops, the error was not what I thought . This is readable.

Sorry for the noise.

/P/

Re: unix epoch data wrapping

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

On Saturday 27 March 2010, Jonathan Thornburg wrote:
> If I write the 2-digit year "50", does it mean 1950 or 2050?
>         [Let's leave aside the possibility of other centuries.]
> In the original poster's case, I gather that 1950 would have been the
> correct interpretation.  But if I were plotting future values of a
> retirement portfolio, 2050 would probably be the better choice.
> Fundamentally, there is no way for gnuplot to know the "correct"
> choice, so it has to make an arbitrary choice (which will be wrong
> a fair number of times).

Indeed. 
And if you are plotting a timeline of Roman emperors, "68" really
does mean 68, the year of Nero's death. 

There is no end to this quagmire.  The behaviour of a program may even
depend on which library version it is linked against. Consider this
lovely bit from the man page for strptime: 
   The  'y' (year in century) specification is taken to specify a year in
   the 20th century by libc4 and libc5. It is taken to be a year  in  the
   range  1950-2049  by  glibc 2.0. It is taken to be a year in 1969-2068
   since glibc 2.1.

So yes, I'll add a note in the documentation.  But better by far not to
use two-digit dates.

	Ethan

timefmt specifier

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

Hi,

I have an additional problem/suggestion relating to a similar set of data

F-00238    378  700323-700330     511.0  -28.8    516.6    11

the date (range) is contained in $3 this one being 23rd March 1970 - 
30th March 1970

Unless I have missed a trick it does not seem possible to read this in 
with gnuplot (more awking required?)

What would be useful is a dead text specifier. The useful data matches 
%y%m%d but I can't tell it to ignore the rest.

A new specifier like %i to ignore the rest of the string would be useful 
(and easy to add ).

  "%y%m%d-%i"

Have I missed an easy way to handle this?

TIA, Peter.

Re: unix epoch data wrapping

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

On 03/27/10 23:45, Jonathan Thornburg wrote:
> On Sat, 27 Mar 2010, Ethan Merritt quoted from the gnuplot source code:
> #              /* In line with the current UNIX98 specification by
> #               * The Open Group and major Unix vendors,
> #               * two-digit years 69-99 refer to the 20th century, and
> #               * values in the range 00-68 refer to the 21st century.
> #               */
>
> On Saturday 27 March 2010, pl...@pi... wrote:
>> OK, that is certainly the source of what is happening. That seems a
>> pretty arbitrary and dumb way to define behaviour that for no good
>> reason is based on the otherwise irrelevant unix year dot.
>
> It's not based on the Unix time epoch -- the gnuplot %y-interpretation
> switch is between 31 Dec 1968 and 1 Jan 1969, while the Unix time epoch
> is a year later, on 1 Jan 1970.
>
>
>> Still that's
>> the way it is and it's outside of gnuplot. I'm curious as to whether
>> this works that same on windows which thinks the world was created in
>> 1980, not 1970.
>
> On Sat, 27 Mar 2010, Ethan Merritt wrote:
> # Apparently MSWin (or at least Excel) uses a rule that
> # 00-29 is a 21st century date, while  30-99 is a 20th century date.
> # I have no idea what they are expecting to happen in 2030.
>
>
> If I write the 2-digit year "50", does it mean 1950 or 2050?
> 	[Let's leave aside the possibility of other centuries.]
> In the original poster's case, I gather that 1950 would have been the
> correct interpretation.  But if I were plotting future values of a
> retirement portfolio, 2050 would probably be the better choice.
> Fundamentally, there is *no* *way* for gnuplot to know the "correct"
> choice, so it has to make an *arbitrary* choice (which will be wrong
> a fair number of times).

That is correct , so maybe that defines the need for a way to specify 
the correct breakpoint.

As an arbitrary rule the MS choice probably gives the most useful range 
(for the foreseeable future) since it allows data back to 1931 - 2030 on 
two digit format.

It seems a bit mad that with data all within a 50 year period in the 
same century I can't deal with this without 'awk'ward hacking of the 
data files.

This isn't a bug as such but a better mechanism could be provided. My 
previous comment was that this was a documentation bug , so thanks for 
providing a patch to clarify the help.
.
I should be pretty simple to provide a variable to over-ride the 
rollover date for this sort of case.

CENTURY_ROLLOVER=1969

This would mimic current behaviour and provide backwards compatability. 
Setting such a variable could then cope with any data set that spans 
less than 100 years, in the two digit format.

The current functionality can only handle this if all data is pre 1969 
or post 1969. This being far from a typical situation it would seem to 
be bit restrictive.

Does that seem like a useful solution to a valid short-coming?

Regards. Peter.




>
> IMHO gnuplot's current choice is a reasonable one (it's certainly the
> only one I've ever seen in other software, albeit I've never used
> MS-Excel).  So, IMHO this is a feature, not a bug.
>
> But it would be useful to document this feature.  Here's a suggested
> patch ('diff -u' format) to gnuplot.doc:
>
> *** gnuplot.doc.orig	Sun May 17 22:47:35 2009
> --- gnuplot.doc	Sat Mar 27 18:42:43 2010
> ***************
> *** 9687,9696 ****
> --- 9687,9700 ----
>     it can still be printed with the "%a", "%A", "%b", or "%B" specifier:
>     see `set format` for more details about these and other options for printing
>     timedata.  (`gnuplot` will determine the proper month and weekday from the
>     numerical values.)
>
> +  In line with the current UNIX98 specification by The Open Group and major
> +  Unix vendors, when reading two-digit years with %y, values 69-99 refer to
> +  the 20th century, while values 00-68 refer to the 21st century.
> +
>     See also `set xdata` and `Time/date` for more information.
>
>     Example:
>           set timefmt "%d/%m/%Y\t%H:%M"
>     tells `gnuplot` to read date and time separated by tab.  (But look closely at
>
>

Re: unix epoch data wrapping

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

On Sat, 27 Mar 2010, Ethan Merritt quoted from the gnuplot source code:
#              /* In line with the current UNIX98 specification by
#               * The Open Group and major Unix vendors,
#               * two-digit years 69-99 refer to the 20th century, and
#               * values in the range 00-68 refer to the 21st century.
#               */

On Saturday 27 March 2010, pl...@pi... wrote:
> OK, that is certainly the source of what is happening. That seems a 
> pretty arbitrary and dumb way to define behaviour that for no good 
> reason is based on the otherwise irrelevant unix year dot.

It's not based on the Unix time epoch -- the gnuplot %y-interpretation
switch is between 31 Dec 1968 and 1 Jan 1969, while the Unix time epoch
is a year later, on 1 Jan 1970.


> Still that's 
> the way it is and it's outside of gnuplot. I'm curious as to whether 
> this works that same on windows which thinks the world was created in 
> 1980, not 1970.

On Sat, 27 Mar 2010, Ethan Merritt wrote:
# Apparently MSWin (or at least Excel) uses a rule that
# 00-29 is a 21st century date, while  30-99 is a 20th century date.  
# I have no idea what they are expecting to happen in 2030.


If I write the 2-digit year "50", does it mean 1950 or 2050?
	[Let's leave aside the possibility of other centuries.]
In the original poster's case, I gather that 1950 would have been the
correct interpretation.  But if I were plotting future values of a
retirement portfolio, 2050 would probably be the better choice.
Fundamentally, there is *no* *way* for gnuplot to know the "correct"
choice, so it has to make an *arbitrary* choice (which will be wrong
a fair number of times).

IMHO gnuplot's current choice is a reasonable one (it's certainly the
only one I've ever seen in other software, albeit I've never used
MS-Excel).  So, IMHO this is a feature, not a bug.

But it would be useful to document this feature.  Here's a suggested
patch ('diff -u' format) to gnuplot.doc:

*** gnuplot.doc.orig	Sun May 17 22:47:35 2009
--- gnuplot.doc	Sat Mar 27 18:42:43 2010
***************
*** 9687,9696 ****
--- 9687,9700 ----
   it can still be printed with the "%a", "%A", "%b", or "%B" specifier:
   see `set format` for more details about these and other options for printing
   timedata.  (`gnuplot` will determine the proper month and weekday from the
   numerical values.)
  
+  In line with the current UNIX98 specification by The Open Group and major
+  Unix vendors, when reading two-digit years with %y, values 69-99 refer to
+  the 20th century, while values 00-68 refer to the 21st century.
+ 
   See also `set xdata` and `Time/date` for more information.
  
   Example:
         set timefmt "%d/%m/%Y\t%H:%M"
   tells `gnuplot` to read date and time separated by tab.  (But look closely at


-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy, 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: unix epoch data wrapping

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

On Saturday 27 March 2010, pl...@pi... wrote:

>>              /* In line with the current UNIX98 specification by
>>               * The Open Group and major Unix vendors,
>>               * two-digit years 69-99 refer to the 20th century, and
>>               * values in the range 00-68 refer to the 21st century.
>>               */
>> 
> OK, that is certainly the source of what is happening. That seems a 
> pretty arbitrary and dumb way to define behaviour that for no good 
> reason is based on the otherwise irrelevant unix year dot. Still that's 
> the way it is and it's outside of gnuplot. I'm curious as to whether 
> this works that same on windows which thinks the world was created in 
> 1980, not 1970.

Apparently MSWin (or at least Excel) uses a rule that
00-29 is a 21st century date, while  30-99 is a 20th century date.  
I have no idea what they are expecting to happen in 2030.

Re: unix epoch data wrapping

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

On 03/27/10 20:27, sfeam (Ethan Merritt) wrote:
> On Saturday 27 March 2010, pl...@pi... wrote:
>> On 03/27/10 16:31, Jonathan Thornburg wrote:
>
>>> 2-digit years are fundamentally ambiguous, so some (arbitrary) decision
>>> must be made to resolve that ambiguity.  I'm not sure how gnuplot implements
>>> this internally, but The X/Open standard documents a function  strptime()
>>> whose man page on my computer says
>>> |      %y    the year within the current century.  When a century is not other-
>>> |            wise specified, values in the range 69-99 refer to years in the
>>> |            twentieth century (1969 to 1999 inclusive); values in the range
>>> |            00-68 refer to years in the twenty-first century (2000 to 2068 in-
>>> |            clusive).  Leading zeros are permitted but not required.
>
>  From the gnuplot source file time.c:
>
>          case 'y':               /* year number */
>              s = read_int(s, 2,&tm->tm_year);
>              /* In line with the current UNIX98 specification by
>               * The Open Group and major Unix vendors,
>               * two-digit years 69-99 refer to the 20th century, and
>               * values in the range 00-68 refer to the 21st century.
>               */
>              if (tm->tm_year<= 68)
>                  tm->tm_year += 100;
>              date++;
>              tm->tm_year += 1900;
>              break;
>
>
>
Thanks Ethan,

shouldn't the doc as well as the source indicate this oddity?

regards.

Re: unix epoch data wrapping

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

On Saturday 27 March 2010, pl...@pi... wrote:
> On 03/27/10 16:31, Jonathan Thornburg wrote:

> > 2-digit years are fundamentally ambiguous, so some (arbitrary) decision
> > must be made to resolve that ambiguity.  I'm not sure how gnuplot implements
> > this internally, but The X/Open standard documents a function  strptime()
> > whose man page on my computer says
> > |      %y    the year within the current century.  When a century is not other-
> > |            wise specified, values in the range 69-99 refer to years in the
> > |            twentieth century (1969 to 1999 inclusive); values in the range
> > |            00-68 refer to years in the twenty-first century (2000 to 2068 in-
> > |            clusive).  Leading zeros are permitted but not required.

From the gnuplot source file time.c:

        case 'y':               /* year number */
            s = read_int(s, 2, &tm->tm_year);
            /* In line with the current UNIX98 specification by
             * The Open Group and major Unix vendors,
             * two-digit years 69-99 refer to the 20th century, and
             * values in the range 00-68 refer to the 21st century.
             */
            if (tm->tm_year <= 68)
                tm->tm_year += 100;
            date++;
            tm->tm_year += 1900;
            break;

Re: unix epoch data wrapping

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

On 03/27/10 16:31, Jonathan Thornburg wrote:
> On Sat, 27 Mar 2010, pl...@pi... wrote:
>> I have just tried a quick plot of some historical C14 data and got the
>> the plot split in two.
>>
>> the data format is:
>>
>>     68    5   31  31-May-68  -24.8   560.5    3.9 NZ2206
>>
>> I'm reading it with :
>> set timefmt  "%d-%b-%y"
>>
>>
>> the data goes from 1957 to 1990 but gets parsed incorrectly such that
>> any dates prior to '70 gets plotted as dates upto 2070
>
> The key is your date "31-May-68".  Gnuplot has to guess whether this
> means 31 May 1968 or 31 May 2068... and evidently it guessed wrong.
> What happens if you change the data format to be unambiguous, i.e. a
> date "31-May-1968" with   set timefmt "%d-%b-%Y" .  Does that parse
> correctly?
>

short of editting the whole text file that is not too practical. Well I 
suppose I could start scatching my head trying to make an awk script to 
pre-process the data but....


>
>> This presumably has something to do with unix year zero. However, I
>> don't see why underlying system internals should be exposed to the
>> interpretation of user data.
>>
>>
>> Is this some cunning feature or a bug?
>
> 2-digit years are fundamentally ambiguous, so some (arbitrary) decision
> must be made to resolve that ambiguity.  I'm not sure how gnuplot implements
> this internally, but The X/Open standard documents a function  strptime()
> whose man page on my computer says
> |      %y    the year within the current century.  When a century is not other-
> |            wise specified, values in the range 69-99 refer to years in the
> |            twentieth century (1969 to 1999 inclusive); values in the range
> |            00-68 refer to years in the twenty-first century (2000 to 2068 in-
> |            clusive).  Leading zeros are permitted but not required.
>
> ciao,
>

OK, that is certainly the source of what is happening. That seems a 
pretty arbitrary and dumb way to define behaviour that for no good 
reason is based on the otherwise irrelevant unix year dot. Still that's 
the way it is and it's outside of gnuplot. I'm curious as to whether 
this works that same on windows which thinks the world was created in 
1980, not 1970.

This dependancy on "current century" is a beauty. Any program dependant 
on this behaviour would have gone tits-up in y2k roll-over. No wonder 
they grounded all aircraft !

However, gnuplot's help timefmt tells me:

        Format       Explanation
        %d           day of the month, 1--31
        %m           month of the year, 1--12
        %y           year, 0--99
        %Y           year, 4-digit

This is what I refered to when I hit this issue and it indicated I had 
done the right thing. This is wrong and hence a bug. There is no mention 
of 0-69 this century : 70-99 next century.

I find this behaviour so inherently stupid that maybe gnuplot should be 
coding around it.

This must be a pretty typical situation to hit since the turn of the 
century , is there no better solution than pre-parse all my data files 
with awk?!

Thanks for pointing out the root of the problem .

best,

  Peter.