From 2abca951e79aec62d920f8e92bba5fe1666447af Mon Sep 17 00:00:00 2001 From: Alan Bernstein Date: Fri, 11 May 2018 14:52:35 -0500 Subject: [PATCH] Minor formatting fixes --- docs/data-model.md | 2 +- docs/examples.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/data-model.md b/docs/data-model.md index 4c7192676..315d05a65 100644 --- a/docs/data-model.md +++ b/docs/data-model.md @@ -87,7 +87,7 @@ This is one major component of Pilosa's ability to combine relationships from mu #### Ranked -Ranked Frames maintain a sorted cache of column counts by Row ID (yielding the top rows by columns with a bit set in each). This cache facilitates the TopN query. The cache size defaults to 50,000 and can be set at Frame creation. +Ranked Frames maintain a sorted cache of column counts by Row ID (yielding the top rows by columns with a bit set in each). This cache facilitates the TopN query. The cache size defaults to 50,000 and can be set at Frame creation. ![ranked frame diagram](/img/docs/frame-ranked.svg) *Ranked frame diagram* diff --git a/docs/examples.md b/docs/examples.md index 42476ab57..35b9d94af 100644 --- a/docs/examples.md +++ b/docs/examples.md @@ -65,13 +65,13 @@ Each column that we want to use must be mapped to a combination of frames and ro ##### 0 columns → 1 frame -cab_type: contains one row for each type of cab. Each column, representing one ride, has a bit set in exactly one row of this frame. The mapping is a simple enumeration, for example yellow=0, green=1, etc. The values of the bits in this frame are determined by the source of the data. That is, we're importing data from several disparate sources: NYC yellow taxi cabs, NYC green taxi cabs, and Uber cars. For each source, the single row to be set in the cab_type frame is constant. +**cab_type**: contains one row for each type of cab. Each column, representing one ride, has a bit set in exactly one row of this frame. The mapping is a simple enumeration, for example yellow=0, green=1, etc. The values of the bits in this frame are determined by the source of the data. That is, we're importing data from several disparate sources: NYC yellow taxi cabs, NYC green taxi cabs, and Uber cars. For each source, the single row to be set in the cab_type frame is constant. ##### 1 column → 1 frame The following three frames are mapped in a simple direct way from single columns of the original data. -dist_miles: each row represents rides of a certain distance. The mapping is simple: as an example, row 1 represents rides with a distance in the interval [0.5, 1.5]. That is, we round the floating point value of distance to an integer, and use that as the row ID directly. Generally, the mapping from a floating point value to a row ID could be arbitrary. The rounding mapping is concise to implement, which simplifies importing and analysis. As an added bonus, it's human-readable. We'll see this pattern used several times. +**dist_miles:** each row represents rides of a certain distance. The mapping is simple: as an example, row 1 represents rides with a distance in the interval [0.5, 1.5]. That is, we round the floating point value of distance to an integer, and use that as the row ID directly. Generally, the mapping from a floating point value to a row ID could be arbitrary. The rounding mapping is concise to implement, which simplifies importing and analysis. As an added bonus, it's human-readable. We'll see this pattern used several times. In PDK parlance, we define a Mapper, which is simply a function that returns integer row IDs. PDK has a number of predefined mappers that can be described with a few parameters. One of these is LinearFloatMapper, which applies a linear function to the input, and casts it to an integer, so the rounding is handled implicitly. In code: ```go