|Warning message, why?||Leo||12/10/10 10:16 AM|
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.
## If at this point I plot the object, I get the warning...
qqq + pltgeom + pltxtfnty + pltheme
## And if I add the error bars...
qqq + pltgeom + pltxtfnty + pltheme + plerrbar
## Warning still there.
What causes it? How to avoid it (other than suppressing/catching R
Thanks for any help!
|Re: Warning message, why?||James McCreight||12/11/10 9:06 AM|
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
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 McCreight mccreigh at colorado.edu
NASA Postdoctoral Fellow
cell: (831) 261-5149
|RE: Warning message, why?||Leo||12/12/10 3:18 PM|
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!
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.
|Re: Warning message, why?||Brian Diggs||12/13/10 11:00 AM|
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
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", "
R/fortify-spatial.r:22: message("Using ", region, " to define
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 =
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
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
> 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!
>> From: mccre...@gmail.com [mailto:mccre...@gmail.com] On Behalf Of James McCreight
> Sent: Saturday, December 11, 2010 9:06 AM> To post: email ggp...@googlegroups.com<mailto:ggp...@googlegroups.com>
> To unsubscribe: email ggplot2+u...@googlegroups.com<mailto:ggplot2%2Bunsubscribe@googlegroups.com>
> More options:http://groups.google.com/group/ggplot2> James McCreight mccreigh at colorado.<mailto:mccre...@colorado.org>edu
|Re: Warning message, why?||Hadley Wickham||12/13/10 11:36 AM|
> The message is created in position-collide.r, line 47. It looks like
It probably shouldn't occur for dodge, but it's necessary for stack,