Hi,
I have a query about the maximum length of vector that can be plotted
in one go in a postscript driver. Try the following code (in 1.7.0;
version details below):
t <- seq(from=0, to=4*pi, length=200000)
y <- sin(t)
postscript(file="o.ps")
plot(t, y, type="l")
dev.off()
If I view the postscript file o.ps in "gv", it takes many seconds
before eventually the axes appear, but then only one vertical line is
drawn within the plot area -- there is no sine curve. (this is on a
fast dual processor linux machine with 2Gb RAM.) This is clearly a
postscript problem, rather than a R problem, since reducing the length
of t down to something like 2000 solves the problem. By looking at
the file o.ps it looks like the line is drawn by one "rlineto" call
per point, followed eventually by a "stroke" after the last point.
I'm guessing that the postscript interpreter simply cannot remember so
many points in the path before it gets to the stroke.
The example above is artificial, but this problem appeared with a real
data set this morning. The fix was to replace the single call to
plot() with many calls to line(), breaking the t and y vectors into
more manageable chunks; in this way, each postscript path was
manageable and we got the plot.
I tried plotting the same long vectors in gnuplot by first writing
them from R:
write.table(cbind(t,y), sep="\t", file="eg.dat",
row.names=F, col.names=F,
quote=F)
and then in gnuplot:
set term postscript
set output "gnuplot.ps"
plot "eg.dat" wi lines
This came out fine; in gnuplot.ps every 400 lines during the plot it
outputs "currentpoint stroke M" (M is defined to moveto). I had a
look at the gnuplot source (gnuplot-3.7.3/term/post.trm) and found
that it does keep count of the length of the current postscript path:
e.g. in the function PS_vector(x,y) we see (line 1122):
if (ps_path_count >= 400) {
fprintf(gpoutfile,"currentpoint stroke M\n");
ps_path_count = 0;
}
so every 400 points it draws the line so far and then continues.
(Matlab .ps files also seem to have regular "MP stroke".
I had a quick look in the corresponding R code src/main/devPS.c and
could not see any counter. Would it be worth adding such a counter
and periodic line output to PS_Polyline?
> version
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major 1
minor 7.0
year 2003
month 04
day 16
language R
I don't think that's entirely correct: as far as I know doing that resets the line-type pattern (and I have just checked the PostScript Reference manual). Level 1 Postscript interpreters often have a limit of about 1500 segments in a path, but level >=2 (all recent ones) are supposed to have no limit. It seems that your suggested change would help a few PostScript interpreters but damage the output for the rest. It is better that the end-user splits the polylines up. On Thu, 29 May 2003, Stephen Eglen wrote:> Hi, > > I have a query about the maximum length of vector that can be plotted > in one go in a postscript driver. Try the following code (in 1.7.0; > version details below): > > t <- seq(from=0, to=4*pi, length=200000) > y <- sin(t) > postscript(file="o.ps") > plot(t, y, type="l") > dev.off() > > If I view the postscript file o.ps in "gv", it takes many seconds > before eventually the axes appear, but then only one vertical line is > drawn within the plot area -- there is no sine curve. (this is on a > fast dual processor linux machine with 2Gb RAM.) This is clearly a > postscript problem, rather than a R problem, since reducing the length > of t down to something like 2000 solves the problem. By looking at > the file o.ps it looks like the line is drawn by one "rlineto" call > per point, followed eventually by a "stroke" after the last point. > I'm guessing that the postscript interpreter simply cannot remember so > many points in the path before it gets to the stroke. > > The example above is artificial, but this problem appeared with a real > data set this morning. The fix was to replace the single call to > plot() with many calls to line(), breaking the t and y vectors into > more manageable chunks; in this way, each postscript path was > manageable and we got the plot. > > I tried plotting the same long vectors in gnuplot by first writing > them from R: > > write.table(cbind(t,y), sep="\t", file="eg.dat", row.names=F, col.names=F, > quote=F) > > and then in gnuplot: > > set term postscript > set output "gnuplot.ps" > plot "eg.dat" wi lines > > This came out fine; in gnuplot.ps every 400 lines during the plot it > outputs "currentpoint stroke M" (M is defined to moveto). I had a > look at the gnuplot source (gnuplot-3.7.3/term/post.trm) and found > that it does keep count of the length of the current postscript path: > e.g. in the function PS_vector(x,y) we see (line 1122): > > if (ps_path_count >= 400) { > fprintf(gpoutfile,"currentpoint stroke M\n"); > ps_path_count = 0; > } > > so every 400 points it draws the line so far and then continues. > (Matlab .ps files also seem to have regular "MP stroke". > > I had a quick look in the corresponding R code src/main/devPS.c and > could not see any counter. Would it be worth adding such a counter > and periodic line output to PS_Polyline?-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
On 29-May-03 Stephen Eglen wrote:> t <- seq(from=0, to=4*pi, length=200000) > y <- sin(t) > postscript(file="o.ps") > plot(t, y, type="l") > dev.off() > > If I view the postscript file o.ps in "gv", it takes many seconds > before eventually the axes appear, but then only one vertical line is > drawn within the plot area -- there is no sine curve. (this is on a > fast dual processor linux machine with 2Gb RAM.) This is clearly a > postscript problem, rather than a R problem, since reducing the length > of t down to something like 2000 solves the problem. By looking at > the file o.ps it looks like the line is drawn by one "rlineto" call > per point, followed eventually by a "stroke" after the last point. > I'm guessing that the postscript interpreter simply cannot remember so > many points in the path before it gets to the stroke.Absolutely no problem here: beautiful sine curve, axes and all (gv-3.5.8 of June 1997, R-1.6.2, medium-speed 733MHz single processor with 512MB RAM running Linux; 15 seconds to draw the curve; 'gs' 5.5 took about 5 secs). At a guess your 'gv' is not coping. It's not a PS problem as such. Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <Ted.Harding at nessie.mcc.ac.uk> Fax-to-email: +44 (0)870 167 1972 Date: 29-May-03 Time: 19:00:38 ------------------------------ XFMail ------------------------------
When I run the example in R 1.6.2, and view it with gs, I get a good plot. When I run the example in R 1.7.0, and view it with gs, I get a bad plot. (run on the same host) My "bad plot" is as described by Stephen. In the "good" postscript file, about 100 lines in, there is this: %%EndProlog %%Page: 1 1 bp 77.04 91.44 743.76 534.96 cl 0.0000 0.0000 0.0000 rgb 0.75 setlinewidth [] 0 setdash np 101.73 313.20 m 101.74 313.21 l 101.74 313.23 l 101.74 313.24 l 101.75 313.25 l (followed by ~200000 lines of the same type, with slowly changing values) In the "bad" postscript file, at about the same point in the file, is this: %%EndProlog %%Page: 1 1 bp 77.04 91.44 743.76 534.96 cl 0 0 0 rgb 0.75 setlinewidth [] 0 setdash np 101.73 313.20 m 0.00 0.01 l 0.00 0.01 l 0.00 0.01 l 0.00 0.01 l 0.00 0.01 l (followed by ~200000 lines, including some like these) 0.00 0.00 l 0.00 0.00 l 0.00 -0.01 l 0.00 -0.01 l 0.00 -0.00 l 0.00 -0.00 l Looks like it might be a formatting issue on how these lines were written. My version information: ---- 1.6.2 ----> versionplatform sparc-sun-solaris2.7 arch sparc os solaris2.7 system sparc, solaris2.7 status major 1 minor 6.2 year 2003 month 01 day 10 language R>---- 1.7.0 ----> version_ platform sparc-sun-solaris2.7 arch sparc os solaris2.7 system sparc, solaris2.7 status major 1 minor 7.0 year 2003 month 04 day 16 language R [245]% gs --version 5.50 -Don At 5:59 PM +0100 5/29/03, Stephen Eglen wrote:>Hi, > >I have a query about the maximum length of vector that can be plotted >in one go in a postscript driver. Try the following code (in 1.7.0; >version details below): > >t <- seq(from=0, to=4*pi, length=200000) >y <- sin(t) >postscript(file="o.ps") >plot(t, y, type="l") >dev.off() > >If I view the postscript file o.ps in "gv", it takes many seconds >before eventually the axes appear, but then only one vertical line is >drawn within the plot area -- there is no sine curve. (this is on a >fast dual processor linux machine with 2Gb RAM.) This is clearly a >postscript problem, rather than a R problem, since reducing the length >of t down to something like 2000 solves the problem. By looking at >the file o.ps it looks like the line is drawn by one "rlineto" call >per point, followed eventually by a "stroke" after the last point. >I'm guessing that the postscript interpreter simply cannot remember so >many points in the path before it gets to the stroke. > >The example above is artificial, but this problem appeared with a real >data set this morning. The fix was to replace the single call to >plot() with many calls to line(), breaking the t and y vectors into >more manageable chunks; in this way, each postscript path was >manageable and we got the plot. > >I tried plotting the same long vectors in gnuplot by first writing >them from R: > >write.table(cbind(t,y), sep="\t", file="eg.dat", row.names=F, col.names=F, > quote=F) > >and then in gnuplot: > >set term postscript >set output "gnuplot.ps" >plot "eg.dat" wi lines > >This came out fine; in gnuplot.ps every 400 lines during the plot it >outputs "currentpoint stroke M" (M is defined to moveto). I had a >look at the gnuplot source (gnuplot-3.7.3/term/post.trm) and found >that it does keep count of the length of the current postscript path: >e.g. in the function PS_vector(x,y) we see (line 1122): > > if (ps_path_count >= 400) { > fprintf(gpoutfile,"currentpoint stroke M\n"); > ps_path_count = 0; > } > >so every 400 points it draws the line so far and then continues. >(Matlab .ps files also seem to have regular "MP stroke". > >I had a quick look in the corresponding R code src/main/devPS.c and >could not see any counter. Would it be worth adding such a counter >and periodic line output to PS_Polyline? > > >> version >platform i686-pc-linux-gnu >arch i686 >os linux-gnu >system i686, linux-gnu >status >major 1 >minor 7.0 >year 2003 >month 04 >day 16 >language R > >______________________________________________ >R-help at stat.math.ethz.ch mailing list >https://www.stat.math.ethz.ch/mailman/listinfo/r-help-- -------------------------------------- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA
On Thu, 29-May-2003 at 04:02PM -0700, Don MacQueen wrote: |> When I run the example in R 1.6.2, and view it with gs, I get a good plot. |> When I run the example in R 1.7.0, and view it with gs, I get a bad plot. |> (run on the same host) |> |> My "bad plot" is as described by Stephen. [ ... ] |> |> 0.00 -0.00 l |> 0.00 -0.00 l |> |> Looks like it might be a formatting issue on how these lines were written. |> |> My version information: |> |> ---- 1.6.2 ---- |> > version |> platform sparc-sun-solaris2.7 |> arch sparc |> os solaris2.7 |> system sparc, solaris2.7 |> status |> major 1 |> minor 6.2 |> year 2003 |> month 01 |> day 10 |> language R |> > |> |> ---- 1.7.0 ---- |> > version |> _ |> platform sparc-sun-solaris2.7 |> arch sparc |> os solaris2.7 |> system sparc, solaris2.7 |> status |> major 1 |> minor 7.0 |> year 2003 |> month 04 |> day 16 |> language R I can confirm similar results using Redhat Linux 7.3 with the same two R releases and gv 3.5.8. best -- Patrick Connolly HortResearch Mt Albert Auckland New Zealand Ph: +64-9 815 4200 x 7188 ~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~ I have the world`s largest collection of seashells. I keep it on all the beaches of the world ... Perhaps you`ve seen it. ---Steven Wright ~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~