Table calculations enable you to easily create on-the-fly metrics, which are similar to formulas found in spreadsheet tools like Excel. These columns will show up as green in the data table, rather than as blue (dimensions), or orange (measures).

Table calculations can perform mathematical, logical (true/false), lexical (text-based), and date-based calculations on the dimensions, measures, and other table calculations in your query. The formulas that you use to execute these calculations are called Looker Expressions.

# Table Calculations are Different From Regular Fields

Although table calculations are similar to the regular fields in Looker, there are some important differences:

- Table calculations give anyone the ability to create new fields, as opposed to regular fields, which require that you have development privileges and understand LookML.
- Table calculations operate on the results from your query, as opposed to regular fields, which are part of the query itself. In other words, you’ll select a set of dimensions and measures and run your report as normal,
*then*you can base table calculations on the data in that report. **Although table calculations are easier to create than regular fields, they are not as easily controlled as regular fields.**Since they can be created by anyone within your organization, they might not be the “official” calculations. Keep this tradeoff in mind as you decide between regular fields and table calculations, since one key advantage of Looker is having a single source of truth!

# Using Table Calculations

## Creating Table Calculations in Looker

First, please make sure that all the fields you want to use in the table calculation have been selected from the field picker, and that you have run the query.

On the Explore page, the dark **Data** bar has a **Calculations** button:

This will bring up a **Table Calculations** pop-up where you can start constructing your custom metrics. The expression you create can evaluate to a number, date, string (text), or boolean (true/false).

If you already have some table calculations defined, click the **Add Table Calculation** button to create another. You are able to add as many table calculations as you need.

Then, for each table calculation:

- Rename your table calculation if desired.
- Optionally, click
**Default Formatting**to choose a predefined format or create a custom format for the results. If you create a custom format, use Excel-style formatting as described in this Discourse article. Start typing a Looker Expression into the large text box to form your calculation. Looker expressions can be quite simple, or they can use as many fields, functions and operators as your business logic requires.

The next docs page, Creating Looker Expressions, explains how to create Looker Expressions and how the editor helps you.

- If you are finished adding table calculations, click
**Save Table Calculations**.

## Sorting Table Calculations

To sort on a table calculation, click the field name at the top of the column, just as you would a dimension or measure.

#### When Table Calculations Cannot be Sorted

Sorting on a table calculation works similarly to sorting on a dimension or measure in Looker. However, there are two important differences that prevent sorting in some scenarios:

- Table calculations are created after the data is retrieved from your database, which means that when you sort a table calculation, you can only sort the data that is already displayed.
- Some table calculations are applied to multiple rows within the same column (for example, when using an
`offset()`

function). In these cases, sorting the table calculation would change its results, and is therefore disabled.

The specific scenarios when you can’t sort a table calculation are:

- Calculations that hit a row limit, as described below.
- Sorting a dimension or measure after you’ve already sorted by a table calculation, as described below.
- Sorting a table calculation that makes use of an offset, as described below.

**Calculations that Hit a Row Limit**

If the number of rows in your query exceed the row limit that you’ve set, you will not be able to sort table calculations. This is because table calculations are only based on the rows that are displayed. Therefore, if you hit a row limit, the table calculation might be missing some rows that it should be sorting into your results. If you run into this issue, you can try increasing your row limit (up to 5,000 rows).

For example, the table below displays the top ten box office movies in 2015, according to their average weekend revenue. Notice that the 10 row limit has been reached, which you’re warned about by the yellow bar displayed at the top of the table:

However, if we want to show the top 10 movies by total revenue instead, you can see the results change (for example, *Cinderella* is new to the list):

If you had tried to use table calculations to do this, they wouldn’t have searched through the undisplayed data, and would not have known that *Cinderella* existed.

**Sorting a Dimension or Measure After Sorting a Table Calculation**

As indicated above, table calculations are only based on the rows that are displayed. In contrast, sorting by a dimension measure goes back to your database to make sure it finds the correct rows. As a result, you should start sorting with dimensions and measures. Then, when the correct data has been returned from your database, you can sort those results based on a table calculation.

**Calculations Using An Offset Function Cannot be Sorted**

Any table calculation that makes use of an offset cannot be sorted, because the sort order of the rows would change the results of the offset.

For example, below is a table calculation that displays the percent change in weekend revenue for the film *Mad Max: Fury Road*:

This of course only makes sense if the results are sorted by the weekend.

## Using Table Calculations in Visualizations

Just like regular dimensions and measures, table calculations are automatically displayed in visualizations. However, table calculations also allow you to decide which rows of your data should be displayed in a visualization.

The example we’ll use to explore this feature is shown below, and includes revenue information about the movie *Titanic*. Note that the underlying data table includes the dimension **Movie Weekend Revenue Weekend Date**, the measure **Movie Weekend Revenue Average Amount**, and a table calculation called **Percent of Previous Weekend Revenue** that compares the revenue of each weekend against the previous weekend:

We can now hide certain rows of data from showing up in the column chart. To do so, you’ll create a table calculation that evaluates to true or false, then hide the false values (which will appear as “no”s in your data table). You don’t want the formula to result in the *word* “true” or “false”, rather it should be a condition that is either true or false.

For example, suppose we only want to show weeks that had greater revenue than the previous week. We could create a table calculation called **Percent of Previous Weekend Revenue** like this:

Then we could create a table calculation called **Exceeds Previous Weekend Revenue** like this:

This will result in a table that looks like this:

To hide all of the rows where a particular weekend did not exceed the revenue of the previous weekend, click the gear icon at the top left of the logical calculation and select **Hide No’s from Visualization**:

The resulting visualization will now display only the weekends that exceeded the previous weekend:

One common use case for this feature is hiding the first or last row from a visualization, since many types of analysis create bad rows at the beginning or end of a table. For example, when you are calculating running totals, have a partial day ending a date analysis, or are calculating a percent of the previous row like this example:

To get rid of that row, simply create a new table calculation to filter out this null value:

Then, hide the row as normal:

# Common Problems and Pitfalls

- All the fields you use in your table calculations MUST be a part of your initial query.
- Formulas must be in lowercase.
`ROUND`

will not work, but`round`

will. - Table calculations will only operate over rows that are returned in your query. If there is a 500 row limit, the 501st row will not be considered.

# Conclusion

Table calculations provide a powerful way for any user of Looker to manipulate and analyze their data, without having to create new LookML fields. Next, you’re ready to go deeper into using Looker Expressions in table calculations and custom filters.