Optimum savings to loan match and Compact Graphs

Two parts.  The first part below describes the optimum s&L match, and the second is some code to organize Huffman trees into compact graph.

To understand the theory, consider a simplification. We have a loan queue and a deposit queue.  The pit boss wants to run down both queues and match S to L as best it van, making up the difference with created or destroyed money, the bit error.  In fact, this would work if all parties operated optimally in tyher sandbox.  Less than optimum matchers use less cycles and thus traders have more looks at the stack.

The optimum is to make two moving window Huffman encoders for each queue, but add in pit boss loan and deposit events to make both queues binary balanced twos bit trees.  Then you have a node by node match, the interest charges should be the path length times the aggregate ratio.

When the bit error exceeds bounds, the pit boss lengthens or shortens the Huffman window as need be.  All participants can traverse the tree, in turn or drop deposit and loan asynchronously.

How is sub optimum matching and red/gree connected?


The secure element uses the red/green indicator to warn when the pricing surface has a convcavity, and he should price around it .

This means, warn if you but two dozen eggs and forget the bacon.  If that happens, the coherence the two supply chains had altered, and you jumped, bought two dozen eggs thinking they were cheap compared to bacon.  Should have just bought the same, and watched one more time, then you price around the bend. Then find out later you only can eat half of much bacon as before.

But it is highly quantized, choices become locally limited so a sub optimum price in the pit still avoids jumping the shark.  Then you add in the buyers club effect where buyers coordinate to reduce supply chain volatility. 

A lot of options for robotic pit bosses. Keep it simple as it can then be validated.
#this tree only descends


# This class acts on a single array, GCOUNT# and
# uses only indices in an unsafe manner
class garray:
 def __init__(self): # upper is the ienclosing block
  self.top = object.__new__(node)  # The G instance cannot call nde.init
  self.top.count = 1
  self.top.return_val = APPENDED
  self.top.value=counter
  self.top.itext = "Top"
  self.g =[]
  self.g.append(self.top)
  # Move a block up the array
 def MOVE(self,dest,src,num) :
  print("Move from ",src, " to ",dest, " count ",num)
  h=[]
  h[0:num] = self.g[src:src+num] # copy the source segment
  self.g[src:src+num] = self.g[dest:dest+num] #move list down
  self.g[dest:dest+num]=h[0:num] # replace
 def DELETE(self,i,num) : pass

 def APPEND(self,n) :
  self.g.append(n)
 def GET(self,i) :
  return(self.g[i])

 # class node operates as a linked graph
 # Bot may descend from the to only
 # mehods accumulae counts toet direct indices into the array

# recursion control constants
APPENDED = 0
CONTINUE = 1
BLOCK = 2
ERROR = 3
DONE = 4
# graph operators allow variable arg list
def NullFun(n,id,x=None) : # complete recursion
 n.return_val = CONTINUE
 print("Null ",n.count,id)
 return(n.return_val )
def JustDotsFun(n,id,x=None) : # Testing recursion
 n.return_val = BLOCK
 print("Dots ",n.count,id)
 return(n.return_val )
def IsEqualFun(n,id,x) : # Stop when x=y
 if  n == x['target'] : n.return_val = DONE
 if n.count  >= x['target'].count : n.result_val = BLOCK # the target is not inthis block
 return(n.return_val)
def UpdateFun(n,id,x) : # Stop when x=y
 if  n == x['target'] :
  print("found ")
  n.return_val = DONE
 else :
  n.count = n.count + x['offset']
 return(n.return_val)


global G
counter =0 # for testing
class node :
# G is an array of  node pointers s
 #inseret node self as the first element in upper
 def __init__(self,upper=None,t=None): # upper is the ienclosing block
  global counter
  self.count = 1 # count itself
  self.return_val = APPENDED
  self.value=counter
  self.itext = t
# if no enclosure,  do not call APPEND to G, do not install
  G.APPEND(self)
  if upper != None : upper.enclose(self)
  else : G.top.count = G.top.count+1  # this just appends a the pit, the bottom
  if len(G.g) != G.top.count : print("Count error ",G.top.count,len(G.g) )
  counter = counter+1
 def delete(self,i) :  pass

 # self prepends the new block
 def enclose(self,new) : #
  i = G.top.traverse(0,UpdateFun,dict(target=self,offset=new.count,func="Update"))
  k = self.traverse(i,IsEqualFun,dict(target=new,func="IsEqual")) # locate the new block
  G.MOVE(i+1,k,new.count)
  self.count = self.count + new.count

 # descend from the top and collect G_index going down
 def traverse(self,id,fun,arglist=None) :
  end = id + self.count # warning here, a function call may alter node values
  if fun(self,id,arglist) != CONTINUE : return(end)
  id = id + 1 # skip the anchor
  while id  < end  and (self.return_val == CONTINUE) :
   id = G.GET(id).traverse(id,fun,arglist)
  if self.return_val == BLOCK : self.return_val = CONTINUE
  return(end)

global G
# Utility printouts for test
VALUE = lambda i : G.g[i].value
COUNT = lambda i : G.g[i].count
RESULT = lambda i : G.g[i].return_val
ITEXT = lambda i : G.g[i].itext
def who(a,b) :
 print(a.itext," with ",a.count,"  enclose ",b.itext," with count ",b.count," G count = ",len(G.g))
def peek() :
 print("Top count ",top.count," G count ",len(G.g))
 for i in range(len(G.g)) :
  print(i,COUNT(i),VALUE(i),RESULT(i),ITEXT(i))

# Some actual test code
G = garray()
top = G.top
top.itext='top'
oo = node(t ='Append1')
oo = node(t ='Append2')

x = node(top,'x')
y = node(x,'y')
z = node(top,'z')
k = node(z,'z')
m = node(z,'z')
#oo = node(top,t ='app',How=1)
#peek()

for i in range(10) :
 nn = node(top,str(i))
 print(nn.itext)
peek()
#top.traverse(0,NullFun,0)


We deal with ledger service congestion in the sandbox, fully three colored. The triple acconting beings deposits, loans, and fees.  The pit maintains a third stack, a queue of ledger requests going out to a queue of miners. The ledger stack is a two bit.  But in the interest swaps, trading bots might be pre-charged a bit for future use of the coin, and thus the it boss enforces the minor flow of ledger services.

Why?
The side chains ensure they trade on par, neither has hidden ledger congestion.

How?
The interest swaps look like some 3-d multiply, mainly rediagonalizing a small matrix. No problem. I define this to be unpatentable, though I could be a gazillionare, but really, we can't patent any aspect of the cash tech.

Who cares?
Smart contracts, their job with time, mass and distance is made much easier, they know arrival  distributions are bound, and the precision.  Fails to deliver become much easier for smart layer.

The trading bots have to deal with three stacks, but the pit boss keeps them normalized and isomorphic. In the process, the pit boss will be keeping a reserve for ledger fees. The promise to the side chain community is to keep a ledger queue going up to the precision specified. But the precision of two or three bits, a requantizing fee structure, discounted for the account significance.  This reduces the 'par uncertainty' down to the trade book uncertainty of reading the queues, in round robin.  Thus all the sidechains have fair knowledge and are subject to risk if a side chain fails.

Advantage to the user

Your cash card does not have to trade the third color, set that on standard. Now the user always suffers the typical fee relative to the significance of the trade. If you are pinching pennies, no problem, your penny pinching will accumulate in the pit and when its big enough to suffer  small ledger fee, it has already happened. Greatly reduce probability of bank runs.

No comments: