On 11-02-09 7:40 PM, David Wolfskill wrote:
[New to the community; still in early part of R's learning curve.]
In the call below that has
plot(..., par(new=TRUE))
you don't name the parameter to which par(new=TRUE) will be bound, so
the first available is chosen, which was apparently xlim. That is, your
code is the same as
plot(..., xlim=par(new=TRUE))
which is not what you meant.
Normally you put the par(new=TRUE) call after the plot() call, not
within it, and then things will work:
plot(...)
par(new=TRUE)
This wasn't your question, but I generally advise against using
par(new=TRUE), because it does more than some people think. It throws
away the scaling that was determined in the first plot, so you can't
trust points in later plots to be at the locations that the axes show.
It is better to use the "add=TRUE" parameter to later plot functions if
they support it, or (in your case) use
lines(...)
rather than plot(...) after the first call.
Duncan Murdoch
Several months ago, I was requested to generate some graphs on a
periodic basis. Accordingly, I managed to figure out a way to do so,
using a combination of Perl and R (in a FreeBSD environment).
While I've needed to adjust a few things here and there, the general
approach has been pretty solid , and the R part has had very little
change perceived as necessary.
I re-generate the graphs each Wednesday morning (as they show disk space
utilization over time).
This morning, one of the graphs -- the first that used plot() with
"par(new = TRUE)" reported an error. Re-doing the work interactively,
I was able to re-create the problem. Poking around with
debug(plot.window) showed that while the ylim values make sense,
the xlim values are ... of an unexpected type altogether.
And when I re-tried the plot() invocation, but without the "par()"
argument, the xlim passed to plot.window() was fine, and the plot was
OK.
The data look like:
Tag Cap mean_GB median_GB census
1 2010-02-03 540972711754 213.5250 154.1011 1061
2 2010-02-10 531711798208 169.4235 124.3809 1033
3 2010-02-17 544482444926 171.2384 130.0641 1052
...
52 2011-01-26 558625618800 195.2759 175.1277 1386
53 2011-02-02 571187807274 199.4980 170.4478 1406
54 2011-02-09 562448031310 197.5468 166.8976 1367
I'm trying to generate a plot, then overlay 3 more plots on it -- which
has been working for several months:
plot(Is_total$Tag, Is_total$Cap/1024/1024/1024, type = "l", col = "blue", ylim = c(0,
max(Is_total$Cap/1024/1024, Is_total$census * 400)/1024), xlab = "Date", ylab = "Capacity(TB)", main =
"Total Local Disk Space")
debug(plot.window)
plot(Is_total$Tag, (Is_total$census * Is_total$mean)/1024, type = "l", col =
"green", ylim = c(0, max(Is_total$Cap/1024/1024, Is_total$census * 400)/1024), ann =
FALSE, axes = FALSE, par(new = TRUE))
debugging in: plot.window(...)
debug: .Internal(plot.window(xlim, ylim, log, asp, ...))
Browse[2]> ylim
[1] 0.0000 549.2188
Browse[2]> xlim
$new
[1] FALSE
Browse[2]> c
Error in plot.window(...) : invalid 'xlim' value
sessionInfo()
R version 2.12.1 (2010-12-16)
Platform: i386-portbld-freebsd8.2 (32-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
plot(Is_total$Tag, (Is_total$census * Is_total$mean)/1024, type = "l", col =
"green", ylim = c(0, max(Is_total$Cap/1024/1024, Is_total$census * 400)/1024), ann =
FALSE, axes = FALSE)
debugging in: plot.window(...)
debug: .Internal(plot.window(xlim, ylim, log, asp, ...))
Browse[2]> ylim
[1] 0.0000 549.2188
Browse[2]> xlim
[1] 14643 15014
Browse[2]> c
exiting from: plot.window(...)
q()
This is running on my laptop:
FreeBSD 8.2-PRERELEASE #99 r218478: Wed Feb 9 04:17:55 PST 2011
[email protected].:/common/S1/obj/usr/src/sys/CANARY
(Yes, I track FreeBSD stable/8 on it daily.)
I built R as a FreeBSD port; it is version 2.12.1. (I update the
installed ports daily, too.)
I actually first noticed the behavior on my desktop machine at work; it
is also running FreeBSD stable/8, but only updated as of 30 Jan 2011 --
and the problem did not exist last week. So I don't believe this is
because of a change in FreeBSD.
For now, I'm (also) open to circumventions, so I can avoid complaints
about the graphs that weren't updated at work, but I'd like to resolve
the issue. (And yes, I fully understand that what needs to be fixed is
my understanding of how to use the tools.)
Thanks!
Peace,
david
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
