Closed MarHai closed 1 year ago
Really like this idea! The implementation would be closely linked to #24, so we may want to decide here first. I'll also think more about potential visualizations.
Also making a mental note here that visualize()
is one of the generics implemented by the generics
package, so we should use this as well.
Just skimmed the ppts of our master students. They also learn how to interpret residual plots to check for homoscedasticity, so we might want to add this to regress() for upwards compatibility. + qq-plots or pp-plots.
See here:
See #32
Updates:
crosstab(..., percentages = T/F)
(i.e., no additional switch)
Given the change to returning tibble-resolvable objects (rather than just tibbles), we could implement
visualize()
generic functions that allow to visualize wherever it makes sense. Here are some suggestions:describe(): horizontal box plot
describe_cat(): horizontal stacked bar chart & unstacked (via argument)
tab_frequencies(): 1 var: histogram, 2 var: facet_wrap, 3 var: facet_grid, 4 var: warning()
crosstab(): horizontal stacked bar chart depending on absolutes / relative freq
t_test(): points with 95% ci as pointrange/points with error lines
unianova(): points with 95% ci as pointrange/points with error lines
correlate(): scatter without line
to_correlation_matrix(): corrgram
add_index(): -
get_reliability(): -
test_icr(): -
regress(): scatter + lm, qq plot (, which = ..., default ist ergebnis, also scatter/linie)
plot
save object to make further enhancements (e.g., coord_flip())
I would expect the produced plots to always represent ggplot visualizations (no
plot()
visualizations). Also, we could consider returning the object just as passed in (for chaining consistency) and just output the plots. This way, we could also output multiple plots, as could be the case for thevisualization.regress
.Thoughts?