buy-side vs sell-side trader — real diff

buy-side (asset manager incl HF) vs sell-side trader — real diff

Both bet “house money” and keep Positions. See my acid test in What’s the real difference between both? Many friends gave me similar answers — strict hedging (though how strict is questionable — See Barings).

Sell-side trader must delta-hedge her positions. When market moves against her, her bank must be protected by the hedges. Sell-side is part of the “infrastructure” and the financial “services” (buy-side being the service-consumer). Therefore it needs more stability and less risk-taking.

In a volatile environment, a bank is supposed to /survive/ longer than a buy-side. A bank failure triggers deeper /repercussions/ and leads to larger /domino-effects/.

The best-known measure to enforce stability (and reduce risk-taking) on a sell-side trader is a strict policy of hedging. Upper management and regulators want to see VaR numbers and stress test results, periodically.

Effect of hedging should be obvious — risk should be much lower and profit also lower.

Barings didn’t hedge as market makers should. Nick Leeson hated to cut losses when market moved against him. He was acting like a buy-side and his firm failed like a buy-side.

clever use of enum(char?) in demanding c++ app

class Der: public Base {…..}

Requirement — we need to down cast a Base pointer. dynamic_cast has overhead.

Der* returnVal = static_cast (new Base) // will compile but is potentially disastrous, because the returnVal can be a partially wild pointer.

Q: without incurring the overhead of vtbl lookup, how do I decide if a pointer to Base given to me actually points to a Base or Der instance?

%%A: type_info still uses vtbl.
%%A: use a Base field to indicate the type. Both ctor will set the field, so the Der ctor will overwrite.
A: enum. If sizeof(aBase) is a tiny 2 bytes, then adding an enum field adds just 1 byte. Adding vptr would add 4 bytes. Big difference if we instantiate billions of this class. I guess enum can be configured to take 1 byte, but you can also use a char, which is always 1 byte.

custom logger to show src line num, caller, parent caller and grandparent caller

<![CDATA[ /** based on* Class name is mentioned in C:\Program Files\Java\jre1.6.0_06\lib\ */ public class JDKLoggingForamtter extends SimpleFormatter { private final String lineSeparator; public JDKLoggingForamtter(){ lineSeparator = new“line.separator”)); } @Override public synchronized String format(LogRecord record) { String sb = super.format(record); String lineNum = getEclipseFormat(); return sb.replaceFirst(lineSeparator, ” ” + lineNum + lineSeparator); } /** * Returns caller location information in eclipse format eg ( * WARNING Generating caller location information is extremely slow. * It's use should be avoided unless execution speed is not an issue. * * @return the eclipse format */ private static String getEclipseFormat() { // getStackTrace can be expensive StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace(); String upstairs = “”; int lineNumber = 0; //StringBuilder sb = new StringBuilder(); // Here is an example of the typical stack trace we get back. // level 0 ( getStackTrace // level 1 ( getFileLineNumber // level 2 ( format // level 3 ( publish // level 4 ( publish // level 5 ( log // level 6 ( doLog // level 7 ( log // level 8 ( someMethod if (stackTrace.length >= 9) { String fileName = stackTrace[8].getFileName(); lineNumber = stackTrace[8].getLineNumber(); // Each of these calls back into logger.logp with the appropriate // level and message. This adds one extra level to the stack trace // logger.finest(“finest message”); // logger.finer(“finer message”); // logger.fine(“fine message”); //“info message”); // logger.warning(“warning message”); // logger.severe(“severe message”); // logger.entering(“SomeClass”, “aMethod”); // logger.exiting(“SomeClass”, “aMethod”); // logger.exiting(“SomeClass”, “aMethod”, “returnval”); // logger.config(“config message”); // // Here is an example stack trace from a call to exiting // level 0 ( getStackTrace // level 1 ( getFileLineNumber // level 2 ( format // level 3 ( publish // level 4 ( publish // level 5 ( log // level 6 ( doLog // level 7 ( logp // level 8 ( exiting // level 9 ( someMethod // // We could check the name of the method we are in and only go one level deeper // if it is one of “finest”, “finer”, “fine”, “info”, “warning”, // “severe”, “config”, “entering” or “exiting” but that would be too much trouble. // If the stack is in and we can go one level deeper – do it. if (stackTrace.length >= 10 && “”.equals(fileName)) { fileName = stackTrace[9].getFileName(); lineNumber = stackTrace[9].getLineNumber(); } if (stackTrace.length >= 10){ upstairs = ” = 11){ upstairs += “

%%broad GTD value-add compared to a 3-year younger java programmer

 (Written in 2009)
– i managed difficult teams and difficult customers for years
– real AR experience with perl
– 5 years of Unix system admin experience
– i took part in AR decisions of many projects. 1st-hand AR experience
– I dealt with more diverse challenges of trouble-shooting and problem-solving
– In small projects, I was usually the customer-facing single point of
contact, not working behind the interface person. i was the only one
to negotiate with customer.
– Over the same 3 years, i dealt with many small customers rather than
1 or 2 big customers
– since i took part in more prj over the same 3 years, i witnessed
more failed prj
– i witnessed 1st-hand the “decline” of many technologies — rare xp

computing delta value from BS formula – unrealistic

Delta is the option-valuation change due to a small change in underlier. We are asking “using the BS formula as a prediction of real market, if there’s a $.01 change in underlier, what’s the change in bid/ask of this listed option?”

Assumption — all the bid/ask quoters in the option market use roughly the same BS formula. Obviously unrealistic. I don’t feel this assumption would help make delta a random variable.

Assumption — large number of bid/ask quoters responding to the underlier change. Realistic? I doubt it. Many quotes may ignore the spot change. I guess a small number of dealers/funds might _concentrate_ on a sector and are responsible for a disproportional part of the order book on that option. If they ignore the spot change, then bid/ask will stay constant and delta is 0!

Assumption — no change in i-vol when underlier changes. I feel real players in the market are emotional and may respond emotionally to whatever event causing the $.01 change. These emotional reactions can /effect/ a change in i-vol. I think some trend recognition machines may recognize this small change as part of a trend. I don’t feel such a market response is random.

What if the change is not $.01 but a 2% change?

Assumption — underlier price change is fairly slow and small. Obviously unrealistic. Therefore the change in option bid/ask in response to underlier change doesn’t always follow math model.

More important factor — An option is often held along with an underlier position as part of a strategy. When underlier moves, the holder may want to adjust her option position. One choice is adjusting her option quotes (limit orders). If she is a powerful market maker, then her new quote can move the best bid/ask. Therefore option valuation as measured by mid price may not move according to any math model.

"increase in volatility" can mean 1 of 2 things

An “increase in volatility” actually can mean 2 different things.

@ increase in “historical volatility”, which actually means increase in recent, observed volatility on the Cash market.[1] I feel this is what “increase in volatility” usually means.
@ increase in implied volatility, reflected in higher bid/ask “insurance” premiums on the Options market.

I-vol is forward-looking and refers to predicted future volatility of an underlier (like SPX) over the next 30 days (or 90, or 365 … days). So an increase there reflects people’s anticipation of market volatility.

H-vol is backward-looking and refers to recorded, realized volatility of an underlier (like GBP) over the past few days. When people talk about increase in h-volatility, I believe it’s usually over the Recent past.

[1] if you have an option on futures, then it’s not the Cash market but the futures market, but in this context it’s better to remove this kind of noise and focus on simple concepts.

4 career (survival) struggles – trading sys developers

(Focus here is the trading sys hands-on developer’s career planning.)

Struggle1: compete for jobs — Without strategies, one can easily get out-shined. The older, the harder. Often the hardest and the one struggle that counts. Recall our 2011-2012 job search…

Struggle1b: overcome the “relevant experience” obstacle. No one has track record in every major area. .

Struggle2: survive first 3->6-12 months — Statistically, most Veterans do survive but it can be a struggle for some. Banks pay 300% for a battle-tested veteran in order to get-things-done quickly. Timeline can be extremely demanding and pushing the human limit. Long hours. Can affect health, stress on everything including family. I was told developers in Asia face additional challenges.

Struggle2b: gain insight, create truly superior designs, add long term value — in addition to get-things-done. Not necessary for survival, but fulfills the promise of an “elite” expert developer. Caliber and Differentiation — Sets you apart on the job.

Struggle3: stay marketable long term — either in this or in another job market.

Struggle4: move up. Statistically, I guess most developers move into leadership roles but it doesn’t always come to you automatically.

Methods are implemented as Fields — function pointer Fields

(It would be great to go back to the earliest OO language, but let’s just start from C++.) The class concept is very similar to the C struct. Now if you add a func ptr as a struct field, then Whoa! A method is born (Today happens to be Christmas…)

Note python treats both fields and methods as “attributes”.

Suppose your struct is named MyStruct and has methods m1(), m2(). You may need to add a pointer-to-MyStruct as a hidden field (named “this”) to MyStruct. You have to pass “this” to m1() as a first argument. Consequently, m1() can reach all the fields of the host MyStruct INSTANCE. Without such an argument, m1() doesn’t know which object it belongs to. Remember all C++ methods are free functions in disguise.

Let me repeat — each method has the same first parameter of type (HostClass*)

That’s the basic idea of a c++ class, but we need some efficiency improvements. If you instantiate 999 instances of MyStruct, then are you going to allocate 999 func-pointers for m1() and 999 func-pointers for m2()?

No. I think you can just add a single pointer-to-MyStruct-class-object as another hidden field to MyStruct. In the singleton MyStruct class object, you keep the addresses of m1() and m2(). Therefore, ARM said the struct instance holds no info about m1().

The vtbl is also part of this singleton object.

Note java puts MyStruct class object in the permanent generation.

Another optimization is where to stored the “this” pointer. Brutal force solution is to add a ptr-to-MyStruct field to MyStruct but  C++ and java compilers all avoid this. I think the compiler treats “this” as a pointer Variable not a pointer Object (like vptr). Implicit conversion —

    myStructInstnace.m1(otherArgs) // becomes
    m1(&myStructInstance, otherArgs); // [aaa]

The [aaa] form isn’t really what compiler does. In MultipleInheritance “this” isn’t the same across Base objects and Derived object.

OO scripting languageS

I see more php developers create classes than Perl developers. I guess python developers are even more likely to create classes. Every language claim to support OO, but the litmus test is how easily (and how frequently) developers create user-defined classes.

(In the same vein, C++ template is a another thing regular developers have not fully embraced. Java generic class is yet another.)

Unlikely Java/c#, these scripting languages won’t deliberately make your life difficult if you don’t “embrace” OO.

Compared to perl and php, I feel python OO is simple, clean and “full-service” (not in the call-girl sense:). Incidentally, built-in python “features” are more object-oriented than in perl and php.

However, I still feel many python applications tend to be more procedural than OO. When facing a choice, I guess many developers feel procedural is simpler even thought python OO is not complicate. If a simple tool does the job, then no motivation to change.

What about multi-module team development? Look at perl and C projects. Many team still stick to procedural.