Chapter 17 causact: Quick Inference With Generative DAGs

17.2.1 Step 1: Add a node to represent your data

The following code uses the descr and label arguments of the dag_node() function to, respectively, provide a long label for your random variable that is easily understood by business stakeholders and a short label that is more for notational/mathematical convenience:

dag_create() %>%  # just get one node to show
  dag_node(descr = "Store Data", label = "x") %>%
  dag_render()

Since, we actually observe this node as data, we use the data argument of the dag_node() function to specify the observed values ⊕The observed values will more often be in a column of a data frame, but giving a vector of actual values also works.:

dag_create() %>%  # make it an observed node
  dag_node(descr = "Store Data", label = "x", 
           data = c(1,1,0)) %>%  ##add data
  dag_render()

The node’s darker fill is automated because of the supplied observed data and the [3] means there are three observed realizations in the supplied data vector. You could also use a plate to represent the multiple realizations, but I recommend plate creation to be the last step in creating generative DAGs via the causact package.

17.2.2 Step 2: Represent the distribution governing how the observed data is generated

One goal we often have is to take a sample of data and find plausible parameters within a distribution family (e.g. normal, gamma, etc.) governing how that data might have been generated - at its core, Bayesian inference is a search for plausible parameters of a specified generative DAG. To specify the distribution family governing the observed data, use the rhs argument of the dag_node() function ⊕rhs stands for right-hand side. The rhs of a node is reserved for indicating how the node is generated as a function of its parent nodes’ values. Alternatively, when not used as a distribution specification, the rhs is an algebraic expression or other function of data converting parent node values into a realization of the node’s value. There is an implicit assumption that all unknown variables will eventually be defined by parent nodes - the causact package will not check for this. In the case below, we are specifying a parameter theta that will need to eventually be added as a parent node.

Hint: Use CTRL+SPACE or CMD+SPACE to access the auto-complete functionality when looking to add the rhs and data arguments.

dag_create() %>%  # specify data generating distribution
  dag_node(descr = "Store Data", label = "x", 
           rhs = bernoulli(theta),  ##add distribution 
           data = c(1,1,0)) %>%
  dag_render()

Note, a random variable’s distribution must be part of greta. The full list of greta distributions can be found by running the following line:

?greta::distributions

17.2.3 Step 3: Add a node for every argument on the rhs

For each unknown argument remaining on the rhs of any nodes in your causact graph, one must eventually ⊕All unknown rhs arguments for nodes must be defined prior to running any Bayesain computations. define how the unknown argument can be generated. In our data node above, the only unknown argument on the rhs is theta. We define the generative model for theta by making an additional node representing its value:

dag_create() %>%  
  dag_node(descr = "Store Data", 
           label = "x",
           rhs = bernoulli(theta), # no quotation marks
           data = c(1,1,0)) %>%
  dag_node(descr = "Success Probability", 
           label = "theta",  # labels needs quotes
           rhs = uniform(0,1)) %>%
  dag_render()

Notice, the parameters of the rhs distribution for theta are not unknown - they are actually constants (i.e. 0 and 1) and hence, no additional parent nodes are required to be created. Take note that theta on the rhs for the Store Data node does not require quotes as it refers to an R object; specifically, this refers to the R object created by:

dag_node(descr = "Success Probability", 
         label = "theta",  # label needs quotes
         rhs = uniform(0,1))

where the theta object is given its name by the label = "theta" argument; ⊕The only case for when the label argument is not within quotes will be when the label name itself is stored in a pre-existing R-object. when creating node labels via this argument, quotes are typically required.

17.2.4 Step 4: Link the parent to child

Without a link betwen theta and x, one is not creating a properly factorizable directed acyclic graph as is required for specifying a joint distribution (see the Graphical Models chapter). ⊕When using the child argument, please ensure the child was previously defined as a node. Generative DAGs are designed to be built from bottom-to-top reflecting the way a business analyst would create these DAGs. Note that computer code for Bayesian inference, like greta code, requires the exact opposite order - parent nodes get defined prior to their children. One way the causact package accelerates the BAW is by facilitating a bottom-up workflow that can be automatically transalated to top-down computer code. Using the child argument of dag_node, one can now create the required link between theta as a parent node and theta as an argument to the distribution of its child node x:

dag_create() %>%  # connect parent to child
  dag_node(descr = "Store Data", label = "x",
           rhs = bernoulli(theta),
           data = c(1,1,0)) %>%
  dag_node(descr = "Success Probability", label = "theta",
           rhs = uniform(0,1),
           child = "x") %>%  ## ADDED LINE TO CREATE EDGE
  dag_render()

For more complicated modelling, repeat this process of adding parent nodes until there are no uncertain parameters on the right hand side of the top nodes.

17.4.1 dag_plate()

Our business narrative calls for the probability to change based on car model. The dag_plate() function can then be called upon to create a generative DAG where theta will vary based on car model. A major difference in the use of greta and causact is that the causact package shifts the burden of index creation to the computer. A plate signifies that the random variables inside of it should be repeated; thus, any oval inside a plate is indexed behind the scenes and effectively, a repeat instance is created for each member of the plate. The system automatically adds the index to the model using the plate label for indexing notation. When using dag_plate() the following arguments prove most useful:

⊕Remember, you can use ?dag_foo, e.g. ?dag_plate, to get descriptions for all available function arguments from the help system.

• descr - a character string representing a longer more descriptive label for the cluster/plate.
• label - a short character string to use as an index label when generating code.
• data - a vector representing the categorical data whose unique values become the plate index. When using with addDataNode = TRUE, ensure this vector represents observations of a variable whose unique values can be coerced to a factor. Omit this argument and causact assumes that node replication is based on observations of any observed nodes within the plate.
• nodeLabels - a character vector of node labels or descriptions to include in the list of nodes that get repeated one time per index value. Labels must be defined already within the specification of the causact_graph_.
• addDataNode - a logical value. When addDataNode = TRUE, the code adds a node of observed data, in addition to the plate, based on the supplied data argument value. This node is used to extract the proper index when any of the nodes in the plate are fed to children nodes. Verify the graphical model using dag_render() to ensure correct behavior.

Figure 17.6 shows how we can change the generative DAG to accomodate the story of Signup Probability being different for drivers of different cars.

### Now vary your modelling of theta by car model
### we use the plate notation to say
### "create a copy of theta for each unique car model
graph = dag_create() %>%
  dag_node("Get Card","x",
           rhs = bernoulli(theta),
           data = carModelDF$getCard) %>%
  dag_node(descr = "Signup Probability",
           label = "theta",
           rhs = uniform(0,1),
           child = "x") %>%
  dag_plate(descr = "Car Model", 
            label = "y",  
            data = carModelDF$carModel, #plate labels  
            nodeLabels = "theta",  # node on plate
            addDataNode = TRUE)  # create obs. node
graph %>% dag_render()

⊕Take time to play with plates before moving on. The generative DAG in Figure 17.6 added one additional function call, dag_plate(). That addition resulted in both the creation of the plate, and also the additional node representing Car Model observations. Each of the 1,000 observed customers of the Car Model node were driving one of 4 unique car models of the Car Model plate. The indexing of theta by y, i.e. the theta[y] on the rhs of the Get Card node extracts one of the 4 \(\theta\)-values to used to spawn each observation of \(x\).

⊕Expert tip: Observed-discrete random variables, like car model, are best modelled via plates. Do not rush to add nodes or indexes for these random variables. Let dag_plate() do the work for you.

Now, when we get the posterior distribution from our greta code, we get a representative sample of four \(\theta\) values instead of one.

## get representative sample
drawsDF = graph %>% dag_greta(warmup = 400) 

Visualizing the posterior using the below code yields Figure 17.7.

drawsDF %>% dagp_plot()

Figure 17.7: Posterior distribution for theta based on car model.

Notice, the index names for the four theta values are automatically generated as abbreviated versions of the unique labels found in carModelDF$carModel.

Digesting Figure 17.7, there are a couple of things to draw attention to. First, interval widths are different for the different theta values. For example, the probability interval for the Toyota Corolla is more narrow than the interval for the other cars. This is simply because there is more data regarding Toyota Corolla drivers than the other vehicles. With more data, we get more confident in our estimate. Here is a quick way to see the distribution of car models across our observations:

carModelDF %>%
  group_by(carModel) %>%
  summarize(numOfObservations = n())

## # A tibble: 4 x 2
##   carModel       numOfObservations
##   <chr>                      <int>
## 1 Jeep Wrangler                193
## 2 Kia Forte                     86
## 3 Subaru Outback               145
## 4 Toyota Corolla               576

Second, notice the overlapping beliefs regarding the true sign-up probability for drivers of the Toyota Corolla and Kia Forte. Based on this, a reasonable query might be what is the probability that theta_KiaForte > theta_ToytCrll? As usual, we use an indicator function on the posterior draws to answer the question. This time though, we look at the representative sample of two random variables and recognize each row of the posterior is a realization of the joint probability distribution. So, to answer “what is the probability that theta_KiaForte > theta_ToytCrll?” ⊕Note: this type of query can only be answered by relying on Bayesian inference, we compute:

drawsDF %>%
  mutate(indicatorFunction = 
           ifelse(theta_KiaForte > theta_ToytCrll,
                  1,0)) %>%
  summarize(pctOfDraws = mean(indicatorFunction))

## # A tibble: 1 x 1
##   pctOfDraws
##        <dbl>
## 1      0.761

⊕Note: You can shorten this code indicatorFunction = ifelse(theta_KiaForte > theta_ToytCrll,1,0) to just indicatorFunction = theta_KiaForte > theta_ToytCrll. The logical comparison outputs the ones and zeroes automatically. We will stick with the longer, but more-easily-readable code.

And using this ability to make probabalistic statements, one might say "there is an approximately 76% chance that Kia Forte drivers are more likely than Toyota Corolla drivers to sign up for the credit card.