demo D301
A grid that is the analysis of another grid
One grid holds the trading days and four more are computed from them: which figures move together, the same coefficients as a square, how one figure has behaved over the period, and how this set of stores compares with a separate one
source: { mode: 'derived', statistics: { fn } }
The grid at the top holds the trading days. The four panels under it are not loaded from anywhere: they are computed from those same rows and follow them, so filtering the days rewrites the analysis in front of you.
One grid is the data, the next one is the analysis of it
Most dashboards answer an analytical question by sending it somewhere else. The table on screen is one query, the correlation behind it is another, and the two agree only for as long as nobody touches a filter. The moment someone narrows to one store, the numbers underneath are answering a question about a set that is no longer on screen.
Here the analysis is a grid, and its rows are computed from the grid above it. Narrow the trading days to one store and every panel recomputes over exactly what is left, because the panels read that grid rather than a copy of its data. There is no second query, nothing to keep in step and nothing to invalidate.
That means the analysis behaves like the rest of your screen. It sorts, it exports, it can be charted, it can drive a tile, and it can be the source of a further panel. Ranking the pairs of figures that move together is an ordinary sort on an ordinary grid, which is why one row per pair is the shape it arrives in.
The three questions it answers
Which figures move together. One row per pair of columns, each carrying how closely the two track each other and how many days the figure covered. The same coefficients also come as the square that a heat map wants, from the same declaration.
How one figure has behaved. One row per measure of the period: where it started and finished, what it changed by, how much it moved about, its worst drawdown and when that ran from and to. A summary of the series rather than a value per day.
How this set compares with a separate one. One row per figure compared, biggest gap first, reading a second grid that shares no key with the first and was never merged into it. Both sides stay live, so an edit or a filter on either one moves the comparison.
Every row carries how many rows it saw. A coefficient that leaves the grid, into an export or a chart, leaves its context behind, and the same number over eleven rows and eleven thousand are two very different claims.
What it costs, and how to keep it cheap
Analysis of this kind is recomputed, not patched. When something in the trading days changes, each panel works its answer out again from scratch, and the readout under the grid is this page timing itself: press a button or start the feed and it reports how long the four panels took to catch up over the days on screen.
Two things follow, and both are worth knowing before you point one at a fast feed. Reading which figures move together scans the rows once for every pair, so the cost climbs with the square of how many columns you ask about: four columns is six pairs, but twenty columns is a hundred and ninety. Ask about the figures you actually mean. And panels add up rather than sharing: every panel reading one grid recomputes on the same change, so the bill is the sum of them, not the largest.
The control for that ships with it. By default a burst of changes is gathered into a single recomputation on the next frame; you can also debounce it by a number of milliseconds, or take over entirely and recompute when it suits you.
How do I make a grid that computes statistics from another grid?
Give a grid a derived source and a statistics block instead of a grouping pipeline: source: { mode: 'derived', from: otherGrid, follow: 'filtered', statistics: { fn: 'correlation', columns: [...] } }. Use fn: 'correlation' for one row per pair of columns, adding orient: 'matrix' for the square instead; fn: 'series' with of and by for one row per measure of how a column has behaved over an ordering; and fn: 'datasetVsDataset' with with: peerGrid for one row per compared column against a second grid. It replaces the pipeline rather than joining it, so sort, filter or limit the derived grid itself, or chain another panel from it. Set refresh to a number of milliseconds or to manual to control how often an expensive analysis runs over a live feed. Single-column figures need none of this: an ordinary derived select already reduces by median, standard deviation and every other measure the totals row offers.