Compact graph structure part 1 or 2

I use the term a lot.  Compact graphs was the basis for storing JSON graphs into SQLite. It means the graphs are spanning trees without loops and each graph holds a sequence count and is composed of sequence of graphs.

G is a (count,G) or (0,Null)

It means, 1) the Turing structure has no loops, a descent down the graphs leads to a fixed point. and 2) efficient memory retrieval is linear. So, algorithms which maintain the graph by deleting and adding nodes is always deleting and adding graphs and must maintain the block count.  But, the counts add and subtract, node counting algorithms needed.

What else?
The length of a compact graph is a close approximation to the Huffman weighted sum, mainly because we get a near match between the array size and number of bits required to hold the enclosed symbol set.  These concepts can lend itself to code optimization and verification by examining the code as a 'block chain'. Find the characteristics of typical 'block chains', shapes commonly found in byte codes, for example.  You have a generic'graph compare'.

Then we talked about lock structure compare when we talked bot security at the smart card foundry. The foundry is doing a graph compare, how much does the verification block structure compare with the issuance block structure, when generating hidden encryption keys.  New math, I will get a graph add, delete, link, all working for some generic node. Make it so the bot can carry a function long with as it traverses the block chain. Then I make that function the Huffman operator, and it will construct the proper graph out of a linear array of symbol nodes. Ftrom then on its a matter of trying different functions, some functions just take stats of the blockchain, whatever is held in the node value field.