I'm guessing you have something in your environment that is causing
confusion. If it has survived the re-installations, then it may be in a
workspace that is being loaded on startup.
On a fresh startup, what does ls() and conflicts() give?
Do you have this problem if you start R with the --vanilla option?
--
Brian S. Diggs, PhD
Senior Research Associate, Department of Surgery
Oregon Health & Science University
(a) don't attach data frames if you don't have to;
(b) qplot() has a data argument, whose purpose is to temporarily
attach the data frame until qplot() completes; this is documented on
the help page and illustrated in the free on-line chapter regarding
qplot(), found at
http://had.co.nz/ggplot2/book/qplot.pdf
It's safer to use the data = argument of qplot() than to attach a data
frame to a session.
Try
library('ggplot2')
qplot(hp, wt, data = mtcars)
ggplot(mtcars, aes(x = 1, fill = factor(cyl))) +
geom_bar(position = 'stack', binwidth = 0.2)
These work for me on a Win 7, 64-bit system. I tried parts of your
code on my system and they also worked. To make a sensible stacked
(percentage) bar plot, it's useful to have two factors in the plot
call: one to provide individual bars for the factor of interest, the
other to perform the stacking. The stacking variable is typically
associated with an aesthetic and will produce a legend by default.
This is a rather inane example, but it illustrates the point; you can
think of it as a way of checking that the design giving rise to the
data is balanced:
ggplot(OrchardSprays, aes(x = treatment, fill = factor(colpos))) +
geom_bar(position = 'stack')
As far as the error message is concerned, I'm wondering if you have
one or more objects in your workspace that conflict with the attached
mtcars data frame (one reason why attaching data frames is often not a
good idea). I'd look for potential conflicts between the objects in
your workspace, the variables in the attached data frame and possibly
with the functions in the ggplot2 package. A good rule of thumb is not
to save objects in your workspace but rather to create and save script
files that can quickly reproduce the objects when necessary. In other
words, don't clutter up the workspace with objects other than the ones
you're working on at the moment.
Dennis
> --
> You received this message because you are subscribed to the ggplot2 mailing list.
> Please provide a reproducible example: http://gist.github.com/270442
>
> To post: email ggp...@googlegroups.com
> To unsubscribe: email ggplot2+u...@googlegroups.com
> More options: http://groups.google.com/group/ggplot2
Are you talking about the sm package? (
http://cran.r-project.org/web/packages/sm/index.html )? If so, I can't
reproduce the problem. I installed sm, loaded it and ggplot2, and
everything worked fine. Also, looking at the documentation, sm doesn't
define an seq function.
The "running the code from scratch" bit makes me think it is something
in your workspace that gets loaded when you restart R. After you first
start R, is there a variable seq? It would show up in ls() or
conflicts(). This is before you load any packages. If so, that is the
source of your problem. You need to delete that workspace (assuming it
has nothing of value in it) or save a new one which does not have seq
defined.
> Any tips on how to avoid these two conflicting with each other? I'm
> used to python where you can specify the package before the function
> (i.e. ggplot2.ggplot() rather than ggplot() alone). Is this possible
> in R? If not, do you suggest a rm(), detach(packages:), or other
> method for avoiding the conflict? Thanks again for your help on this.
You can specify a package using ::. So it would be ggplot2::ggplot().
But that only handles the initial function call, not all functions that
function calls.
> On Feb 17, 2:17 pm, swajud<walker.sara...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Thanks for the input. conflicts() revealed a generic named variable
>> "seq" which I had read about in other help topics with the same error.
>> The odd thing is, seq was not being directly called in the plot and is
>> only processed in a function I built, but when I removed it the
>> problem went away. Perhaps I stepped through the function manually at
>> some point to debug and forgot to remove the variable. Thanks for
>> looking into this!
>>