diff --git a/docs/design/stencil-scratch.md b/docs/design/stencil-scratch.md new file mode 100644 index 0000000..5009114 --- /dev/null +++ b/docs/design/stencil-scratch.md @@ -0,0 +1,130 @@ +## Notes + +The stencil registration mechanism discussed above is not currently +implemented. The current design relies on the cooperative relationship +between SMO and stimbuff libraries, where stimbuffs are expected to respect +the n-stencils limit without requiring explicit registration or validation +by SMO. +# Stencil Design: + +Right now, I think we have an attachmentSupport stencil base class, right? + +## Opaque, per-stimbuffapi? Or SMO-standardized, per-format? + +I think stencils will have to be opaque derived types of that base class, and +each stimbuff api lib will have to export its own derived stencil type, perhaps. + +Alternatively, since the output data format exposed by a stimbuff is conformant to a qualeifaceapi's expectations, maybe stencils should be decided by SMO and then used jointly between and by the stimbuffapis and the qualifaceapis. I think this is better, actually. So stencils are per-stimbuff data format-specific, and not perstimbuffapi opaque. + +## Stencils: where do they fit in, and what are they? + +Stencils are mentena. They are the result of abstraction and projection. + +When the direction of operation is from quale soup to interpretion/knowledge, +they are produced from the stimframe -- this is abstraction. +When the direction of operation is from a mathobj to the soup in order to +compare an abstract notion to the data in a stimframe, they are created by +artificing a new stencil which satisfies the properties of the mathobj whose +properties need to be compared against the stimframe soup data -- this is +projection. + +I.e: stencils are implexed mental phenomena. They are what Ayn Rand calls, +"Implicit existents", or what conventional AI researchers call "Regions of +Interest". + +## Abstraction and projection: + +Cognition is possible because the body helps the mind to perform its first +abstractions. When intrins occur, the sense organ is aware of where the intrin +is located and what its intensity is, and what ought to be done with the intrin. +The intrin can tell the mind: +* Where its attention ought to be directed (stencil of BodySpots). +* What it ought to do with the intrin (autogoal with reference values to + achieve). +* How to tell when the required operation has been satisfied (comparators + attached to the stencil). + +In this respect, yet again, it seems like the mind is not in charge of the body. +Rather, the body literally gives the mind missives to fulfill, along with +completion criteria. Nietzsche seems to be correct again: +> The body is a big sagacity, a plurality with one sense, a war and a peace, a flock and a shepherd. +> +> An instrument of thy body is also thy little sagacity, my brother, which thou callest "spirit"- a little instrument and plaything of thy big sagacity. +> +> "Ego," sayest thou, and art proud of that word. But the greater thing- in which thou art unwilling to believe- is thy body with its big sagacity; it saith not "ego," but doeth it. + +## But how ought these things be put together as an abstract data structure? + +I understand that the comparators should hold the autogoal's reference values +(which are within the stencil) as their ref operand. + +I understand that a cologex is a string of comparators, each having its own +reference operand and a var operand as the slot for whatever it will eventually +be compared against. + +### Are mentena the top-level, identity objects? Or are cologexes? + +I guess I just keep thinking that the stencil should be some kind of central +mentenon that holds all of the comparators in an array. But maybe this is wrong. +Maybe we should allow a situation where a single cologex has comparators of +different kinds, and each one may point to different mentena. It will simply +be the case that most of the time, the referent mentena for the comparators +within any given single cologex will usually be a single mentenon. But this may +not be necessary. + +``` +cologex = collection of comparators; +comparator = reference value + method for comparison; +reference value = +``` + +### What does the stimbuffapi give to the mind? + +We have two paradigms for thinking about this, and hitherto we've been thinking +about it as, the stimbuffapi gives the mind a stencil, with a comparator that +allows the mind to use that stencil to determine autogoal completion. + +Perhaps we should be thinking about it as: the stimbuffapi gives the mind a +cologex with a set of comparators, and those comparators' ref operands happen to +point at this stencil which has been filled with these values that the +stimbuffapi wants the mind to achieve. + +So: it's not that the body gives the mind a stencil. Rather: the body gives the +mind a cologex. The cologex encodes ref operands which, if the mind pursued, +would achieve the body's goals. The focus isn't on the stencil, but rather on +the comparators...nay, even more: on the cologex. + +## Cologexes as the top-level pertinence determiners for memory? + +Do we store stencils on HDD for their own sake, as ends in themselves? Or do we +store them for as long as they're attached to a comparator? + +And do we store comparators for their own sake? Or do we store them for as long +as they're instrumentally valuable for achieving an autogoal? + +It seems like cologexes are the root of the knowledge graph, and more than that: +the cologexes constructed by stimbuffapis are the root cologexes of the mind's +knowledge graph? And we can "forget" and evict mentities based on their +relationship to our cologex graph. + +## But still: what do stimbuffapis hand over to the mind in pos/negtrinCInd? + +They hand over a cologex, with a comparator, whose ref operand is a stencil, +which has been filled with reference values that are pertinent to that intrin. +* For a negtrin, the ref values in the stencil will be 0s. +* For a postrin the ref values in the stencil will be INT_MAX or something. + +### And how does the mind use this? + +The only way to answer this is to first figure out what a goal is, relative to/ +within our taxonomy of data structures and notions. Because ultimately, the +stimbuffapi is trying to give the mind a goal -- an auto-generated goal. + +What's the difference between a concept and a goal? Concepts are cologexes that +state the criteria for qualifying to be a member of that concept. We compare +data against the comparators in a cologex to deduce what that data should be +classified as. + +Goals seem to be, at the same time, cologexes, yet something more. + +We need a stencil type that encodes the intrin spots within an [light/dark]ambience stimframe. We also need comparators, but we'll deal with that after. \ No newline at end of file diff --git a/docs/design/stencils.md b/docs/design/stencils.md index cfa7378..de27e2a 100644 --- a/docs/design/stencils.md +++ b/docs/design/stencils.md @@ -1,123 +1,105 @@ -# Stencil Design: +# Stencils -Right now, I think we have an attachmentSupport stencil base class, right? +## Overview -## Opaque, per-stimbuffapi? Or SMO-standardized, per-format? +Stencils are an intrin info event data type used by SMO to efficiently +identify and process intrinsic stimuli (postrins and negtrins). Each stim +feature may have a stencil type if it's expected that devices exporting +stimbuffs for that feature can raise intrins (and even if not, because stencils +are used for projection). Stencils are derived classes +that provide sparse lists of body spots whose stim feature values have +passed the importance threshold for a particular intrin. -I think stencils will have to be opaque derived types of that base class, and -each stimbuff api lib will have to export its own derived stencil type, perhaps. +## Purpose -Alternatively, since the output data format exposed by a stimbuff is conformant to a qualeifaceapi's expectations, maybe stencils should be decided by SMO and then used jointly between and by the stimbuffapis and the qualifaceapis. I think this is better, actually. So stencils are per-stimbuff data format-specific, and not perstimbuffapi opaque. +Stencils enable SMO's mind layer to quickly "just know" where an intrin is +occurring on the body. When an intrin is raised, SMO doesn't have to first +scan its percepts to figure out where the intrin is. The stencil +descriptors tell it exactly which body spots are raising it, because the sense +organ itself conveyed that information via the stencil. -## Stencils: where do they fit in, and what are they? +This direct information also assists SMO in narrowing down the scope of its +DB searches for methods to handle (increase or decrease) the stimval. For +example, for a negtrin raised from a `negtrin(...)` segment attached to a +nontrin DAP line (e.g. `pcloudLightAmbience` / `pcloudDarkAmbience`), +we don't search DB by trying to +match all possible body spots with their stimvals. Rather, we search for +all the body spots that are described in the stencil. This optimizes DB +searches and also makes negtrin relieving/postrin satisfying searches +more explicit and obviously scoped items of knowledge. The eventual +solution is automatically classified as being a method to relieve/satisfy +intrins at this point on the body and not just hazily generally for "all +over the body". We get to make the new item of knowledge more specific. -Stencils are mentena. They are the result of abstraction and projection. +## Format and Allocation Model -When the direction of operation is from quale soup to interpretion/knowledge, -they are produced from the stimframe -- this is abstraction. -When the direction of operation is from a mathobj to the soup in order to -compare an abstract notion to the data in a stimframe, they are created by -artificing a new stencil which satisfies the properties of the mathobj whose -properties need to be compared against the stimframe soup data -- this is -projection. +Stencils' formats are specified and standardized by SMO, as well as the +number of stencils that a stimbuff may deliver at once. But the size of the +stencil allocated by a stimbuff cannot be known by the SMO layer. Only the +stimbuff itself knows how much memory is required to hold a stencil for +describing intrin events that it raises. -I.e: stencils are implexed mental phenomena. They are what Ayn Rand calls, -"Implicit existents", or what conventional AI researchers call "Regions of -Interest". +For example, only the livoxGen1 stimbuff knows the upper bound on how many +sparse descriptors are needed to describe an ambience event, for its current +configuration. Because for example, the stencil memory size is determined +by its nDgramsPerFrame parameter. -## Abstraction and projection: +So SMO must specify the format and number of stencils (for rate limiting) +per stimbuff. But the stimbuff library will determine internally the memory +size required for each stencil. This means that SMO can't pre-allocate and +loan stencils to the stimbuffs. That would be ideal because it would give +total control to SMO over intrin events -- because SMO could reject any +intrin event whose stencil's internal memory doesn't match one that it +previously loaned out. -Cognition is possible because the body helps the mind to perform its first -abstractions. When intrins occur, the sense organ is aware of where the intrin -is located and what its intensity is, and what ought to be done with the intrin. -The intrin can tell the mind: -* Where its attention ought to be directed (stencil of BodySpots). -* What it ought to do with the intrin (autogoal with reference values to - achieve). -* How to tell when the required operation has been satisfied (comparators - attached to the stencil). +We could probably still enforce this by making the stimbuffs "register" +their stencils with SMO before raising intrins. This would have the effect +of ensuring that SMO can verify that only its permitted number of stencils +have been allocated. Moreover, we also regain the ability to reject stencils +whose internal memory doesn't match the memory of a registered stencil. -In this respect, yet again, it seems like the mind is not in charge of the body. -Rather, the body literally gives the mind missives to fulfill, along with -completion criteria. Nietzsche seems to be correct again: -> The body is a big sagacity, a plurality with one sense, a war and a peace, a flock and a shepherd. -> -> An instrument of thy body is also thy little sagacity, my brother, which thou callest "spirit"- a little instrument and plaything of thy big sagacity. -> -> "Ego," sayest thou, and art proud of that word. But the greater thing- in which thou art unwilling to believe- is thy body with its big sagacity; it saith not "ego," but doeth it. +But it's fine because we don't expect the relationship between SMO and +stimbuff libraries to be inimical enough for security measures like that to +be non-negotiable. -## But how ought these things be put together as an abstract data structure? +## n-stencils Intrin-Segment Parameter -I understand that the comparators should hold the autogoal's reference values -(which are within the stencil) as their ref operand. +Where a stim buff supports it, a parameter called `n-stencils` tells the +stimbuff how many stencils it can allocate and deliver to SMO +simultaneously for **intrinsic** delivery. `n-stencils` belongs on the +`postrin(...)` / `negtrin(...)` segment it rate-limits — **not** on the +nontrin qualeIfaceApi params. Postrin and negtrin get independent +budgets. -I understand that a cologex is a string of comparators, each having its own -reference operand and a var operand as the slot for whatever it will eventually -be compared against. +The stimbuff must wait until SMO returns stencils to it via postrinEventRdy or +negtrinEventRdy before delivering new intrin events. Stimbuffs can deliver +as many intrin events as they have stencils for. When all of their stencils +have been given to SMO, they must wait until SMO returns a stencil before +raising new intrins. -### Are mentena the top-level, identity objects? Or are cologexes? - -I guess I just keep thinking that the stencil should be some kind of central -mentenon that holds all of the comparators in an array. But maybe this is wrong. -Maybe we should allow a situation where a single cologex has comparators of -different kinds, and each one may point to different mentena. It will simply -be the case that most of the time, the referent mentena for the comparators -within any given single cologex will usually be a single mentenon. But this may -not be necessary. +**Specification:** +- The parameter is specified inside a `postrin(...)` or `negtrin(...)` + segment on a DAP line +- The value is an integer representing the maximum number of stencils + that can be allocated simultaneously for that segment's intrin path +- This parameter controls rate limiting for intrin events +- Stimbuffs must respect this limit and wait for stencil returns before + allocating new ones +**Example (generic shape — names depend on device):** ``` -cologex = collection of comparators; -comparator = reference value + method for comparison; -reference value = ++idev|my-device + |negtrin(interest-pc=85|n-stencils=4)|someSensoryQuale()|someStimBuffApi() + |livoxProto1()|SERIAL ``` -### What does the stimbuffapi give to the mind? +The Livox Gen1 **`pcloudLightAmbience`** / **`pcloudDarkAmbience`** sensory +lines do **not** use `n-stencils`; each emits one `uint32` passband count +per stimframe. If Livox adds `n-stencils` for its intrinsic pipelines, it +would appear inside the `postrin(...)` / `negtrin(...)` segments attached to +the ambience line, not on the ambience qualeIfaceApi itself. -We have two paradigms for thinking about this, and hitherto we've been thinking -about it as, the stimbuffapi gives the mind a stencil, with a comparator that -allows the mind to use that stencil to determine autogoal completion. - -Perhaps we should be thinking about it as: the stimbuffapi gives the mind a -cologex with a set of comparators, and those comparators' ref operands happen to -point at this stencil which has been filled with these values that the -stimbuffapi wants the mind to achieve. - -So: it's not that the body gives the mind a stencil. Rather: the body gives the -mind a cologex. The cologex encodes ref operands which, if the mind pursued, -would achieve the body's goals. The focus isn't on the stencil, but rather on -the comparators...nay, even more: on the cologex. - -## Cologexes as the top-level pertinence determiners for memory? - -Do we store stencils on HDD for their own sake, as ends in themselves? Or do we -store them for as long as they're attached to a comparator? - -And do we store comparators for their own sake? Or do we store them for as long -as they're instrumentally valuable for achieving an autogoal? - -It seems like cologexes are the root of the knowledge graph, and more than that: -the cologexes constructed by stimbuffapis are the root cologexes of the mind's -knowledge graph? And we can "forget" and evict mentities based on their -relationship to our cologex graph. - -## But still: what do stimbuffapis hand over to the mind in pos/negtrinCInd? - -They hand over a cologex, with a comparator, whose ref operand is a stencil, -which has been filled with reference values that are pertinent to that intrin. -* For a negtrin, the ref values in the stencil will be 0s. -* For a postrin the ref values in the stencil will be INT_MAX or something. - -### And how does the mind use this? - -The only way to answer this is to first figure out what a goal is, relative to/ -within our taxonomy of data structures and notions. Because ultimately, the -stimbuffapi is trying to give the mind a goal -- an auto-generated goal. - -What's the difference between a concept and a goal? Concepts are cologexes that -state the criteria for qualifying to be a member of that concept. We compare -data against the comparators in a cologex to deduce what that data should be -classified as. - -Goals seem to be, at the same time, cologexes, yet something more. - -We need a stencil type that encodes the intrin spots within an [light/dark]ambience stimframe. We also need comparators, but we'll deal with that after. \ No newline at end of file +**Invalid (sensory qualeIfaceApi must not carry intrin-oriented params):** +``` ++idev|my-device|pcloudLightAmbience(n-stencils=4)|livoxGen1-pcloud()|livoxProto1()|3JEDK380010Z39 +```