There are number of areas where Crunch needs to represent an object as belonging to one of many categories. The simplest and most common example of this is the categories of a categorical variable. For a categorical variable, the values of the variable can be one of a limited set of categories and those categories are specified in the Crunch API as metadata about the variable. These categoricals are similar to R’s factors but are richer because Crunch categoricals can have any number of missing values (compared to just NA for factors), as well as a numeric representation that is separate from the category ids (which is useful for things like income bins, where you might put the middle of the bin as the value).
Moving beyond just categorical variables, we have a need to be able to represent a number of different properties, transformations, etc. in a category-like way. One concrete example is used heavily in order to add subtotals and headings to representations of categorical variables. In order to do this, we have two families of S4 classes: AbstractCategory and AbstractCategories Although subtotals and headings was the initial motivation for the new classes, they will allow for other types of representations and manipulations in the future.
The core classes that all other classes inherit from are AbstractCategory and AbstractCategories. The first, AbstractCategory, is designed to represent a single category, which might have a number of properties about it (what those are will be explained in more detail below). The second, AbstractCategories is designed to hold more than one AbstractCategory together to form a coherent group. As a simple, example: an AbstractCategories for binned income could have 5 AbstractCategorys: <$25,000, $25,000-$49,999, $50,000-$99,999, $100,000-$199,999, >$200,000. This could be represented in R as:
income <- AbstractCategories(AbstractCategory(name = "<$25,000"),
AbstractCategory(name = "$25,000-$49,999"),
AbstractCategory(name = "$50,000-$99,999"),
AbstractCategory(name = "$100,000-$199,999"),
AbstractCategory(name = ">$200,000"))An alternate (and less typing) way to instantiate this same AbstractCategories is to send lists, and the constructor takes care of calling the AbstractCategory class on each (as below). Each of the child-classes of AbstractCategories (described in the sections below) have their own mapping of plural container to singular entity constructor in the same way, so passing Categories a list will result in a Categories object full of Category objects.
income <- AbstractCategories(list(name = "<$25,000"),
list(name = "$25,000-$49,999"),
list(name = "$50,000-$99,999"),
list(name = "$100,000-$199,999"),
list(name = ">$200,000"))Finally, there’s a data argument, if you already have a list of AbstractCategorys (or simply named lists!) you want to pass in (the same thing could also be accomplished with do.call):
income_list <- list(list(name = "<$25,000"),
list(name = "$25,000-$49,999"),
list(name = "$50,000-$99,999"),
list(name = "$100,000-$199,999"),
list(name = ">$200,000"))
income <- AbstractCategories(data=income_list)Any methods that are defined for the abstract classes will function on the subclasses as well. Child classes might have special over-ride methods defined for them, but for the most part, if a method can be used on AbstractCategories or AbstractCategory it can be used on the child classes as well.
AbstractCategories inherits from list and AbstractCategory inherits from namedList so many of the same methods will be work with both of them. This includes using [, [[, [<-, and [[<- to get and set subsets of AbstractCategories and $, and [[ to get the properties in an AbstractCategory.
lapply has also been defined for AbstractCategories for easily iterating over all members. modifyCats also allows for modifying one AbstractCategories object by updating with new information from a second AbstractCategories object in the same way that modifyList works, but crucially it does not recurse into the AbstractCategory objects themselves.
Finally, there are a few custom methods that return the values of the properties as either a vector of that property for each member (when using the plural versions against AbstractCategories) or a vector (typically of length one) for a single member (when using the singular versions against AbstractCategory).
names returns the names associated with each AbstractCategory in an AbstractCategories object. And name returns the names associated with an AbstractCategory object. ids and id patterns the exact same way.
Categories from a categorical variable are represented by the Categories and Category classes. They inherit directly from AbstractCategories and Category respectively. For these, each Category must have a name and an id, they optionally can have a numeric_value, missing, and selected property.
values and value return the numeric_values property from Categories or a single Category respectively.is.na and is.na returns the missing property from Categories or a single Category respectively.is.selected and is.selected returns the selected property from Categories or a single Category respectively.Insertions allow users to insert new categories into a variable or a CrunchCube for display purposes. This is useful when the user would like to show things like aggregates (e.g. subtotals) without manipulating the underlying data (or creating a new variable). Insertions are defined as part of the Crunch API (see the Transforms section below for an explanation about where Insertions live). The Insertions class is designed to mirror the Crunch API for insertions as closely as possible. Insertions and Insertion inherit directly from AbstractCategories and Category respectively.
Insertions must have a name and an anchor. The name is just like Category names, and is used as the label to display. The anchor is the id of the category after which the insertion should be placed.
Since insertions can represent a number of different aggregations, they also can have function and args properties. The function property is a character describing the aggregation to use (e.g. "subtotal") and the args property is a vector of the category ids to use as operands for the function.
The Insertion class has two child classes: Subtotal and Heading. The Insertions class can contain anything that inherits from Insertion. Therefor an Insertions object might include Insertions, Subtotals, and Headings.
anchors and anchor return the anchor property from Insertions or a single Insertion respectively.funcs and func return the function property from Insertions or a single Insertion respectively.arguments returns the args property from a single Insertion.Subtotals and headings are both types of insertions. Because of this Subtotal and Heading classes inherit from Insertion rather than directly from AbstractCategory. These classes are designed to hold known types of Insertions to make it easier to work with Insertions (for example: testing which insertion to style in what way when using prettyPrint functions). Additionally, these classes have slightly more user-friendly names (e.g. after instead of anchor), and they accept either ids or names to refer to specific Categorys.
A Subtotal must have name, after, and categories properties. name is the same as other abstract categories. after is similar to anchor but can be either a category id or a category name after which the subtotal should be placed. categories is either the category ids or a category names to subtotal.
The same as Insertion, however some have customizations: * func always returns the string "subtotal" (because by definition a Subtotal object is an Insertion with function="subtotal") * anchor and arguments both have an option var_categories which is required if the Subtotal is using category names instead of ids in the after or categories properties. Supplying the categories is required in order to translate from category names to ids which are required to be a well-formed Insertion.
A Heading must have name and after properties. Both of which have the same interpretation as Subtotal above.
The same as Subtotal for anchor. func and arguments return NA
As a concrete example, let’s take the following categories:
feeling_cats <- Categories(
list(name = "Very Happy", id = 1),
list(name = "Somewhat Happy", id = 2),
list(name = "Neither Happy nor Unhappy", id = 3),
list(name = "Somewhat Unhappy", id = 4),
list(name = "Very Unhappy", id = 5)
)
feeling_cats## id name value missing
## 1 1 Very Happy NA FALSE
## 2 2 Somewhat Happy NA FALSE
## 3 3 Neither Happy nor Unhappy NA FALSE
## 4 4 Somewhat Unhappy NA FALSE
## 5 5 Very Unhappy NA FALSEAnd make some subtotals and headings to use as insertions:
feeling_subtotals <- Insertions(
Heading(name = "How I feel about cheese", position = "top"),
Subtotal(name = "Generally Happy", after = "Somewhat Happy",
categories = c("Very Happy", "Somewhat Happy")),
Subtotal(name = "Generally Unhappy", after = 5,
categories = c(4, 5))
)Notice that the “Generally Happy” subtotal is made specifying category names for after and categories:
## [1] "Somewhat Happy"## [1] "Very Happy" "Somewhat Happy"Where as the “Generally Unhappy” subtotal uses ids:
## [1] 5## [1] 4 5Since the Crunch API does not have a distinction between Subtotals Headings, and other Insertions, we sometimes need to convert from Subtotals or Headings to Insertions. This is accomplished with the method makeInsertion(). This method takes a Subtotal or Heading and returns a valid Insertion. If the Subtotal or Heading has category name references instead of ids, then you must include a Categories object as the var_categories argument. In general, this is only needed before sending a heterogeneous set of Insertions to the Crunch API.
Using the examples we used before, we can see how this works:
feeling_insertions <- Insertions(data = lapply(feeling_subtotals, makeInsertion, var_categories = feeling_cats))Now, all of the Subtotals and Heading from feeling_subtotals are proper Insertions:
## [1] "Insertion" "Insertion" "Insertion"This means that the after property has been translated into anchor, and the function and args properties have been filled in appropriately:
## [1] 5## [1] "subtotal"## [1] 4 5Because Insertions are required to use category ids only, the new all-Insertions feeling_insertions has translated the “Generally Happy” subtotal’s category names to ids:
## [1] 2## [1] 1 2Since the Crunch API does not have a distinction between Subtotals Headings, and other Insertions when we get data about Insertions from the API, we need to change the classes for the Insertions that the crunch package knows about. To do this, we can use either subtypeInsertions to change the types of all of the members of an Insertions object, or subtypeInsertion to change the type of a single Insertion object.
These functions work by inspecting the Insertion and determining if it can be identified as one of the known child classes of Insertion (namely: Subtotal or Heading).
Using the same example above, we can convert back from all Insertions to the subtypes:
feeling_subtotals_again <- subtypeInsertions(feeling_insertions)
sapply(feeling_subtotals_again, class)## [1] "Heading" "Subtotal" "Subtotal"There are two sets of inheritance: one for containers and one for members: Classes inherit from those immediately to their left
| top-level classes | 1st children | 2nd children | |
|---|---|---|---|
| containers | AnstractCategories |
Categories |
|
AnstractCategories |
Insertions |
||
| members | AbstractCategory |
Category |
|
AbstractCategory |
Insertion |
Subtotal |
|
AbstractCategory |
Insertion |
Heading |
The Transforms class and set of functions is not an abstract category at all, but rather it mirrors the Crunch API’s set of transformations that are allowed on a variable or CrunchCube. One of the possible transformations are insertions (which is where Insertions are stored). Currently the crunch package doesn’t support other transformations.