Equational

At least eight dimensions can be used qualify the way financial participants trade: Transaction speed from slow to quasi-instantaneous. Transaction rate from rare/infrequent to quasi-continuous. Selection of transactions from disorganized to very organized (e.g. backed by mathematics and research). Transaction's future obligations from no future obligations to with future obligations (e.g. backed by personal wealth). Time scope of transaction's obligation from immediate (e.g. transfer cash) to long term (e.g. payout bond coupon after 30y). Number of participants on "same side of transaction" from small to large Size of single transaction from small to large. Influence of fundamental/"real world" properties of traded contract from none to very important. In the context of the GameStop event we note the following:  Traditionally,  retail investors execute transactions: Slowly Infrequently In a disorganized way With no future obligation With only immediate obli...

In 1996, my team adopted a tensor view of its application parameter space. Credit must be given to one of my partners at QT Optec/Actant, who presented the following view of the world: each client could "tie" each parameter to any point/slice in "high-dimensional" cartesian space of primary and secondary keys. It was an advanced concept which took me many years to fully master. The simple statement is: "it ain't easy"! Higher dimensional data views are "all the rage" now, but not in 1996. I'll try to illustrate the concept as follows: Imagine we have a parameter P1 used in formula F that goes from X to Y. Imagine that X can be queried with keys kx0 and kx1 (it is two dimensional) and Y is three dimensional with "axis" ky0, ky1, and ky2. P1 is a parameter, which means that it is a "given value". The question is then: is P1 just one value? Should we use a different P1 for the different values of X tied to its 2d mapping ...

 Here is what works for me to write higher order typed Python: Use class with __call__ instead of lambdas or functions (aka explicitly specify each closure). Favor constraining types with Callable , ParamSpec and Concatenate (not with class constructions). Replace *args by immutable list (Tuple[a,Tuple[b, ...) when ParamSpec fails to scale.  Replace **kwargs with object using @overload  with Literal typed arguments (sadly TypedDict seems not to support generic typing) . Use Generic to “store” multiple polymorphic types Use Protocol to separate semantic tiers of types (e.g. ownership in a smart contract) No nested functions, lambdas or classes. Use cast to type "unmanaged" types (e.g. eval) Use phantom typed "dummy" arguments (and type casts) to get around "wrong direction" type dependencies Visual Code's Pyright works. Early 2021, pycharm fails. The untyped application scope is a broader Python 3 stack. Note this is 3.10 Python typing (e.g. Par...