Comments (23)
I agree - I like this option:
model %>%
report() %>%
to_table()
Also, something you may want to consider is a printing of the "skimmed" overview of the data, e.g., skimr::skim(data)
. I like skimming more than summarizing, especially in an increasingly tidy world. Just a thought to consider.
from report.
@humanfactors Funnily enough, this version is actually the one currently implemented 😅
from report.
Another possible workflow could be:
report() : print long text
report() %>% as.table() : print complete table
report() %>% summary() : print short text
repot () %>% summary() %>% as.table() : print consise table
from report.
This is great for internal R stuff, but perhaps we could include an additional option to print pretty tables using existing packages, e.g.,
report(..., html = TRUE) {
if (HTML = TRUE){
knitr::kable()
} else as.table()
}
from report.
bump - maybe someone wants to give feedback on the current API: https://easystats.github.io/report ?
from report.
In either case, you should probably add some more content to https://easystats.github.io/report/reference/text_long.html, you know initial submissions are checked thoroughly...
from report.
Maybe summary
with full
(default FALSE
) and table
(default FALSE
)? So summary(x, full = FALSE, table = FALSE)
is like to_text(x)
, etc...?
from report.
in psycho I had more or less the triggers to different outputs as argument... But I don't know, I got somewhat tired of it... I feel like it's clearer and nicer to have:
model %>%
report() %>%
to_table(
than
model %>%
report() %>%
summary(table = TRUE)
Altho we could still create aliases for such behaviour
from report.
Also to consider
model %>%
report() %>%
to_table(full = T)
A bit of a blend of the idea above.
from report.
until parameters is CRAN ready (which hopefully should be soon)
How extensive do you plan the support for different model-objects? It would be great to have all the functions available for as many models as supported by insight as possible...
If so, I think there's quite some work to do.
from report.
How extensive do you plan the support for different model-objects? It would be great to have all the functions available for as many models as supported by insight as possible...
I see it as a two step sequence: first we finalize the API until we are happy with the functions, their output and how things work. Once we know what we want, we simply add the methods for all the remaining functions.
I am relatively satisfied with the current model_parameters
, so guys do not hesitate to explore, test it and provide any improvements, feedback and thoughts.
from report.
Note to myself, add table
and details
method so we have the following API:
report
object with the following methods:
to_text
=print
= default outputto_fulltext
=details
to_table
=summary
to_fulltable
=table
=as.data.frame
to_values
=as.list
Both to_text
and to_table
can also be used to output detailed forms with the full = TRUE
argument, that could be renamed to details = TRUE
(?)
from report.
I really like both these options below
report() %>% as.table() : print complete table
report() %>% summary() : print short text
I think report () %>% summary() %>% as.table() : print concise table
is incredibly non-intuitive though, and don't really like that at all to be honest. It isn't clear how summarized text would pipe into a shorter table. I kind of understand the logic in traditional notation, but I think easystats users would get confused by that.
Instead, perhaps even summary(verbose=T)
and as.table(full = T)
?
I also feel that, perhaps controversially, report
in isolation should print a table and a complete text? This would make much more sense to me and provide a nice comprehensive front end.
from report.
@pdwaggoner this is interesting, because this is what I was experimenting with today (for purpose of Rmarkdown output). I wasn't sure if it would be a "big issue" to add knitr
as a dep though? Moving forward, if we want to have easy HTML and Rmd compatible table outputs, I have a feeling it might be required.
from report.
I think API decision has been made (at least for now, revisions/changes still be possible), so we can close this?
from report.
yes please, I still have a taste of uncertainty for some reasons ^^ (maybe because I had sooo much back and forth in my mind that i don't know what's good and what's not anymore 😞)
from report.
Only thought: might want to avoid as.table()
since it doesn't return an R class-table 🤷♂️
from report.
I copy my comment here, since it also relates to the API discussion:
The general idea is:
report()
create a generic, comprehensive reportreport_*()
creates more specific reports- `text_()* creates text output from the generic report
That's quite compact and intuitive. Thus, in my understanding, text_*()
should never do something directly with objects like regression models, but work on report-objects. So I would say, report_statistics()
for #86 makes sense, like we havereport_parameters()
etc.
from report.
alright makes sense so table_()
and text_()
would barely be extractors to shape reports objects in a given way. Maybe having as_table()
, as_text()
and as_plot()
(once we find a way to hook it up with see
) would be more intuitive? Though then the problems is that we break the conventions for more specific methods like as_text_short()
we would have to go either with as_text(report, short=True)
or with summary(as_text(report))
from report.
Which leads me back again thinking that maybe we should remove the text_short
and text_long
accessors in favour of a text -> summary
workflow?
fort short text:
model %>%
report() %>%
as_text() %>%
summary()
which would be equivalent to: (because as_text()
is "the default" output of report)
model %>%
report() %>%
summary()
fort "summary"/short table:
model %>%
report() %>%
as_table() %>%
summary()
It's a bit more verbose (it adds one step), but it feels more "R"-like and more flexible no?
from report.
from report.
Well, we have the strange situation here that summary()
would make sense from a technical point of view, it extracts a summary from an object. However, report objects are actually already summaries, so does it make sense to get a summary of an summary?
I mean, we can have both for now, and let's see what turns out to be feeling more natural, and then make a final decision later.
from report.
Following #96 (comment), sometimes its
#' r
#' summary(r)
#' as.data.frame(r)
#' summary(as.data.frame(r))
And sometimes
#' text_long(r)
#' text_short(r)
#' table_long(r)
#' table_short(r)
I see what you mean by "reports are already summaries" and while it's true on an essential level, I don't think it prevents from using summary()
on report objects in the API ^^
Basically I think it boils down to whether we want to favour the usage of base R methods, our own new methods or a mix thereof (e.g., summary(as_text(r))
)... I really have no preference... I'd say that using our own methods would allow more flexibility (i.e., more specific documentation, arguments etc.), but base R functions could feel more intuitive and lower the usage burden.
As you said, we can keep both APIs "working" but I think we need to pick one just for consistency in the examples etc.
from report.
Related Issues (20)
- Report text duplicated many times for brms model using in a tidymodels workflow
- Fix failing snapshots1: `report.htest-chi2` HOT 3
- Fix failing snapshots2: `report.brms`
- problems using group_by with cor.test report HOT 1
- ANOVA report missing 2nd degrees of freedom
- Missing citation for Allie Brosh's "All the Things" image HOT 2
- [Feature request] Support output of `test_predictions` from `ggeffects` HOT 3
- Can not report models/objects derived from function in pysch package
- Fix contrast errors coming from a customization that only the report website template is using HOT 2
- My hub
- t.test sign interpretation HOT 1
- Gender vs Sex mismatch in report_participants HOT 1
- Test failing on CRAN HOT 1
- Change how unspecified `...` arguments are passed to other functions HOT 1
- Fix all new failing checks HOT 1
- Fix `check-test-warnings` workflow: "Global state has changed" in `test-report.brmsfit` HOT 2
- report.loo_compare docs example broken HOT 3
- report() assigning effect size to intercept in model HOT 4
- report() not outputting denominator degrees of freedom HOT 3
- Fail to compute report for Kruskal test in some cases HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from report.