Docs: Stencil notes
This commit is contained in:
@@ -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 = <stencil|mathobj|3dobj>
|
||||
```
|
||||
|
||||
### 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.
|
||||
+85
-103
@@ -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 = <stencil|mathobj|3dobj>
|
||||
+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.
|
||||
**Invalid (sensory qualeIfaceApi must not carry intrin-oriented params):**
|
||||
```
|
||||
+idev|my-device|pcloudLightAmbience(n-stencils=4)|livoxGen1-pcloud()|livoxProto1()|3JEDK380010Z39
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user