Coder Social home page Coder Social logo

mpm-errors's People

Contributors

brucekendall avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar

mpm-errors's Issues

How should we code "not applicable"?

Rob has suggested writing "NA" in various places for "not applicable". The problem is, when R imports the data file, blanks will also be coded "NA", and we will be unable to distinguish entries that were directly assessed from those that were just left blank. This means that future updates will have to revisit these cases, in case they had been overlooked rather than actively assessed. This is particularly problematic if we do not do a comprehensive scan of the database.

I had proposed using "na" (lowercase) as the sign that the field had been assessed. However, it is awfully easy to forget; and between Excel's autofill and a likelihood that someone will rectify capitalization before finalizing the file, it is likely that some or all of them will turn into "NA" anyway. So we need something more distinct, at least as far away as "N/A", but perhaps even more distant.

Decision needed: How should we code "not applicable"?

Examples needed: Census type

We need examples illustrating how to select the census type. Ideally we will have one or more for each of:

  • Pre
  • Post
  • Post+
  • Mid
  • Flow
  • Ambiguous

Should we include retrogression?

Rob asked, in the paragraph on notation, whether we should include retrogression. Indeed, more generally, should we expand the focus from a simple dichotomy (stay in same stage vs. mature to next) to the general multitomous "decision" to move to one of a number of different stages?

The development/growth issue is relevant to two questions:

  1. Do maturing individuals reproduce on time?
  2. Does the modeled stage duration match the actual (mean) stage duration in the organisms life history?

Question 2 only applies when maturation from a stage is primarily controlled by time within stage (rather than, say, size). In animals, such stages generally follow a sequential pattern (e.g., newborn, small juvenile, large juvenile, subadult, adult; egg, larva I, larva II, pupa, adult). There might be circumstances where an individual could skip a stage, but I can't think of cases where they would retrogress. In many plant models, most classes are size-based, such that this question doesn't apply; and the developmental stages (e.g., seeds, saplings) tend not (I imagine) to have a determinate stage duration, again making this question moot. Indeed, we might want to only apply this question (the final section of the protocol) to animals.

Question 1 would apply to size-based transitions as well; the general question here is: when an individual transitions from one class to another, does it get the reproduction from the starting class or the ending class (the right answer depends on whether it's a pre- or post-breeding census)? When there is a clear transition from pre-reproductive to reproductive stages, this will be most clear, and such transitions exist for most animals. In plant models, the same rule will generally be applied throughout the matrix, but I'm not sure how to robustly identify one of them to examine. It will be clearest, I guess, in the transitions with the biggest fertility differences between classes.

So the question is, where do we balance the simplicity of the protocol against its ability to consider every possible case? Can we make the protocol more general without losing the compadrinos in a maze of notation?

Conflicts in objectives between manuscript and database improvement

For the manuscript, the goal of classifying the COM[P]ADRE models is document the frequency of errors in published MPMs. For the databases, the goal of this review is to improve the quality of the models in the database by fixing errors in the published models.

These goals are broadly aligned, but there are a couple of places where we might ask the Compadrinos to do different things depending on the goal.

  1. When a value cannot be determined from the published source, RSG suggests contacting the authors. This would get a definitive answer for the purpose of correcting the model; but for the manuscript it would be sufficient (and useful) to record that the model description was unclear.
  2. For the manuscript, the unit of observation is the study or publication, as we are documenting the practices of scientists. Also all models within the study are likely to have been constructed in similar ways. However, correcting the models in the database requires that each model within a study be documented.

Decision needed: Do we prioritize the manuscript or the database?

Coping with non-ascii characters when exporting from com[p]adre

In the early days of this project I used write.csv() to export a subset of the database and then read the csv file into Excel to add additional columns. Somewhere along the way I discovered that the database had non-ascii characters (accents, superscripts, etc.) and that these had gotten lost. I don't know whether the loss was in write.csv() or reading into Excel.

It's probably possible to preserve these on write by using an encoding option in write.table(). But I don't know if Excel will recognize these in a csv file. Perhaps a better way is to write directly to Excel (e.g., with the xlsx package); or use something other than Excel as a data input system (although since Rob already set up an Excel template that may be the default mode for the compadrinos).

Looking for appropriate treatment of continuous breeders

Right now, the CensusType variable refers to the model -- this is appropriate and needed, so that we can do subsequent analyses on the model. But there is a separate question of whether the model is appropriate to the species' life history. For seasonal breeders, any birth-pulse model is appropriate. But thinking through the lionfish paper, I realized that, while the species itself is a continuous breeder, they do not apply a birth-flow formulation, instead relying on a short timestep (1 month) to do the work for them.

So would it be possible for the compadrinos to assess the actual breeding schedule from the description of the life history? The possibilities I can think of are:

  1. Pulsed
  2. Continuous and constant
  3. Continuous but cyclically varying

For 1 and 3 we would also need to know the length of the cyclical variation (a year? 28 days? 24 hours?) or time between pulses, to compare with the timestep of the model.

In some sense, this gets beyond the original scope of the paper (although it is a potential source of inaccurate inference), and would require a theoretical treatment of birth-flow models that is probably more than I want to get into (is the treatment in Caswell the most general version out there?).

Decision needed: do we ask the compdrinos to assess actual breeding strategy?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.