OCHA-DAP / pa-anticipatory-action

Code and documentation for analytical work on OCHA Anticipatory Action pilots.
GNU General Public License v3.0
14 stars 0 forks source link

Uncertainty report #272

Closed joseepoirier closed 2 years ago

joseepoirier commented 2 years ago

@turnerm This is the doc we would submit with a formal proposal and in the final AAF. It's mock data as we discussed and it would read in the data from csv files generated through analytical scripts.

I didn't push any images. You should be able to generate them as you knit the document.

@caldwellst The CSS doesn't all work properly. Can you take a look with your fresh eyes to figure out why font color of headers aren't working, for instance?

joseepoirier commented 2 years ago

@turnerm I hadn't actually (non-draft) PRed this yet so good to have someone tinker with it more. It's unfortunately a bit hack-y at times because it is meant to be a template that applies to multiple situations fairly simply.

The values could be floats. I wouldn't go beyond 1 decimal however, would you? I also haven't tested the visuals with floats so the labels on the CI plots might get a bit crowded. A first question we should answer is whether we think it is necessary and justified to report at the decimal level, esp since they are values within a confidence interval (not means being compared in a t-test, for instance - which requires high precision)?

This is also related to my question about including data validation checks in the generation of the CSV's.

I don't get an error when knitting in a new session. What is the error you get?

turnerm commented 2 years ago

The values could be floats. I wouldn't go beyond 1 decimal however, would you? I also haven't tested the visuals with floats so the labels on the CI plots might get a bit crowded. A first question we should answer is whether we think it is necessary and justified to report at the decimal level, esp since they are values within a confidence interval (not means being compared in a t-test, for instance - which requires high precision)?

@joseepoirier Agree that we definitely shouldn't be reporting floats. I just wanted to check whether the rounding would occur here, or if the user should pre-round the values for the input csv.

joseepoirier commented 2 years ago

I originally had it in the Rmd but removed it, thinking it would be best done as part of a set of validation checks when generating the values. Happy to reconsider though: it's only a few lines of code to add if needed.

It also shouldn't be the reason you can't knit the document, in case that was your line of thought.

joseepoirier commented 2 years ago

@turnerm Ha yes. It's indicated on ln35 that the folder needs to exist. I didn't set it up to do it automatically because the repos are undergoing so many refactorings and restructuring, I didn't know if this were the path or structure we'd want. Figured it was a non-issue until we start using it and we can make a decision then.

turnerm commented 2 years ago

I didn't set it up to do it automatically because the repos are undergoing so many refactorings and restructuring, I didn't know if this were the path or structure we'd want. Figured it was a non-issue until we start using it and we can make a decision then.

Ah okay makes sense. I would argue for setting it up so at least the current version of the rmd file will run smoothly for whoever is using it; it can always be changed if we want to modify the file structure.

joseepoirier commented 2 years ago

@turnerm Per our conversation I'll merge this for now and do some refactoring later on, perhaps to reflect feedback as it comes in.