The following commands illustrate a problem with graphing relatively large data sets using the "line" option to plot: temp <- runif(200000) # or whatever other numbers you like; # same thing happens with a sine wave plot(1:200000, temp) # everything fine plot(1:200000, temp, type="l") # data gets cut off The number of points isn't crucial. The cutoff point appears to be about 65,000 points. (70,000 points demonstrates the cutoff; with 50,000 points there's no cutoff.) As far as I can tell, the problem only occurs when using the option type="l". It's unaffected by color, line type, and line width. Matt Wiener -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
mcw@ln.nimh.nih.gov writes:> The following commands illustrate a problem with graphing relatively large > data sets using the "line" option to plot: > > temp <- runif(200000) # or whatever other numbers you like; > # same thing happens with a sine wave > plot(1:200000, temp) # everything fine > plot(1:200000, temp, type="l") # data gets cut off > > > The number of points isn't crucial. The cutoff point appears to be about > 65,000 points. (70,000 points demonstrates the cutoff; with 50,000 points > there's no cutoff.) > > As far as I can tell, the problem only occurs when using the > option type="l". It's unaffected by color, line type, and line width. > > Matt WienerDoesn't happen to me with 0.63.pre-3 on RedHat Linux. I can't offhand see any documented fixes that would affect this, perhaps there's an OS difference? Looks a bit like a short integer overrun (65536=2^16) -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Tue, 16 Feb 1999 Matt Wiener, mcw@ln.nimh.nih.gov wrote:> > The following commands illustrate a problem with graphing relatively large > data sets using the "line" option to plot: > > temp <- runif(200000) # or whatever other numbers you like; > # same thing happens with a sine wave > plot(1:200000, temp) # everything fine > plot(1:200000, temp, type="l") # data gets cut off > > > The number of points isn't crucial. The cutoff point appears to be about > 65,000 points. (70,000 points demonstrates the cutoff; with 50,000 points > there's no cutoff.)This is device-specific (and which device was not mentioned). It does not happen on Windows (rw0632) nor on a postscript device. It does happen on the Unix x11() device for me, and my guess is that it is a limitation in the X library used. (Not in the X server, for this works in gs displaying postscript, and in S-PLUS. The lines are drawn in a single Xlib call.) Do you really want to plot such a dataset in one go? What do you expect to see of significance in 200000 points? (There are by default only about twice that many pixels on the device surface.) Are they really one group? Would some group colour coding help? .... -- Brian D. Ripley, ripley@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 272860 (secr) Oxford OX1 3TG, UK Fax: +44 1865 272595 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Prof Brian D Ripley <ripley@stats.ox.ac.uk> writes:> On Tue, 16 Feb 1999 Matt Wiener, mcw@ln.nimh.nih.gov wrote: > > > > > The following commands illustrate a problem with graphing relatively large > > data sets using the "line" option to plot: > > > > temp <- runif(200000) # or whatever other numbers you like; > > # same thing happens with a sine wave > > plot(1:200000, temp) # everything fine > > plot(1:200000, temp, type="l") # data gets cut off > > > > > > The number of points isn't crucial. The cutoff point appears to be about > > 65,000 points. (70,000 points demonstrates the cutoff; with 50,000 points > > there's no cutoff.) > > This is device-specific (and which device was not mentioned). It does not > happen on Windows (rw0632) nor on a postscript device. It does happen on > the Unix x11() device for me, and my guess is that it is a limitation in > the X library used. (Not in the X server, for this works in gs > displaying postscript, and in S-PLUS. The lines are drawn in a single Xlib > call.)Apparently, this is not only device-specific but X-server specific as the following network experiment shows: Run on Linux, display Linux OK Run on Solaris, display Linux OK Run on Solaris, display Solaris Error Run on Linux, display Solaris Error So it seems that the Solaris OpenWindows X Server cannot handle requests for drawing lines through more than 64K points. I suppose we *could* fix this by splitting all XDrawLines into blocks of max 64K. The man page for XDrawLines and friends have the following blob: All x and y members are signed integers. The width and height members are 16-bit unsigned integers. You should be careful not to generate coordinates and sizes out of the 16-bit ranges, because the protocol only has 16-bit fields for these values. The "and sizes" bit might be taken to mean that you should do the above, although it's beyond me how it would work on any platform if there's only room for 16 bits in the protocol (perhaps the protocol has changed from X11R5 to R6?). XDrawLines only occurs twice in devX11.c, so I suppose it's no big deal to fix up. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._