change report methods names? about report

[pdwaggoner]

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.

[DominiqueMakowski]

@humanfactors Funnily enough, this version is actually the one currently implemented 😅

[DominiqueMakowski]

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

[pdwaggoner]

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()
}

[strengejacke]

bump - maybe someone wants to give feedback on the current API: https://easystats.github.io/report ?

[strengejacke]

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...

[mattansb]

Maybe summary with full (default FALSE) and table (default FALSE)? So summary(x, full = FALSE, table = FALSE) is like to_text(x), etc...?

[DominiqueMakowski]

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

[humanfactors]

Also to consider

model %>%
  report() %>%
  to_table(full = T)

A bit of a blend of the idea above.

[strengejacke]

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.

[DominiqueMakowski]

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.

[DominiqueMakowski]

Note to myself, add table and details method so we have the following API:

report object with the following methods:

• to_text = print = default output
• to_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 (?)

[humanfactors]

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.

[humanfactors]

@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.

[strengejacke]

I think API decision has been made (at least for now, revisions/changes still be possible), so we can close this?

[DominiqueMakowski]

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 😞)

[mattansb]

Only thought: might want to avoid as.table() since it doesn't return an R class-table 🤷‍♂️

[strengejacke]

I copy my comment here, since it also relates to the API discussion:

The general idea is:

• report() create a generic, comprehensive report
• report_*() 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.

[DominiqueMakowski]

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))

[DominiqueMakowski]

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?

[DominiqueMakowski]

[strengejacke]

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.

[DominiqueMakowski]

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.