Caveats and Limitations for Rules

This article describes the caveats and limitations involved when applying Rules to drag-and-drop tables, R tables, and legacy "with tests" visualizations.

Performance

Rules are generally applied via looping in JavaScript, and some are designed for applying to a single row or column only. The following should, therefore, be kept in mind:

• Tables with hundreds of rows and/or columns will take longer to load as the code needs to run through each row and column every time it loads.
• Applying a rule multiple times to a table to perform a specific task on a different row or column (instead of including this within the same loop) will result in inefficient code that could cause performance issues when loading the table.
• Rules that rely on temporary tables being generated within the code may also cause slow-running tables, especially when used on a large table, a large data set, or both.

Rules on visualizations

Note: You must apply the rule directly to the input table if you see a table icon in the Data > Data Source > Data field in the object inspector of a visualization.

You will also see a warning in the Rules section of the object inspector if you have applied a rule directly to a non-compatible visualization, and you will need to apply it to the input table instead. For example:

Rules on R Tables

Many R tables in Displayr can work with rules the same way as regular, drag-and-drop tables. However, not all rules are available on R tables. Currently, rules that modify the cell colors or access the statistics Below or to the Right of a table will not work. Rules that change the order of rows/columns, which rows/columns are shown on the table, operate using the values of a table, and edit the labeling of the headers and contents of the table will work. Incompatible rules will display a warning in the Data > Rules field and in the Rule's pop-up window (if available).

Significance Testing in Rules

Some caution should be applied when customizing a table using Table JavaScript, particularly with regard to significance testing. The p-values that control the significance results that are displayed in a table using arrows, font coloring, font sizes, and column letters are determined before the table JavaScript is applied to the table. As a result, some Table JavaScript functions can have unintended consequences with regard to which cells are shown to be significant, causing cells to be highlighted incorrectly. In these cases, significance should be prevented from being displayed, and this can be done by selecting Appearance > Appearance > Significance > No in the object inspector .

One example is the addition of rows or columns to the table. Since the significance results are computed prior to the addition of these rows or columns, the new cells can have no significance results.

In general, significance results should be turned off when the Table JavaScript involves any function that:

• Changes the number of cells in the table
• Changes the value of a statistic in any of the cells
• Applying filters or weights to some cells and not others

Modifying Significance Tests via Rules

In general, we do not recommend modifying significance tests in any way other than through the table settings.  If you nevertheless wish to adjust significance results using rules, then care needs to be taken to address the following aspects:

• That the test that is to be used is actually better. That is, the automatic tests in Displayr are designed to take the following factors into account, and if overriding these tests, it is important to verify that these issues are still being addressed appropriately:
  • Multiple Comparisons (Post Hoc Testing).
  • Weights.
  • Dependence.
  • Statistical power.
  • Robustness.
  • Edge cases (e.g., variables with zero variance).
  • Numerical precision.
• That you do not inadvertently apply the modifications to the wrong data (e.g., if applying a rule to a specific table, care needs to be taken to avoid inadvertently copying that rule and applying it to other tables that have different structures).
• Avoiding inconsistencies. For example:
  • If you modify the way that tests are conducted on tables, this will not have any impact on other areas where Displayr conducts testing automatically.
  • Different implications from tests shown on the main section of the table versus those shown in the object inspector via Data > Statistics > Right and Data > Statistics > Below (which cannot, generally, be modified via rules).

See Also

How to Use Rules in Displayr