Warning message, why?

[Leo]

Hello,

I am running into a warning that I don't understand. I tried several
options to see if I could tell what was causing it, but without luck.

library(ggplot2)

res.df<-as.data.frame(
cbind(
c(2005,2005,2005,2004,2004,2004,2006,2006,2006),
c(0,0,0.4,0,0.267,0,0,0.6,0),
c(0,0,0.563,0,0.392,0,0,0.967,0),
c(0,0,0.237,0,0.142,0,0,0.233,0)
)
)
names(res.df)<-c("Year","Abundance","ymax","ymin")

qqq<-ggplot(data=res.df,aes(x=Year,y=Abundance))
pltgeom<-geom_point(size=4,position=position_dodge(width=0.50))
pltxtfnty<-ggplot2::opts(
axis.title.y=theme_text(angle=90,size=16),
axis.text.y=theme_text(size=14)
)
pltheme<-ggplot2::theme_bw()

## If at this point I plot the object, I get the warning...

qqq + pltgeom + pltxtfnty + pltheme

## And if I add the error bars...

plerrbar<-ggplot2::geom_errorbar(data=res.df,stat="identity",

aes(ymin=ymin,ymax=ymax),width=0.2,position=position_dodge(width=0.50))

qqq + pltgeom + pltxtfnty + pltheme + plerrbar

## Warning still there.

What causes it? How to avoid it (other than suppressing/catching R
warnings)?

Thanks for any help!

Leo

[James McCreight]

Hi Leo-

is the error: ymax not defined: adjusting position using y instead ?

I get that "error" for just

qqq + pltgeom

So I focus on this only. The "error" appears to be coming from position_dodge somehow, because if you change 

pltgeom <- geom_point(size=4)

you dont get the error. Assuming you DONT make that change, you can make the error go away by

pltgeom <-geom_point(aes(ymax=max(Abundance)),size=4,position=position_dodge(width=0.50,height=0.1))

but that's strange because, as far as i see, position_dodge shouldnt want ymax. And doing it this way gives exactly the same plot. So, though it's giving an error, it seems to be doing the desired thing.... maybe a little rough spot in the code? It dosent appear to be affected by options(warn=) either, so it's not really a warning or an error, i'd say. I wouldnt call it a bug, since the behaviour seems correct, but maybe a rogue print statement? That's my best guess.

Hopefully I've addressed the error message you were talking about. As my SA always says, copy the error message down, if you can.

As and aside, you'll probably also want to

res.df$Year <- factor(res.df$Year)

for the sake of a clean x-axis.

Best and HTH, 

James

--
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

--
-
******************************************************************************
James McCreight                                  mccreigh at colorado.edu
NASA Postdoctoral Fellow
cell: (831) 261-5149

[Leonardo Salas]

James -

Thanks for the help.  I did not realize that the dodge function was the source of the “warning”.  The warning is more a limitation than a problem on my end – the code is buried down many layers and the warning is luckily not passed up beyond the immediate calling method.  It would be great to have it removed so I can call the method from any level, and you gave me an option (my code sends back xml to a client and any print statement is also sent, resulting in client receiving “incorrect xml”).  Thank you!

 

Leo

Ps.  I understand what you are suggesting with Year as factor to beautify the x-axis.  I’m handling the x-axis labels some other way, still keeping Year as integer.  But thank you for that suggestion too, anyway.

[Brian Diggs]

I had seen this error/warning too. It is related to the
position_dodge. In fact, it is a level "below" a warning even; it is
a message. That's why changing the handling of warnings didn't affect
it.

The message is created in position-collide.r, line 47. It looks like
it was a debugging message that got left in. I don't see any reason
for it; it is in a legitimate code path, and in fact probably the more
common one (a "y" but not a "ymax"). Can this be removed?

For comparison, I looked through the code for other uses of message():

$ grep -Rn "message(" *
R/aaa-examples.r:54: if (verbose) message("Running examples for", "
", x$my_name())
R/fortify-spatial.r:22: message("Using ", region, " to define
regions.")
R/position-collide.r:47: message("ymax not defined: adjusting
position using y instead")
R/position-stack.r:7: message("Missing y and ymax in position =
'stack'. ",
R/save.r:70: message("Saving ", prettyNum(width * scale, digits=3),
"\" x ", prettyNum(height * scale, digits=3), "\" image")
R/stat-bin.r:105: message("stat_bin: binwidth defaulted to range/
30. Use 'binwidth = x' to adjust this.")
R/stat-smooth.r:6: message("geom_smooth: Only one unique x value
each group.",
R/theme.r:87: message("Theme element ", element, " missing")

The other uses are for requested verbose output (aaa-examples.r),
using defaults which may not be what was wanted (fortify-spatial.r,
save.r, stat-bin.r), and doing nothing when nothing could be done
despite something being requested to be done (position-stack.r, stat-
smooth.r, theme.r). At best, the use in position-collide.r could go
with the "using defaults" usage, but that is a stretch.

--
Brian S. Diggs, PhD
Senior Research Associate, Department of Surgery
Oregon Health & Science University

On Dec 12, 3:18 pm, Leonardo Salas <lsa...@prbo.org> wrote:
> James -

> Thanks for the help.  I did not realize that the dodge function was the source of the "warning".  The warning is more a limitation than a problem on my end - the code is buried down many layers and the warning is luckily not passed up beyond the immediate calling method.  It would be great to have it removed so I can call the method from any level, and you gave me an option (my code sends back xml to a client and any print statement is also sent, resulting in client receiving "incorrect xml").  Thank you!

>
> Leo
> Ps.  I understand what you are suggesting with Year as factor to beautify the x-axis.  I'm handling the x-axis labels some other way, still keeping Year as integer.  But thank you for that suggestion too, anyway.
>

> From: mccre...@gmail.com [mailto:mccre...@gmail.com] On Behalf Of James McCreight
> Sent: Saturday, December 11, 2010 9:06 AM
> To: Leonardo Salas
> Cc: ggplot2
> Subject: Re: Warning message, why?
>
> Hi Leo-
>
> is the error: ymax not defined: adjusting position using y instead ?
>
> I get that "error" for just
>
> qqq + pltgeom
>
> So I focus on this only. The "error" appears to be coming from position_dodge somehow, because if you change
>
> pltgeom <- geom_point(size=4)
>
> you dont get the error. Assuming you DONT make that change, you can make the error go away by
>
> pltgeom <-geom_point(aes(ymax=max(Abundance)),size=4,position=position_dodge(width=0.50,height=0.1))
>
> but that's strange because, as far as i see, position_dodge shouldnt want ymax. And doing it this way gives exactly the same plot. So, though it's giving an error, it seems to be doing the desired thing.... maybe a little rough spot in the code? It dosent appear to be affected by options(warn=) either, so it's not really a warning or an error, i'd say. I wouldnt call it a bug, since the behaviour seems correct, but maybe a rogue print statement? That's my best guess.
>
> Hopefully I've addressed the error message you were talking about. As my SA always says, copy the error message down, if you can.
>
> As and aside, you'll probably also want to
>
> res.df$Year <- factor(res.df$Year)
>
> for the sake of a clean x-axis.
>
> Best and HTH,
>
> James
>

> To post: email ggp...@googlegroups.com<mailto:ggp...@googlegroups.com>
> To unsubscribe: email ggplot2+u...@googlegroups.com<mailto:ggplot2%2Bunsu...@googlegroups.com>

> More options:http://groups.google.com/group/ggplot2
>
> --
> -
> ******************************************************************************

> James McCreight                                  mccreigh at colorado.<mailto:mccre...@colorado.org>edu

[Hadley Wickham]

> The message is created in position-collide.r, line 47.  It looks like
> it was a debugging message that got left in.  I don't see any reason
> for it; it is in a legitimate code path, and in fact probably the more
> common one (a "y" but not a "ymax").  Can this be removed?

It probably shouldn't occur for dodge, but it's necessary for stack,
which you should only really use if you have ymin = 0 and ymax, not
just y. However, there's a few cases where it's useful with y (e.g.
stacking lines), even though stacking isn't really very well defined
in that case.

Hadley

--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/