ggplot2 0.8.4

[Hadley Wickham]

Hi everyone,

I've just uploaded the latest version of ggplot2 to cran and so it
should be available on your local mirror in the next couple of days.
It's basically just a big set of bug fixes, but there are a couple of
new features. I've included a complete changelog below.

I'll be working on ggplot2 quite a bit over Christmas, so please let
me know if you've discovered a new bug - the list of all bugs I
currently know about is available
http://github.com/hadley/ggplot2/issues, and if you look closely
you'll notice I've been working a lot of ggplot2 0.8.5 which includes
another big round of bug fixes. I'm hoping to release this in the
next week or two, and then begin on a big layout rewrite which will
herald ggplot2 0.9.

Regards,

Hadley

ggplot2 0.8.4 (2009-12-08) ----------------------------------------

* aes and aes_string both convert prefixes to full names
* aesthetics: corrected list of aesthetics to include american spelling of
colour as well as base R abbreviations
* aesthetics: fix bug in detecting which aesthetics are calculated
* aes_string treats NULL as "NULL"
* annotate now works with missing x and y (e.g. for geom_rect)
* continuous scale limits now automatically sorted
* coord_polar: fix bug if breaks not all inside limits
* facet_wrap: can now specify both ncol and nrow without getting an error
* facet_wrap: now works with statistics that produce both x and y values (e.g.
stat_qq)
* fullseq now adds additional break on bottom if necessary, so that the
include.lowest argument in cut never comes into play (this the source of a
potential bug in histograms)
* geom_boxplot: alpha now affects fill colour of boxes only
* geom_path correctly switches to segments if varying alpha used (thanks to
Karl Ove Hufthammer for the report and Baptiste Auguie for the fix)
* geom_point: the alpha aesthetic now also affects the fill.
* geom_ribbon always sorts input to avoid problems with certain pathological
inputs
* geom_smooth was incorrectly applying alpha to line colour in the legend
* nullGrob renamed to zeroGrob to avoid name conflict with grid
* position_collide now works with missing values
* position_stack: fixed bug in detection of overlap for negative values
* scale_discrete_position now uses drop argument to force dropping of unused
levels
* scale_gradient, scale_gradient2 and scale_gradientn now uses label
parameters, if supplied
* scale_x_inverse, scale_y_inverse now actually work, and added recip as alias
* stat_qq now correctly groups results
* stat_smooth will not try and fit a line to 2 or fewer points (previously
didn't try for only 1 point)
* stat_spoke now works with reversed scales
* grouping: now consistent between different geoms (Issue #33)

--
http://had.co.nz/

[baptiste auguie]

Thanks, I just installed it in R 2.10.1 and R 2.11, seems to work fine.

Regarding the layout rewrite, have you compiled a list of most wanted features?


All the best,

baptiste

> --
> You received this message because you are subscribed to the ggplot2 mailing list.
> To post to this group, send email to ggp...@googlegroups.com
> To unsubscribe from this group, send email to
> ggplot2+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/ggplot2

[hadley wickham]

Here's what I have on my list, in no particular order:

should have subtitle
think about double axes
legend alignment within box
key table with rows and columns
legend shouldn't overlap with plot
legend.position != "right"
should be able to override label alignment in legends
finally do facet label wrapping correctly
should be able to set fixed size for any element (incl. panel) - and
should be able to compute for ggsave
secondary axis which is a function of the primary axis
don't clip axis labels
aspect ratio and axis labels
should be able to control apperance of strips: T = always display, F =
never display, and NA = display if > 1
figure out how to do margins and padding properly
axis line should be plotted on top of panel.background
device size
should support multiple pages
margins should have bigger gaps
make sure facet labels span across all columns
make entire strip function a theme setting
more flexible strip formating to look like labels
some way of plotting nested factors with varying levels so that they
line up nicely - wrap within grid

Hadley

--
http://had.co.nz/

[Nicholas Lewin-Koh]

Hi Hadley,
If you are going to support nested factors, it shouldn't be too hard
to support recursive conditioning in facets as well. Perhaps I am
pipe dreaming on this, but since it seems like it is in principle the
same consider this a request. Also, and perhaps a more inflammatory
request,
would be to be able to suppress the legend, but leave the viewport
available
for a custom legend eg something like geom_legend(aes(),data,....)
I am about to try the new version, I am hoping that the sorting feature
you added to geom_ribbon solves some headaches for me :)

Nicholas

On Thu, 10 Dec 2009 09:30 -0600, "hadley wickham" <h.wi...@gmail.com>
wrote:

[hadley wickham]

Hi Nicholas,

What exactly do you mean by recursive partitioning? It's probably the
same as what I'm thinking, but unfortunately it's unlikely to happen
due to the complexities of specifying how scales should be fixed or
free.

I'm hoping you'll be able to turn off the legend yet still have space
available by doing something like:

+ opts(legend.position = "none", legend.width = unit(2, "cm"))

Hadley

--
http://had.co.nz/

[baptiste auguie]

Great! (and good luck :-) )

If I'm not mistaken most of these features are implemented in lattice,
it might give you some inspiration. lattice is also faster at
arranging the plot elements on the page (pushing a viewport, then
drawing), although I prefer the way it's done with ggplot2 (assigning
viewports to the grobs).

One thing that I didn't see in the list is the ability to specify,

- manual axis breaks, limits and labels for each panel, with more
control than scales="free" (lattice gives the option of using a list
to override the defaults)

- manual spacing between panels.

Also a general wish: for most elements of a plot, I really like
lattice's functional and object oriented approach: you have a default
function that returns a graphical object (say, a facet strip), but you
can replace it with your own function to create a very original plot
(e.g. use the strip space to draw a sparkline).
The same remark applies to axes: I remember a recent request on this
list to draw chemical structures as axis labels. One could imagine a
user-defined function that returns an axis with custom grobs for the
labels. Of course one would have to ensure that all these elements
have a well defined size so that the layout knows how much space needs
to be allocated.


All the best,

baptiste

[Nicholas Lewin-Koh]

Hi Hadley,
I think I said recursive conditioning. And I think we are just trying to
get the
semantics right :)
So what I mean by conditioning is
x and y continuous
a, b and c factors (orthognal)
want to look at the relation x~y|a,b,c
So from a layout perspective, the order of conditioning matters.
Is this what you mean by nested factors? Gee calibrating language is
almost harder than calibrating assays ;)

Nicholas


On Thu, 10 Dec 2009 10:38 -0600, "hadley wickham" <h.wi...@gmail.com>

[hadley wickham]

On Thu, Dec 10, 2009 at 12:10 PM, Nicholas Lewin-Koh <ni...@hailmail.net> wrote:
> Hi Hadley,

> I think I said recursive conditioning. And I think we are just trying to
> get the
> semantics right :)
> So what I mean by conditioning is
>  x and y continuous
>  a, b and c factors (orthognal)
> want to look at the relation x~y|a,b,c
> So from a layout perspective, the order of conditioning matters.
> Is this what you mean by nested factors? Gee calibrating language is
> almost harder than calibrating assays ;)

I think so - basically facet_grid is useful for completely crossed
data, and facet_wrap for completely nested data, but there's no layout
that works particularly well for partial crossed data.

Anyway, it's unlikely I'll get to that in this round of changes, but I
hope to at least have a cleaner layout specification so that it will
be easier to implement in the future.

Hadley


--
http://had.co.nz/

[hadley wickham]

> If I'm not mistaken most of these features are implemented in lattice,
> it might give you some inspiration. lattice is also faster at
> arranging the plot elements on the page (pushing a viewport, then
> drawing), although I prefer the way it's done with ggplot2 (assigning
> viewports to the grobs).

I'm not willing to give up my use of grob objects, but I'm hopefully
that I can (eventually) find ways to speed up the drawing.

> One thing that I didn't see in the list is the ability to specify,
>
> - manual axis breaks, limits and labels for each panel, with more
> control than scales="free" (lattice gives the option of using a list
> to override the defaults)

Yes, because that's not really a layout issue - it's a scaling issue.
If you were interested in helping with this, the most useful thing
that you could do would be to come up with some suggestions for what
the syntax might look like.

> - manual spacing between panels.

This is tricky, but I'll definitely be thinking about it.

> Also a general wish: for most elements of a plot, I really like
> lattice's functional and object oriented approach: you have a default
> function that returns a graphical object (say, a facet strip), but you
> can replace it with your own function to create a very original plot
> (e.g. use the strip space to draw a sparkline).

Using functions for this is fine, the problem is figuring out just
what the arguments of each function should be. It's definitely
reasonable to pass the strip function the title of the strip, but if
you want to do something more interesting you need to pass in the data
- and what format should the data take? Should it be broken down by
layer? For labels that cover multiple panels (e.g. rows and columns in
facet_grid), how should the data be represented?

> The same remark applies to axes: I remember a recent request on this
> list to draw chemical structures as axis labels. One could imagine a
> user-defined function that returns an axis with custom grobs for the
> labels. Of course one would have to ensure that all these elements
> have a well defined size so that the layout knows how much space needs
> to be allocated.

I'll definitely think about this, but I'm not sure number of times it
would be used justifies the amount of work involved.

Hadley

--
http://had.co.nz/

[JiHO]

Hi Hadley,

Thanks for all your work on this. I see these fixes:

On Wed, Dec 9, 2009 at 21:33, Hadley Wickham <had...@rice.edu> wrote:
> * facet_wrap: can now specify both ncol and nrow without getting an error
> * facet_wrap: now works with statistics that produce both x and y values (e.g.
>  stat_qq)

but there is another bug with facet_wrap which I don't see in the
tracker: coord_equal is not respected.

d <- data.frame(x=runif(10), y=runif(10), z=c(rep(1,5), rep(2,5)))
ggplot(d) + geom_point(aes(x=x,y=y)) + coord_equal() + facet_grid(.~z)
ggplot(d) + geom_point(aes(x=x,y=y)) + coord_equal() + facet_wrap(~z)

More generally, a more consistent coord_equal and coord_map (as
discussed in previous posts on the list) would be much appreciated. I
don't know whether this is included in your "layout rewrite". I think
gpplot is particularly superior to base R graphics for drawing maps
and superposing layers on maps. Having the basics of the map layout
right would make it a killer tool in this respect. I am currently
dealing with sp objects and gstat quite a bit. Most objects look very
much like data.frames (or even have two classes, one of which is
data.frame) and should therefore be easy to deal with in ggplot
afterwards. I will be able to provide a bit of guidance if needed.

JiHO
---
http://maururu.net

[Hadley Wickham]

> More generally, a more consistent coord_equal and coord_map (as
> discussed in previous posts on the list) would be much appreciated. I
> don't know whether this is included in your "layout rewrite".

This is done already in 0.8.5 which I'll be realising either today or
later this week. If you can't wait, see
http://github.com/hadley/ggplot2/tree/ggplot-0.8.5.

(I've switched to using branches for releases, which I'm hoping will
make certain things simpler in the long run)

Hadley

--
http://had.co.nz/

[JiHO]

On Mon, Dec 14, 2009 at 22:57, Hadley Wickham <had...@rice.edu> wrote:
> This is done already in 0.8.5 which I'll be realising either today or
> later this week. If you can't wait, see
> http://github.com/hadley/ggplot2/tree/ggplot-0.8.5.

Great!

> (I've switched to using branches for releases, which I'm hoping will
> make certain things simpler in the long run)

So from what I see, development is still linear, meaning that the
master stopped and then all changes went to the 0.8.5 branch. So what
I should do if I want the bleeding edge is follow the new branch each
time (0.8.5, 0.8.6, 0.9 etc.) rather than the master.
I am afraid I don't really see the purpose of this new setup but I
guess there is one ;) I would just suggest that if you are trying to
reproduce svn-like release branches, that allow to:
1. only include some changes from the master into the release and
2. continue improving the release branch for point-releases after the
initial release is made
I would rather suggest a workflow such as:
- work on master
- tag 0.8.4 (the old way)
- branch 0.8.5 *immediately*
- work on master, change 1
- work on master, change 2
- work on master, change 3
- switch to branch 0.8.5
- merge changes 1 and 3 from master, 2 is not suited for this
release. This is not actually a merge operation but something like a
series of cherry-picking. You can use the method described in answer 2
of this stack overflow question:
http://stackoverflow.com/questions/449541/how-do-you-merge-selective-files-with-git-merge
to avoid doing all the cherry picking by hand.
- tag 0.8.5 release on the 0.8.5 branch
- checkout master
- branch 0.8.6
- work on master
- checkout 0.8.5
- fix a thing
- tag 0.8.5.1
- checkout master
- work on master
...
This way, all development stays on master and other parties can just
follow that. Making a release is picking out the pieces you want from
the master and storing them in the release branch.

JiHO
---
http://maururu.net

[Hadley Wickham]

>> (I've switched to using branches for releases, which I'm hoping will
>> make certain things simpler in the long run)
>
> So from what I see, development is still linear, meaning that the
> master stopped and then all changes went to the 0.8.5 branch. So what
> I should do if I want the bleeding edge is follow the new branch each
> time (0.8.5, 0.8.6, 0.9 etc.) rather than the master.
> I am afraid I don't really see the purpose of this new setup but I
> guess there is one ;) I would just suggest that if you are trying to
> reproduce svn-like release branches, that allow to:

Well, actually, I'm trying to avoid the problem where I submit ggplot2
0.8.4 to cran and then start work on ggplot 2 0.8.5. A few days later
I get an email from the CRAN maintainer saying that there's a problem
I need to fix and there's no easy way to add a fix to 0.8.4 and pull
it forward to 0.8.5

> 1. only include some changes from the master into the release and

I don't really care about this - if there was something I didn't think
would go in, I'd use a branch for it.

> 2. continue improving the release branch for point-releases after the
> initial release is made
>

>...
>
> This way, all development stays on master and other parties can just
> follow that. Making a release is picking out the pieces you want from
> the master and storing them in the release branch.

I was thinking of merging 0.8.5 back into master when it was done, and
then tagging it 0.8.5. That also avoids the problem of the master
branch having potentially broken code. Does that make sense?

Hadley

--
http://had.co.nz/

[JiHO]

On Tue, Dec 15, 2009 at 00:49, Hadley Wickham <had...@rice.edu> wrote:
> Well, actually, I'm trying to avoid the problem where I submit ggplot2
> 0.8.4 to cran and then start work on ggplot 2 0.8.5.  A few days later
> I get an email from the CRAN maintainer saying that there's a problem
> I need to fix and there's no easy way to add a fix to 0.8.4 and pull
> it forward to 0.8.5

OK, so you only want:

>> 2. continue improving the release branch for point-releases after the
>> initial release is made

right?

> I was thinking of merging 0.8.5 back into master when it was done, and
> then tagging it 0.8.5.  That also avoids the problem of the master
> branch having potentially broken code.  Does that make sense?

I see. I guess I am just more used to projects working the other way
around (even in SVN), which I think also requires less merges:
- work on master
- work on master
# release is ready
- branch 0.8.5
- tag 0.8.5.0 in the branch
- send it to CRAN
# continue development on the next release
- checkout master
- continue work
# 0.8.5 needs a fix
- checkout 0.8.5
- fix stuff
- tag 0.8.5.1 in the branch
- send that to CRAN
- checkout master
- merge fix from 0.8.5 branch
- resume normal work
etc...
The difference would be that master is potentially unstable and
release branches are (or should be) stable. This looks more natural to
me than the other way around, but that may be just me.

JiHO
---
http://maururu.net

[Hadley Wickham]

> I see. I guess I am just more used to projects working the other way
> around (even in SVN), which I think also requires less merges:
> - work on master
> - work on master
> # release is ready
> - branch 0.8.5
> - tag 0.8.5.0 in the branch
> - send it to CRAN
> # continue development on the next release
> - checkout master
> - continue work
> # 0.8.5 needs a fix
> - checkout 0.8.5
> - fix stuff
> - tag 0.8.5.1 in the branch
> - send that to CRAN
> - checkout master
> - merge fix from 0.8.5 branch
> - resume normal work
> etc...
> The difference would be that master is potentially unstable and
> release branches are (or should be) stable. This looks more natural to
> me than the other way around, but that may be just me.

Ok - that makes sense. I'll try it for ggplot2 0.9.

Hadley


--
http://had.co.nz/