---
title: "Pruning and Sorting Tables"
author: "Gabriel Becker and Adrian Waddell"
date: "`r Sys.Date()`"
output: rmarkdown::html_vignette
vignette: >
  %\VignetteIndexEntry{Pruning and Sorting Tables}
  %\VignetteEncoding{UTF-8}
  %\VignetteEngine{knitr::rmarkdown}
editor_options: 
  chunk_output_type: console
---

```{r, echo=FALSE}
knitr::opts_chunk$set(comment = "")
```

```{css, echo=FALSE}
.reveal .r code {
    white-space: pre;
}
```
## Introduction

Often we want to filter or reorder subsections of a table in ways that take into account the table structure. For example

- sorting subtables corresponding to factor levels so that most commonly observed levels occur first in the table
- Removing subtables which represent 0 observations or which after other filtering contain 0 rows

```{r, messages=FALSE}
library(rtables)
library(dplyr)
```


## A Table In Need of Attention


```{r}
rawtable <- basic_table() %>%
    split_cols_by("ARM") %>%
    split_cols_by("SEX") %>%
    split_rows_by("RACE") %>%
    summarize_row_groups() %>%
    split_rows_by("STRATA1") %>%
    summarize_row_groups() %>%
    analyze("AGE") %>%
    build_table(DM)
rawtable
```

## Trimming

### Rows

Trimming represents a convenience wrapper around simple, direct subsetting of the rows of a `TableTree`.

We use the `trim_rows()` function and pass it our table and a critera function. All rows where the criteria function returns `TRUE` will be removed, all others will be retained. 

**NOTE**: each row is kept or removed completely independently, with no awareness of the surrounding structure. This means, for example, that a subtree could have all its analysis rows removed and not be removed itself. For structure-aware filtering of a table, we will use *pruning* described in the next section.

A *trimming function* accepts a `TableRow` object and returns `TRUE` if the row should be removed.

The default trimming function removes rows that have no values in them that have all `NA` values or all `0` values (but not if there is a mix)
```{r}
trim_rows(rawtable)
```

### Trimming Columns

There are currently no special utilities for trimming columns but we can remove the empty columns with fairly straightforward column subsetting:

```{r}
coltrimmed <- rawtable[,col_counts(rawtable) > 0]
head(coltrimmed)
```


## Pruning

Pruning is similar in outcome to trimming, but more powerful and more complex, as it takes structure into account. 

Pruning is applied recursively, in that at each structural unit (subtable, row) it both applies the pruning function at that level and to all it's children (up to a user-specifiable maximum depth).

The default pruning funciton, for example, determines if a subtree is empty by

a. Removing all children which contain a single content row which contains all zeros or all `NA`s
b. Removing rows which contain either all zeros or all `NA`s
c. Removing the full subtree if no unpruned children remain

```{r}
pruned <- prune_table(coltrimmed)
pruned
```

We can also use the `low_obs_pruner` pruning function constructor to create a pruning function which removes subtrees with content summaries whose first entries for each column sum or average to below a specified number. (In the default summaries the first entry per column is the count).

```{r}
pruned2 <- prune_table(coltrimmed, low_obs_pruner(10, "mean"))
pruned2
```

Note that because the pruning is being applied recursively, only the `ASIAN` subtree remains because even though the full `BLACK OR AFRICAN AMERICAN` subtree encompassed enough observations, the strata within it did not. We can take care of this by setting the `stop_depth` for pruning to `1`.


```{r}
pruned3 <- prune_table(coltrimmed, low_obs_pruner(10, "sum"), stop_depth = 1)
pruned3
```

We can also see that pruning to a lower number of observations, say, to a total of `16`, with no `stop_depth` removes some but not all of the strata from our third race (`WHITE`)

```{r}
pruned4 <- prune_table(coltrimmed, low_obs_pruner(16, "sum"))
pruned4
```



## Sorting

Sorting an rtable is done **at a path** and recursively, meaning a sort opreation will occur at a particular location within the table, and the subtables( children) will both be reordered themselves and potentially have their own children reordered as well.

This is done by giving a *score function* which accepts a subtree or TableRow and returns a single numeric value. Within the context currently being sorted, the subtrees are then reordered by the value of the score function.

Another difference between pruning and sorting is that sorting occurs at particular places in the table, as defined by a path. The path can contain "*" to indicate that at that portion of the structure sorting should occur **separately** within branch of the path.

Sort the strata by observation counts within just the `ASIAN` subtable:
```{r}
sort_at_path(pruned, path = c("RACE", "ASIAN", "STRATA1"), scorefun = cont_n_allcols)
```


Sort the ethnicities by observations, increasing

```{r}
ethsort <- sort_at_path(pruned, path = c("RACE"), scorefun = cont_n_allcols, decreasing = FALSE)
ethsort
```

Within each ethnicity separately, sort the strata by number of females in arm c (ie column position `5`)

```{r}
sort_at_path(pruned, path = c("RACE", "*", "STRATA1"), cont_n_onecol(5))

```

### Sorting Within an Analysis Subtable

When sorting within an analysis subtable (e.g., the subtable generated when your analysis function generates more than one row per group of data), the name of that subtable (generally the name of the variable being analyzed) must appear in the path, _**even if the variable label is not displayed when the table is printed**_


```{r}
silly_afun = function(x) {
    in_rows(a = rcell(2),
            b = rcell(3),
            c = rcell(1))
}



sillytbl <- basic_table() %>% split_rows_by("cyl") %>%
    analyze("mpg", silly_afun) %>%
    build_table(mtcars)
sillytbl
```


The path required to sort the rows inside our "analysis" of `mpg`, then is `c("cyl", "*", "mpg")`:

```{r}
scorefun <- function(tt) { mean(unlist(row_values(tt)))}
sort_at_path(sillytbl, c("cyl", "*", "mpg"), scorefun)
```

# Writing Custom Pruning Criteria and Scoring Functions

Pruning criteria and scoring functions map TableTree or TableRow objects to a boolean value (for pruning criteria) or a sortable scalar value (scoring functions). To do this we currently need to interact with the structure of the objects in more than usual.

## Useful Functions and Accessors

`content_table` Retrieves a `TableTree` object's content table (which contains its summary rows).

`tree_children` Retrieves a `TableTree` object's children (either subtables, rows or possibly a mix thereof, though that should not happen in practice)

`row_values` Retrieves a `TableRow` object's values in the form of a list of length `ncol(tt)`

`vapply(row_values(tt), '[[', i=1, numeric(1))` will retrieve the first element from each cell provided `tt` is a TableRow (and the first element is a numeric value).

`obj_name` Retrieves the name of an object. Note this can differ from the label that is displayed (if any is) when printing. This will match the element in the path.

`obj_label` Retrieves the display label of an object. Note this can differ from the name that appears in the path.

## Example Custom Scoring Functions

### Sort by a character "score"

In this case, for convenience/simplicity, we use the name of the table element but any logic which returns a single string could be used here.

We sort the ethnicities by alphabetical order (in practice undoing our previous sorting by ethnicity above).

```{r}
silly_name_scorer = function(tt) {
    nm = obj_name(tt)
    print(nm)
    nm
}

sort_at_path(ethsort, "RACE", silly_name_scorer)
```

**NOTE** generally this would be more appropriately done using the reorder_split_levels function within the layout rather than as a sort postprocessing step, but other character scorers may or may not not map as easily to layouting directives.


### Sort by the Percent Difference in counts between genders in Arm C

We need the F and M percents, only for Arm C (ie columns 5 and 6), differenced.


We will sort _**the strata within each ethnicity**_ by the percent difference in counts between males and females in arm C. This is not statistically meaningful at all, and is fact a terrible idea because it reorders the strata seemingly (but not) at random within each race, but illustrates the various things we need to do inside custom sorting functions. 


```{r}
silly_gender_diffcount = function(tt) {
    ctable = content_table(tt) ## get summary table at this location
    crow = tree_children(ctable)[[1]] ## get first row in summary table
    vals = row_values(crow)
    ## we need to have a better api for specificying location in column space but currently we don't
    mcount = vals[[6]][1]
    fcount = vals[[5]][1]
    (mcount - fcount)/fcount
}

sort_at_path(pruned, c("RACE", "*", "STRATA1"), silly_gender_diffcount)
```
