Git Product home page Git Product logo

safestats's People

Contributors

alexanderlynl avatar judithterschure avatar rosanneturner avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

Forkers

judithterschure

safestats's Issues

Implied target for nPlanBatch and deltaMin known

When nPlanBatch, deltaMin (and alpha) are fixed, aside from power, implied target should also be included in the safeDesign object, for the t and logrank test. Implied target: exp (E [log E-value])

Do not change user options

Please make sure that you do not change the user's options, par or working directory. If you really have to do so within functions, please ensure with an immediate call of on.exit() that the settings are reset when the function is exited

Safe test print function: add confidence intervals

For all tests where possible (@AlexanderLyNL logrank and z-test if I am correct?) confidence intervals should be printed by default in the print.safeTest function. For the logrank test, the z-based version can be printed for now, with a warning. If you have finalized the code for the z- and logrank printing could you warn me, then I will format the 2x2 design accordingly!

Unexported functions

You have examples for unexported functions which cannot run in this way. Please either add packagename::: to the function calls in the examples, omit these examples or export these functions.

Make vignettes small again

  • Currently, a safeTSim objects are saved as RData files
  • The samples (dataGroup1 and dataGroup2) are stored in safeTSim$safeSim and in safeTSim$freqSim
  • Generating these data is easy:
someData <- generateNormalData("nPlan"=c(n1Plan, n2Plan), "nSim"=nSim, "deltaTrue"=deltaTrue,
                                 "muGlobal"=muGlobal, "sigmaTrue"=sigmaTrue, "paired"=paired, "seed"=seed)
  • Make RDate files smaller

Trick:

  1. Generate data on demand in the vignette itself (fast)
  2. Provide data as argument for (simulate.safeDesign, thus, replicateTTest)
  3. Drink whisky

Return values for every function in docs

Please add \value to .Rd files regarding exported methods and explain the functions results in the documentation. (If a function does not return a value, please document that too, e.g. \value{No return value, called for side effects} or similar)

Rewrite documentation according to feedback for 2x2

  • Please always but solely write package names, software names and API names in single quotes in title and description.

  • Please add () behind all function names in the description text. e.g: --> example()

  • Please add \value to .Rd files regarding exported methods and explain the functions results in the documentation.
    (If a function does not return a value, please document that too, e.g. \value{No return value, called for side effects} or similar)

  • You have examples for unexported functions which cannot run in this way.
    Please either add packagename::: to the function calls in the examples, omit these examples or export these functions.

  • \dontrun{} should only be used if the example really cannot be executed (e.g. because of missing additional software, missing API keys, ...) by the user. That's why wrapping examples in \dontrun{} adds the comment ("# Not run:") as a warning for the user.
    Does not seem necessary.
    Please unwrap the examples if they are executable in < 5 sec, or replace \dontrun{} with \donttest{}.

  • You write information messages to the console that cannot be easily suppressed.
    It is more R like to generate objects that can be used to extract the information a user is interested in, and then print() that object.
    Instead of print()/cat() rather use message()/warning() or if(verbose)cat(..) (or maybe stop()) if you really have to write text to the console.
    (except for print() and summary() functions)
    e.g.: safe2x2Test.R, ...

  • Please make sure that you do not change the user's options, par or working directory. If you really have to do so within functions, please ensure with an immediate call of on.exit() that the settings are reset when the function is exited. e.g.:
    ...
    oldpar <- par(no.readonly = TRUE) # code line i
    on.exit(par(oldpar)) # code line i + 1
    ...
    par(mfrow=c(2,2)) # somewhere after
    ...
    e.g.: helpers, ...
    If you're not familiar with the function, please check ?on.exit. This function makes it possible to restore options before exiting a function even if the function breaks. Therefore it needs to be called immediately after the option change within a function.

nPlan, nPlanBatch and nPlanExpected

What we call "nPlan" now in the t- and z-test (I am not sure about the logrank test) should be called "nPlanBatch" and should be printed at the bottom of print.safeDesign, in a note.

For prospective designs, "nPlan" should be changed to be the nPlan under optional stopping (i.e., quantile of M simulated stopping times under an optional stopping experiment with parameters set according to the design, with nMax set to infinity).

"nPlanExpected" should be available when requested in the design function: nPlanExpected is the mean of M simulated stopping times under optional stopping, with nMax set to nPlan defined as above.

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.