Liking cljdoc? Tell your friends :D

vaelii.impl.quality

Four readings about the knowledge, where the rest of the instrumentation reads the engine: which rules never fire, how skewed the predicate extents are, how deep the rule graph's chains reach, and how much of the taxonomy is connected to anything.

settle-stats and chain-stats answer how the engine ran. These answer whether the knowledge is any good, which is the question the author of a large KB has and the one nothing else here asks. None of it is a gate: a threshold on somebody's ontology is not a build failure, and lein perf gates the engine while this reports on the content.

Every reading comes off state that already exists, and nothing new is indexed. A rule -> firings index would be a second copy of the JTMS adjacency to keep in step, which is the failure class the taxonomy's single :support map exists to avoid. So the cost is O(terms + rules + firings + genl edges) and never O(sentexes) — the vocabulary, which on a KB of a million facts about a hundred individuals is a hundred-odd names:

  • One walk over the term roster, and one is the number: the functor names come off it by filter, and the type-shaped names come off those rather than off the roster a second time. Measured at 8x the terms for 8x the cost, so the walk is the term the formula above leads with.
  • Three O(1) index reads per functor name — the stored extent off the count-aware trie, and the rule postings both ways. That is everything the extent and chain readings need, and it is where the rule handles come from, so the record store is read only for the handful of rules the report actually lists.
  • The firing census reads each rule's own :consequences adjacency, the candidate set jtms/restrength-informant* uses, and never scans the justification map. At 11.5M justifications that difference is the report existing or not.
  • The chain depth condenses strongly-connected components first. A KB's rule graph is cyclic in the ordinary case — (genl ?a ?b) & (genl ?b ?c) => (genl ?a ?c) alone makes it so — so memoizing a path re-explores the reachable subgraph along every one of them. Memoize the component.

Every count is of what is stored. A believed extent is O(n) per predicate (vaelii.core/count-with-functor says why), which would turn an O(predicates) report into an O(sentexes) one — and stored-vs-believed is exactly the distinction an author wants to see rather than have chosen for them. The firing census is the one reading that consults belief, because "fired and every conclusion defeated" is a category and not a rounding error.

Four readings about the **knowledge**, where the rest of the instrumentation reads the
engine: which rules never fire, how skewed the predicate extents are, how deep the rule
graph's chains reach, and how much of the taxonomy is connected to anything.

`settle-stats` and `chain-stats` answer *how the engine ran*.  These answer *whether the
knowledge is any good*, which is the question the author of a large KB has and the one
nothing else here asks.  None of it is a gate: a threshold on somebody's ontology is not
a build failure, and `lein perf` gates the engine while this reports on the content.

**Every reading comes off state that already exists, and nothing new is indexed.**  A
`rule -> firings` index would be a second copy of the JTMS adjacency to keep in step,
which is the failure class the taxonomy's single `:support` map exists to avoid.  So the
cost is
`O(terms + rules + firings + genl edges)` and never `O(sentexes)` — the **vocabulary**,
which on a KB of a million facts about a hundred individuals is a hundred-odd names:

- **One walk over the term roster**, and one is the number: the functor names come off it
  by filter, and the type-shaped names come off *those* rather than off the roster a
  second time.  Measured at 8x the terms for 8x the cost, so the walk is the term the
  formula above leads with.
- **Three O(1) index reads per functor name** — the stored extent off the count-aware
  trie, and the rule postings *both* ways.  That is everything the extent and chain
  readings need, and it is where the rule handles come from, so the record store is read
  only for the handful of rules the report actually lists.
- **The firing census reads each rule's own `:consequences` adjacency**, the candidate
  set `jtms/restrength-informant*` uses, and never scans the justification map.  At
  11.5M justifications that difference is the report existing or not.
- **The chain depth condenses strongly-connected components first.**  A KB's rule graph
  is cyclic in the ordinary case — `(genl ?a ?b) & (genl ?b ?c) => (genl ?a ?c)` alone
  makes it so — so memoizing a *path* re-explores the reachable subgraph along every one
  of them.  Memoize the component.

Every count is of what is **stored**.  A believed extent is O(n) per predicate
(`vaelii.core/count-with-functor` says why), which would turn an O(predicates) report
into an O(sentexes) one — and stored-vs-believed is exactly the distinction an author
wants to see rather than have chosen for them.  The firing census is the one reading that
consults belief, because "fired and every conclusion defeated" is a category and not a
rounding error.
raw docstring

censusclj

(census kb {:keys [limit on-progress]})

The four readings as one map — {:rules … :extents … :chains … :taxonomy …}. vaelii.core/kb-quality is the door and documents the options.

The four readings as one map — `{:rules … :extents … :chains … :taxonomy …}`.
`vaelii.core/kb-quality` is the door and documents the options.
sourceraw docstring

default-limitclj

How many rules and how many heavy predicates the report lists before it says it truncated. A cap rather than the whole set because the counts are the headline and a 30,000-entry list is not one; :limit raises it.

How many rules and how many heavy predicates the report lists before it says it
truncated.  A cap rather than the whole set because the *counts* are the headline and a
30,000-entry list is not one; `:limit` raises it.
sourceraw docstring

reportclj

(report {:keys [rules extents chains taxonomy] :as quality})

The census map as Markdown — the four readings in the order an author reads them, the counts first and the lists after. A map that is not a census answer is refused (:not-a-report) rather than rendered as a page of zeros, which is what a caller passing the wrong map would otherwise be handed and believe.

The `census` map as Markdown — the four readings in the order an author reads them,
the counts first and the lists after.  A map that is not a `census` answer is refused
(`:not-a-report`) rather than rendered as a page of zeros, which is what a caller passing
the wrong map would otherwise be handed and believe.
sourceraw docstring

cljdoc builds & hosts documentation for Clojure/Script libraries

Keyboard shortcuts
Ctrl+kJump to recent docs
Move to previous article
Move to next article
Ctrl+/Jump to the search field
× close