todo: post v3.0 release

[dmcglinn]

code refactoring

• [ ] get_mob_stats --> 316776f introduced calc_comm_div which accomplishes some of these (get_mob_stats is obsolete`)
  • [x] output needs to be in as a tibble or data.frame for easy downstream output to export or ggplot per #242
  • [ ] make sure row ids or site ids are properly implemented in output per #199
  • [x] turn off randomization tests by default because often inappropriate
  • [x] make it work for just a community matrix input with a grouping vector rather than only on a mob_in object (see similar behavior in rarefaction)
  • [ ] issue warning if unbalanced design.
  • [ ] if coordinates are provided then do a quick extent check on each grouping factor see if they are similar issue warning if not
• [ ] make_mob_in
  • [ ] allow input data to be in long or wide format for community matrix, key assumption will be that attribute data is provided in similar way - this makes things a little tricky.
  • [ ] make sure it is clear that presence absence data is not currently supported
  • [ ] needs to accept just a vector for the plot_attr argument rather than a full data.frame see #41
• [ ] rarefaction
  • [ ] make individual based per site easier per #209
  • [ ] dens_ratio argument is difficult to understand per #238
  • [ ] consider dropping lchoose for lgamma throughout so that floating point abundances can be used per #207 this applies to case in which sampling effort is rounded (need better implementation of rejected PR #184)
  • [ ] when plotting there are currently limited colors implemented should patch per #222
• [ ] get_delta_stats
  • [ ] report proportional change in richness rather than only absolute per #165
• [ ] plot_rarefaction
  • [ ] fix issue of colors being recycled if group number is large
  • [ ] provide warning if group id for ref_level is not a viable group name.

    new functionality

• [x] add in @T-Engel 's beta diversity statistics from https://github.com/T-Engel/betaC
  • [ ] add in setwise beta comparisons https://github.com/T-Engel/betaC/blob/master/R/setwise_beta.R
• [x] calc_SPIE needed to provide a means of computing S_PIE when site has all singletons (i.e., PIE = 1 which results in a division by zero and therefore an NA value. Essentially this is the difference between using asymptotic S or observed S. Note this replaces some of the functionality of the calc_PIE function
  • [ ] write tests for calc_PIE and calc_SPIE in ./tests/testhat/ directory
• [x] spatially explicit sSBR that expresses S as a function of distance rather than number of samples collected
• [o] confidence intervals for rarefaction and diversity metrics generated via bootstrapping.
  • [x] CI for div metrics via bootstrap
  • [x] standard deviation for IBR analytical calc implemented
  • [ ] general rarefaction CI's for all rarefaction methods
• [ ] extending MoB to binary presence / absence data - which represents a change from SAD to OFD and density to fill of matrix per #89
• [ ] change get_mob_stats and get_delta_stats over to a formula specification per #239
• [ ] more complex experimental designs need to be implemented (e.g., block designs per #129).

[dmcglinn]

tagging @T-Engel, @jmchase, and @sablowes here as this reflects our meeting on 2020/10/09

[T-Engel]

I changed calc_PIE in my fork. Will write a pull request once I've added the betas. 48224b3ac62ee83ff0791209f9032f0ee593303d

[dmcglinn]

Thanks @T-Engel! I'll comment on your fork at your commit

[T-Engel]

I just created a new branch from dev for the incorporation of beta_C. (Here: 040a9bb). Now we don't depend on the betaC package. Before we merge into dev, I want to update calc_com_div(). I don't think it makes sense for beta_C to show up as the default for index=S. Can we remove it from there? Maybe it is not a bad idea to leave beta_C out of this big function. If users want to use it, they can just call beta_C directly. Otherwise, calc_comm_div needs a C_target argument, as well. Otherwise, the coverage changes every time depending on the data. What do you think, @dmcglinn ?

[dmcglinn]

Hey @jmchase @sablowes @T-Engel @FelixMay it would be good to revisit this mobr wishlist. There still seems to be some important items that would be great if we develop a plan of implementation. Also a reprioritized list would likely be really helpful. Something to think about after mobr v3.0.0 comes out here in the next few weeks.

[FelixMay]

Hi @dmcglinn, thanks for pushing this Dan. I am teaching for the next to weeks, but I am happy to talk or comment afterwards

[dmcglinn]

Sounds good thanks @FelixMay. I hope teaching goes well.