6.1 KiB
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.