forward volatility — from basic principle

See also — variance is additive. More specifically, for n multiple independent experiments with each outcome having var1, var2, …var_n, the sum of the outcomes has variance var1+var2+…var_n. Incidentally, the sum of the outcomes has mean of mean1+mean…mean_n. A random walker makes one “experiment” at each step, and the log(PR) is cumulative.
One basic assumption in is “Given that the underlying random variables for non overlapping time intervals are independent, the variance is additive.”

Q: What’s that random variable? I believe it’s the “r” i.e. log(PR) described in in This variable “r” is additive in itself. Intuitively, if over 4 days gold price moves by a ratio of 120% -> 101% -> 97% -> 99%, then we can ADD r2,r3,r4,r5… to get the overall Price-Relative of Day 5 over Day 1 closing.

where r1-2 represents log($Day2ClosingPrice / $Day1ClosingPrice) = log(PR over Day2), which is another label for the earlier r2.

It turns out this sum is the variance of log(PR1-5), or variance of r1-5 , i.e. the volatility over the 5 consecutive observations. Since the random variables r1-2 r2-3 r3-4 r4-5 follow the same pdf, each variance should be numerically identical.
==> variance over 96 hours and 5 observations (Price1 to Price5) is exactly 4 times the daily variance
==> If we assume 256 trading days in a year, then annual variance is 256 times daily variance
==> annualized vol is 16 times daily vol. If annualized vol is 80%, then log(PRdaily) has stdev = 5%…..

The sum in [1] is variance over Day 1-5. Forward variance over 2-5 can be derived from the 4 individual variance numbers, or from….

However, it’s unfair to compare 2-5 fwd variance against “spot” variance of 1-5 when the holding periods are unequal. Therefore, all the variance numbers must be annualized for a fair comparison.

Basic statistics rule — if Y = X_a + X_b, i.e. 2 independent normal variables, then the variance of Y is sum of the 2 variances.

Good knowledge of vendor products is far from enough for GTD

Consider typical non-trivial financial app based on 1 or a couple primary vendor products + some database + some JMS server + some app server + some web server. The #1 “primary vendor software” could be a distributed cache, spring, ETL, or something like ION or something else.

Q: How much complexity is in the vendor software, and how much is in the site-specific code including localized customizations of the vendor software?
A: 10% vs 90%

How about the ML Edge b2b trade engine? 70/30% at this stage (March).

harmless productivity tools ^ frameworks like ..Spring

[[The Productive Programmer]] by Neal Ford advocates learning a large number of _simple_ tools for productivity. Tools could be a complex but we use them in a non-intrusive, simple manner. Many other tools promise to help productivity but are traps – spring, hibernate, jaxb, xslt. Once you employ them they tend to become your master.

I have no such issues with perl/shell scripting, testing tools like junit, unix utilities, text editors, eclipse, maven/ant (?) A critical feature is, the option to use the tool in part of my project, and use alternative tools for the remainder. The tool should not be possessive and exclusive.

Hibernate is more gregarious than Spring, as you can mix Hibernate and straight JDBC in different modules of your system. Spring, being a framework, tends to engulf your entire project. You are then constrained by that framework developers’ decisions.

##wall blaster handy techniques to impelement features

Challenge — to implement non-trivial logic quickly, cleanly, with assurance and peace of mind.

Default (stupid) solution is a java/c++/c# implementation – painful. The challenge feels like a stone wall to drill through. The following technologies are good dynamites. (Additional Background — often, there’s a legacy Prod codebase…)

#1) regex
#2) SQL execute immediate
) perl
) reflection
) rmi
* embedded db
* multiple-statement SQL batch to implement complex logic
* byte code engineering
* DB constraints to replace app validation
* MOM as concurrency tool
* DB as concurrency tool
* file system as concurrency tool
* jmx
* annotation

* javascript, if this fits into the infrastructure
* xslt
* aop

I don’t fancy dependency-injection, ORM, ajax.

subject based addressing vs jms topics

Among the defining features of Tibrv, [ A) decentralization and B) SBA ] are 2 sides of the same coin. For me, it's a struggle to find out the real difference between SBA vs jms topics. Here's my attempt.

#1) In SBA(subject-based-addressing), there's no central server holding a subject. In tibrv, any sender/receiver can specify any subject. Nice — No admin to create subjects. I tested it with tibrvlisten/tibrvsend. By contrast, In JMS, “The physical creation of topics is an administrative task” on the central broker [2], not on the producer or consumer.

) If a jms broker goes down, so do topics therein.

) a jms publisher (or subscriber) must physically connect to a physical broker process[2]. The broker has a physical network address. Our topic is tied to that physical address. A tibrv subject has no physical address.

) tibrv SBA (subject-based-addressing) uses a subject tree. No such tree among JMS topics. The tree lets a subscriber receive q(prices.stocks.*)  but also q(*.your.*). See rv_concepts.

[2] such as the weblogic server in autoreo.

daily margin call – simplest futures illustration

Simplest and best-known margin calc is in commodity futures, say a Dec oil contract. Let me use it to describe daily margin calc in my own language.

Clearing house computes and issues daily margin calls. Therefore the formula/algo is crafted from the clearing house’s standpoint. Goal is to protect the clearing house from
1) any “reasonable volatility” i.e. a daily price swing smaller than the extreme 0.05% cases. (More extreme cases would show Larger swings.)
Here, let’s assume house estimates 1% maximum daily move.
2) any reasonable/unreasonable member default.

relevant — EOD best bid/ask
irrelevant — Current spot price — irrelevant.
irrelevant — Last transaction price for the same Fut contract — irrelevant.

Suppose current mid-day fut price = {89.99/90.01} ie {best bid/offer}

Suppose I BUY a contract mid-day at the market i.e. $90.01. Clearing house locks up an amount $x as collateral in my margin account to protect house against my default. If I default, on delivery date house still [1] need to BUY from the contract seller @ $90.01 the agreement/transaction price, but how does the house get the cash to BUY? To answer that, let me first Introducing the basic long margin call formula

  EOD-liquidation-value [my long position]  – 1% + x = $90.01 // Soon We will solve the margin requirement $x of a long, using agreement price and best BID at EndOfDay.

Here the clearing house is assuming market moves at most 1% against me by end of Day2. So if I declare bankruptcy on Day2, house liquidates my long position at most 1% below Day1’s EOD mv.

We will denote “current liquidation value of some position” as mv[that pos]

Now, mv [my long pos] is simply the best SELLING price of that asset (the oil contract) when house must liquidate my position. Think hard — That’s actually the end-of-day best BID. That’s $89.99 in our case, assuming no market move.

  x = $90.01 – $89.99 * 99%, roughly $0.02, which translates to $0.02k = $20. Here we assume each full contract is $90k when price = $90

— Now suppose market collapses drastically and moves against me to ($88/$88.02)

mv [my long position] – 1% + x = $90.01 // $90.01 is the me-counterparty agreement price

x = $90.01 – $88 * 99%, roughly $2.01k

A 2.2% Fut price change (89.99 to 88) causes a large margin call. I would say the margin call roughly matches the physical contract valuation drop from $89.990K to $88K

[1] so my default doesn’t cause a chain reaction taking down the seller.

5 parts in socket data structure

— Adapted from

Note accept() instantiates a socket object and returns a file descriptor for it. accept() doesn’t open a new port.

A socket object in memory consists of 5 things – (source ip, source port, destination ip, destination port, protocol). Here the protocol could TCP or UDP[1]. This protocol is identified in the packet from the ‘protocol’ field in the IP datagram.

Thus it is possible to have 2 different applications on the server communicating to to the same client on exactly the same 4-tuples but different in protocol field. For example

Apache at server talking on ( on TCP) and
World of warcraft talking on ( on UDP)

Both the client and server will handle it since protocol field in the IP packet in both cases is different even if all the other 4 fields are same.

[1] or others