Roadmap

[rgri]

I saw your post on reddit and am very happy to help with this project. I propose to use this issue to help create a roadmap for the types of tests which need to be implemented.

[rikhuijzer]

Nice to hear that you're happy to help with this project and thank you for reaching out.

To answer your question about the roadmap, I'll first give a big picture overview of the state of the project so far. The aim of the project is to make all important G*Power functionality available in the browser. This allows people to run power analyses on any desktop device (Windows, Mac, or Linux), but also even mobile devices. I just tested it on my phone and tablet and on both the calculation runs. To achieve this, the project is compiling C and Rust code to WebAssembly. Rust has great support for WebAssembly and C so that's why Rust was chosen. Another aim of this project is to be future proof. As a guideline, my aim was to have code that will still run 10 years from now. Since this project uses only Javascript, Rust, and C, I think it's reasonable to assume that these languages will live for 10 more years. At the time of writing, I think the Rust and C parts of the codebase are quite elegant, so those are fine. The Javascript side is quite verbose and not so great. For now it works, so I think it's probably best to stick to the current approach unless someone comes up with a less verbose approach that would also be able to live for 10 more years (so that means that React and most other web frameworks are out of the picture).

Then a big picture overview of the code. The code can be seen as two separate parts: a front end and a back end. For people familiar with front and back end engineering, note that both the front and back ends run in the clients computer. Nothing runs on a server. The back end contains the logic for the power analyses calculations. The back end also contains extensive tests to verify that the result of the calculation is the same as what is reported by G*Power and/or R's pwr package. These tests ensure that as long as the front end passes the right numbers to the back end, then the returned value will be correct. The front end does not do calculations, but manages the appearance of the website. It will also gather the right numbers from the input fields and pass those to the back end. Then the back end does the power analyses calculations and returns the result. Next, the front end places the result in the right position in the website.

The communication between the two happens via JSON. For example, the front end may send something like this to the back end:

{"analysis":"n","test":"deviationFromZeroMultipleRegression","n":100,"alpha":0.05,"power":0.95,"es":0.5,"nPredictors":"2"}

and then the back end returns:

{"n":64}

The "n":100 here can be ignored. It was easier in the front end to just pass all numbers. The back end will just ignore n because "analysis":"n" specifies that n should be calculated (based on alpha, power, and es). If you open the browser console via the developer tools of your browser, then you can see this communication between the front and back end happening in the logs.

Okay so finally on to what is still not implemented:

Power Analyses

Many different types of power analyses are not implemented yet. These are visible when opening the drop down menu's on the website. Many fields cannot be selected meaning they are not implemented yet.

For anyone who wants to work on it, an easy way to start is to update only the back end (Rust). Just find a test from G*Power that is not available in this project yet. Then add tests to ensure that the result here is the same as in G*Power. You can use the output parameters from G*Power and the formula's from their paper to figure out which distribution should be used with which parameters.

Plotting

G*Power allows clients to plot the power analyses. This is a required functionality for some medical use-cases from what I've heard. It could also be useful for debugging. The nicest here would be to implement the plotting in a Rust library and pass an image via the JSON to the front end (just convert to PNG and pass the raw bytes via JSON). That would give the best performance and also complexity is easier to manage in Rust code than in Javascript. Also Rust has access to the distributions so would be best suited for making the plot. If there are no good enough Rust libraries, we could fall back to some Javascript library. This would be slower and more risky in terms of being future-proof, but it could work.

Other

Some other functionality that G*Power offers would probably also be nice to have like the Determine box or the Protocol. I don't think they are super important though. Just implementing the Power Analyses and Plotting should probably be sufficient for 99% of clients.

[storopoli]

ANOVA is on the way to merge in #17.