Python history

In late 1994, a select group of programmers from across the US met to discuss their new secret weapon.  Barry Warsaw was one of the 20 or so developers present at that first-ever workshop for the newly-created Python programming language and recalls the palpable excitement among those early users. "I can remember one person in particular who said, 'You cannot tell anybody that I'm here because our use of Python is a competitive advantage.' It was their secret weapon, right?"

Years ago, on this blog, I was using Python as a prototype pit interface, where the iterator function let the trading bot skip through the bets in structured order, very fast.   But I tired of programming

Python has an interpreter, and that is a key point of compliance with the spectre protections. If the python kernel is protected, then that protection can be extended into the iterator, and we can just sell cycles in the iterator function. Still a great idea, and Python has become some what of a default trading language.

I still like Default. It wasn't a language so much as a grammar that resulted from dispersing all the sub functions out onto the general API interface.  So the shunt API is there, anyway; needed for stacks. The console already supported a variety of re-entrants, all compatible with universal interface.  And all applets used the same high speed symbol tables.  So Default was just the command syntax would could use, fully nested, when the standard set of applet was on the bus. Since you had a multi-purpose shunt for managing stacks,  one got a free stack language.  And the console was designed to swap syntaxes as needed. Oh, yes, Hardly. That was my stack language. I meant, I hardly did anything, the sub functions already on the bus.

Structured queues in the iterator.

That is the format of the boards. They are the Huffman maps from the last time pit boss squared the bets. One per color. The traders are generally using double entry, running bets on opposing queues. Except the central banker accounts where trader triple entry account to cover the variable tax on the Constitution. We can do all that with python traders and high speed compute on the back end. That was my deal, organizing trees for the fastest look up and the slowest writes. That made the pir boss function slow and sluggish, and I left the tech looking at the run time Huffman encoder, one that could migrate the previous tree to the net tree adiabatically. That  operation should exists, identified when some bids exceed the bit error bound, causing a requant.

The two sequences, two color, are slightly ill sampled, one is voer complete, the other under. The pit boss, in its market function, is descending both trees, in parallel, from top down and inserting its 'chits' to keep the combined tree, the scale version, minimal.  It should always reach a point where the error bound is exceeded, the the rebalance is from that node down, iteratively, meaning a continued correction seems to be a converging outcome. Our equivalent to Newton's grammar. But, that means, by construction, an iterative Huffman encoder should exist and be observed during the normal process of matching in the market. The pit Boss should, therefore, be able to run, from top down, match market, make a payoff within bound, then partly finish the requant in the lower tree.  It then runs asynchronously from the top, again, without state. The two tress always tending to correct past imbalances, ASAP, leaving the residual error.  Just keep the lines short enough.

Prime counting function and fraction approximation

I hinted once, if operation count goes as the prime numbers, and we extend  proofs on the prime counting function. The pit boss, financial share, in this formulation, is proportional to cycles on the iterator.  It is doing the nearest fractional approximation that satisfies the round off conditions. If we can show theories on how the pit boss counts, we can point to solutions of Riemann.  That means, using graph theory on transformations of these minimal trees.

We get the python N-ary pit channel compressor

A general framework that can be installed in any liquidity net, especially a net that can insure provable python bot codes. Then there is confidence al around, the python framework easily adapted to various bets and over the counter trades. Bots have access to publicly listed ledger services.

Biometric AppleID simplifies all this. Entry an exit, trading rules, bearer badges, bearer dollars for small trades. It brings the flexibility of a more complex trading contract, rather than simple 'no double spending'. So it is a great aid in risk equalization, which keeps the scofflaw count low.