Conscious uncoupling round #1

[patrickbarks]

Updates to close #20, close #41, close #42, and make progress toward #48. Though I think we should revamp our naming scheme as described in #48, I'm not attached to any specific name/prefix, so suggestions for alternatives are encouraged.

(1.) Add functions to convert among survivorship (lx), survival (px), and mortality hazard (hx)

• lx_to_px, lx_to_hx
• px_to_lx, px_to_hx
• hx_to_lx, hx_to_px

(2.) Rename ageSpecific- fns to mpm_to_, and add to-survival and to-hazard fns

• mpm_to_lx, mpm_to_px, mpm_to_hx, mpm_to_mx

(3.) Update plotLifeCycle to close #42

• prevent alphabetical re-ordering of nodes
• quote node names to allow punctuation (the quotes won't appear in plot)
• change default title from "my life cycle" to NULL
• add stages arg for custom stage names (rather than using matrix dimnames)

(4.) Break apart lifeTimeRepEvents to close #20

• fns mature_prob, mature_age, mature_life_expect each return a single numeric value

(5.) Break apart vitalRates as described in #20

(6.) Break apart perturbation functions as described in #20

• matrixElementPerturbation -> perturb_trans
• vitalRatePerturbation -> perturb_vr
• new fn perturb_matrix returns a full sensitvity or elasticity matrix
• in all fns user now selects "sensitivity" or "elasticity" with arg type

(7.) Add functionality to distinguish between structural zeros and sampled zeros

• for all vr_ and vr_vec_ fns, and perturb_trans
• user can specify set of possible transitions with args posU/posF/posC
• default is posU = matU > 0, posF = matF > 0, etc., which effectively assumes that all zeros are structural
• vital rates or sensitivities corresponding to impossible transitions are return as NA, and/or excluded from subsequent calculation, whereas transtions that are 0 but still 'possible' (i.e. sampled zeros) are included in further caculations
• this functionality should still be added to perturb_vr, but this will be more difficult

(8.) Add functions to calculate stochastic elasticities

• based on method from Haridas et al 2009
• perturb_stochastic() calculates stochastic elasticities given a list of matA and corresponding population vectors
• pop_vectors() derives a series of population vectors via recursive projection (assuming some starting point, with various options)

[patrickbarks]

@levisc8 do you have any ideas for this build error? Looks like some builds are failing on the igraph installation, and others on stringi. Previous devel builds were failing on the installation of openssl or curl.

Part of the issue is that we've recently added a dependency on DiagrammeR, which itself has a huge chain of dependencies. They were all successfully installed in the last build of the master branch, though.

[levisc8]

I have no idea about the travis builds. stringi did just get udpated on CRAN yesterday though so maybe it's not available on all platforms yet?

The appveyor builds seem to be failing because it can't find the Fortran compiler to install igraph in some cases. I don't think we can fix that one on our end.

Is there any way to avoid the DiagrammeR dependency? Or do we have to use it for plotLifeCycle?

[patrickbarks]

Cool, thanks for checking. Ya, DiagrammeR is just used in plotLifeCycle. There are other packages for plotting graphs, like ggraph, but it has lots of dependencies too.

Do you know if there's an elegant way to make DiagrammeR a Suggest rather than Depend? Perhaps use testthat::skip_if_not_installed() for the unit tests, and modify the function to fail with a helpful message if DiagrammeR isn't installed? We do something like this for tidyverse functions in Rcompadre, though maybe that's a bit different because they're S3 methods.

I'm assuming Suggests aren't installed during the CI checks, though I'm not actually positive on that.

Edit: it seems Suggests are in fact installed for the CI checks, so this strategy wouldn't help anyway.

[levisc8]

Yea, I think you could add something like if(!requireNamespace(DiagrammeR)) stop('Please install.packages('DiagrammeR') to use this functionality') to generate a similar behavior in plotLifeCycle. This won't modify the search path, and the message should be descriptive enough.

I'm not sure how you'd do it with .onLoad. I think just putting the requireNamespace in plotLifeCycle itself is easier.

[levisc8]

^^That won’t solve the CI problem, but I don’t think we can do much about that other than wait.

…

On 14. Feb 2019, at 14:45, Patrick Barks ***@***.***> wrote: Cool, thanks for checking. Ya, DiagrammeR is just used in plotLifeCycle. There are other packages for plotting graphs, like ggraph, but it has lots of dependencies too. Do you know if there's an elegant way to make DiagrammeR a Suggest rather than Depend? Perhaps use testthat::skip_if_not_installed() for the unit tests, and modify the function to fail with a helpful message if DiagrammeR isn't installed? We do something like this for tidyverse functions in Rcompadre, though maybe that's a bit different because they're S3 methods. I'm assuming Suggests aren't installed during the CI checks, though I'm not actually positive on that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.