[WIP] Port phaseR to ggplot graphics

[tomicapretto]

Opening PR to track changes and discussion about porting current plots to ggplot2.

Do not review changed files because they're changing in the immediate future.

[tomicapretto]

Commit 1e0876ffec99fcaffbeb75f72d7f48692e521fe0 added two functions flowField2() and nullclines2(). The names aren't definite, I just didn't want to delete the original versions because these functions might be modified in the near future.

Now, you can do something like this:

library(magrittr)

func = function(t, state, parameters) {
  with(as.list(c(t, state, parameters)), {
    dx = a * x ** 2 + b * y ** 2 + c
    dy = d * x + e * y
    list(c(dx, dy))
  })
}
parameters = c(a = 1 , b = 1, c = -4, d = -2, e = 1)

flowField2(
  deriv = func,
  xlim = c(-3, 3),
  ylim = c(-3, 3),
  parameters = parameters,
  system = "two.dim") %>%
nullclines2(
  deriv = func, xlim = c(-3, 3), ylim = c(-3, 3),
  parameters = parameters, system = "two.dim", points = 400,
  add.legend = TRUE
)

And the output will be

These two functions also allow you to return the data.frames that are consumed by ggplot2. Instead of letting flowField2() and nullclines2() generate the plot for you, you take the data.frames and generate your own custom plot via ggplot2 (or via base graphics if you want)

Some questions that arise...

• Do we want pipeable functions?
  • If we do. Shouldn't we allow a more concise way of expressing deriv, parameters, etc. etc.?
  • This implies major refactor of the code... not sure if there are people with time to do this.
• How much does CRAN bother with backwards compatibility? I tried not to modify interface to functions, but there are definitely some changes that break it.
• Creating ggplot2 geoms_* and stats_* instead of this very high level functions?
  • I think this is the cleanest idea but I don't know if it is feasible (We don't have a tidy data.frame to be plotted, the data.frame is generated within functions like flowField() and nullclines() for example.)

Well, those are some thoughts after the commit. The one that concerns me the most is the first, which is something I'd like to address during the next one or two weeks

[mjg211]

Great work Tomas! Some thoughts on your points:

• My intuition is this could be done in a way that doesn't require too much of a rewrite, and that it would be a good idea. If there was an additional 'launch' function that sets up an object with the variables that never change (deriv etc.), that could always be the first run function that's then subsequently passed along ? The launch function would be the only one that's not pipeable. Does that make sense?
• I would consider this a major update to the package, so I wouldn't worry about backwards compatibility. I will also archive the current version in a few places and can add a section to the vignette on changes.
• I agree this might be the cleanest idea; I think shelve this for now though as it would be a lot of work.