Preview.

Formal write up moving along. Of the following.

We've mentioned several primitives needed to make robust systems that enable dropping in smart methods as needed without much rewriting.

A third primitive we'll need is the ability to spawn processes the following way.

Let's say: s = 4. — Then G(s) does the following.
Then we want to create and call 4 mailboxes that will know each other's "locations"; and each one:
(i) begins by generating and sending an O message and an X message,
(ii) to random other mailboxes including possibly itself,
(iii) and each message has a state: marked or unmarked,
(iv) if unmarked, the mailbox marks it and randomly passes it on inside the system,
(v) if marked, it reads to message and:
(vi) if O, generates another two such messages and sending them out in the system,
(vii) if X, stops reading messages, but can still mark and pass messages.
(viii) if a stopped mailbox receives a marked O message, it "eats" it, and the same with an "X" message.
(viiii) if O is received, a counter is advanced, this either flips switch, a threshold (like in a neural net),
or just advances a count, and eventually the system halts with some "coarse" states (which switch flipped), and "fine" states (precise count). Fine state can select initial methods attempted for problems, say, based on load.
This will be used for various things.
For example: to spread load, make such that < 5 seconds everything settles, generate good biased randoms however correlated with system activity (s is a statistic of something), to allow the same system to be doing two different computations at different levels of granularity, which are loosely correlated, only as much as we like, but basically don't interfere, and some are neural net like, while others declarative or logical computing like (pick a method and try to get output that satisfies goals, either they run out and system halts or methods run out and system halts, making as much progress as possible, but safely). Some things: (i) Messages are labeled with a name of the "location" of the intended mailbox; (ii) mailboxes read heaps or buffer or stacks of messages periodically, (iii) and they take the messages that are "meant for them". Don't communicate directly. (iv) If somehow a message is received at the wrong mailbox, it knows it. It must scrape the label first to read it. That packaging reveals it's wrong, and it would put it back into the heap. Some resistance to bugs and more general unexpected behaviors. (Which are inevitable in complex systems.) So this uses the other primitives of MARK and SCRAPE. The dual of SCRAPE (x_5) = 5 is COSCRAPE (x_5) = x, by the way. And for MARK, of course, it's UNMARK.

Thinking about probability model we can calculate quickly without using a CAS.

It's probably going to be of the form guess and check with a gradient to climb. (A machine can check an integer calculation very quickly, more easily than solving anything.) With a condition approached that, if met, gives an estimate equivalent to a probability measure. Meanwhile the condition will depend on a sample. Also quick. For example the test will involve multiple systems performing their operation, and seeing how long it takes. The single number guessed should satisfy the same equation taking each of those results as a parameter, basically.