dev

[DominiqueMakowski]

DO NOT MERGE THIS BRANCH cause it's like super broken, related to the reorganization with effectsize

Fix progress

• cite_packages()
• format_algorithm()
• format_model()
• report.htest() (depends on enhance n_clusters parameters#205)
• model_table.lm()
• report.data.frame()
• report_participants() (report_participant: a report-like output with tables etc. #61)
• report.bayesfactor()
• report.aov()
• report.glm()
• report.glmer()
• report.stanreg()
• report.modelbased()
• report.easycorrelation()

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@5a5f9a9). Click here to learn what that means.
The diff coverage is 58.88%.

@@           Coverage Diff           @@
##             master    #50   +/-   ##
=======================================
  Coverage          ?    45%           
=======================================
  Files             ?     29           
  Lines             ?   1382           
  Branches          ?      0           
=======================================
  Hits              ?    622           
  Misses            ?    760           
  Partials          ?      0

Impacted Files	Coverage Δ
R/format_algorithm.R	0% <ø> (ø)
R/format_model.R	92.3% <ø> (ø)
R/report_model.R	0% <0%> (ø)
R/report_model_regression.R	0% <0%> (ø)
R/report_regression.R	0% <0%> (ø)
R/report_performance.R	0% <0%> (ø)
R/report_sample.R	0% <0%> (ø)
R/model_table_regression.R	0% <0%> (ø)
R/report_parameters_regression.R	0% <0%> (ø)
R/report_intercept.R	0% <0%> (ø)
... and 17 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5a5f9a9...47953f8. Read the comment docs.

[strengejacke]

p_method and ci_method are now integrated in df_method.

[DominiqueMakowski]

Let's get this big overhaul started 💪

So, as we discussed somewhere, the first step is to get that function that would create the big table (that basically merges the parameters, effectsize and performance tables).

I started the model_table() function, but it'd probably need an improved print method (knowing that we'd likely need to keep in mind that people will want to easily convert this table output to markdown/latex/knitr::kable). So we have to make it quite flexible.

Once we have that model_table() function working for our models (which should be straightforward, as really all the work is done in parameters and performance), we can start thinking about how best convert this table to a textual output.

@strengejacke @mattansb what do you think?

[strengejacke]

Sounds good! Basically, I imagine something like these tables, but as textual output which can be easily integrated in non-HTML documents.

[DominiqueMakowski]

Yup, would it work to have different .print_report_table_* internals, such as print_report_table_console (default to console with coloured output), print_report_table_html(), print_report_table_latex() etc.?

@humanfactors

[strengejacke]

I have no idea about latex... I think we should have an idea in mind how our table looks like. Then we have a data frame that "mimics" this table (with empty "cells" where the table cells should be empty as well), and then we have functions like add_first_column() or add_header_row() or whatever, and then, it either inserts HTML, or text/markdown. But this is just a quick thought, haven't thought about it in detail yet.

[strengejacke]

https://cran.r-project.org/web/packages/tangram/vignettes/example.html
https://gist.github.com/leeper/f9cfbe6bd185763762e126a4d8d7c286
https://github.com/spgarbet/tangram

[strengejacke]

We may also think of adding "layer" (but with +, not %>%, as the latter makes no sense when we actually add something).

[mattansb]

The idea of focusing on tables first sounds good, as most of our outputs are data.frames anyway.
Might be interested to have a look at https://github.com/rstudio/gt (which I haven't used yet).

[DominiqueMakowski]

python style > R style tho 🙊

The last big step, before merging to master, is to get that flexible yet powerful report() function for regression models. The tricky part is to find the sweet spot between flexibility (having methods that can adapt based on the input) and complexity (avoid having tons of ifelses for all the possible cases). And that's quite a challenge

[strengejacke]

before merging to master

Why? Master is currently broken, while dev should be working better. Wouldn't it make sense to have the more stable branch as master?

[DominiqueMakowski]

Alright so for regressions and complex models, model_text() (which creates the textual output), will be made from the combination of subparts, such as report_model(), report_intercept() and report_parameters() etc.

It'll be simpler to maintain these smaller chunks

[strengejacke]

Sounds good. Should we merge this branch to have something working at master? We could encourage users to test this new version.

[DominiqueMakowski]

Soon soon, hopefully by tomorrow, once a basic version of report for regressions works

[DominiqueMakowski]

Not sure if I'm satisfied by the names of table_long, table_short, text_long, text_short... Opinions?

Maybe something like text_summary / text_details?

[DominiqueMakowski]

Let's merge this, cannot be more broken than it is anyway so...... 😅

[strengejacke]