[[api design for c++]]

pimpl – adv/disadv
scripting support by boost::python
API wrapping/layering -- extremely common technique

api styles:
- flat C style
- OO
- template

[[21st century c]] - unusually practical update on C

a sub-chapter on string processing in the new world
a sub-chapter on robust Macros in the new world
a sub-chapter on function to report errors in the new world
a full chapter on pointer in the new world
a full chapter on C api to be consumed by other languages like python
a full chapter on struct syntax improvement to support returning multiple values + status code
a sub-chapter on pthreads
a sub-chapter on [[numerical recipes in C]] and the implementation – the GNU scientific library
a sub-chapter on SQLite
briefly on valgrind
function returning 2 values + status code
many innovative macro tricks
innovative and concise explanation of auto(i.e. stack) vs static vs malloc memory

Note a sub-chapter is very short, in a concise book. A remarkably practical update on C, somewhat similar to [[safe c++]]. Content isn't theoretical, and not so relevant to interviews, but relevant to real projects and GTD

[[spring data]]

chapter on redis (integration with spring data)

chapter on mongoDB (integration with spring data)

chapter on gemfire

chapter on JPA

multiple chapters on Hadoop

sub-chapter on job scheduling in the Hadoop context.

[[c++common knowledge]]

Has shorter, simpler treatment than [[effC++]]:
* placement new
* class-specific op-new
* restrict heap allocation of my class

[[java performance]] by Scott Oaks

--[[java performance]] by Scott Oaks

 

best of breed..see chapter details on

[jvm] heap memory

[jvm] threading

[jvm] instrumentation

JPA

serialization

lambda, stream  (java 8 interviews!)

 

The Introduction chapter outlines 3 broad aspects

* JVM – like memory tuning

* java language – like threading, collections

* Java API -- like xml parser, JDBC, serialization, Json...

 

JVM tuning is done by "system engineers" who may not be developers.

 

[[all about HFT]]

Author is an option specialists (currently teaching derivatives at a university). Many mentions of HFT on options.

 

chapters (80p) on technology. Author believes the 3 legs are {strategy, math, tech}

chapter (50p) on strategy

**first part seems to be uninteresting, math-light but might be important in practice

**chapter (12p) on arbitrage strategies

1 page on native API vs FIX.

a few pages on cpu offloading, including running Monte Carlo on GPGPU

compares c++ vs c#java in a HFT context

compares buy vs build in a HFT context

[[Quatitative Trading]] by E.P.Chan

I still feel it's too complicated ...

 

chapter (5p) on Matlab. This author singles out Matlab and Excel, not R or c++

chapter (40p) on back testing

**Chapter on historical database

chapter (2P) on HFT

chapter (7p) on factor models

[[practical api design]] java

I find this book rather detailed, not a lot of high-level (vague) concepts like most  design/architecture books including the classics. It seems to deal with some real world coding and design decisions. I would say these are not life-and-death decisions but still everyday decisions. (In contrast those other books address decisions I don't encounter or care at all -- seem to belong to another level.) Therefore this book is closer to my life as a developer.

chapter against "extreme" (unhealthy) advice. unconventional critique

** an api must be beautiful

** an api must be correct

** an api must be simple

** an api must have good performance

** an api must be 100% compatible

** an api must be symmetrical

chapter on creating a threadsafe API, to be used by clueless and untrained programmers.

chapter on supervising the development of an API

chapter on the fear of committing to a stable API

chapter on Factory better than constructor

chapter on making everything final

[[ModernC++]] - learning notes

Primitive language constructs at the foundation –

* preprocessor tricks, not those quick and dirty types

* (partial) template specializations

* non-type template arguments

* sizeof

 

compile-time programming

[[inside windows debugging]]

P38 has a half-pager comparison of the 2 main debuggers
^ MSVS – dev environment, with source code available
^ windbg – production environment. For post-coding, without source code.
** script/SQL debugging – only MSVS

P38 points out the free MSVS-express lacks certain debugging features. WinDBG is Completely free.

Q: does "windows debugger" mean windbg + minor tools?

--symbol files, symbol servers, *.pdb files
P53

P54 - "public symbols" and the microsoft online public symbol server.

[[c++without fear]] tips (fuxi in 12M)

P 418 [[c++without fear]] -- iterators are like smart pointers -- won't corrupt memory. Raw pointer is more dangerous, a low-level construct designed to give low-level programmers full control.

P 209 – for pointer recasts, C-style cast can be more convenient than reinterpret_cast

string,debugging + other tips - [[moving from c to c++]]

[[moving from c to c++]] is fairly practical. Not full of good-on-paper "best practice" advice.

P132 don't (and why) put "using" in header files

P133 nested struct

P129 varargs suppressing arg checking

P162 a practical custom Stack class non-template
P167 just when we could hit "missing default ctor" error. It's a bit complicated.

--P102 offers practical tips on c++ debugging

* macro DEBUG flag can be set in #define and also ... on the compiler command line

* frequently people (me included) don't want to recompile a large codebase just to add DEBUG flag. This book shows simple techniques to turn on/off run-time debug flags

* perl dumper receives a variable $abc and dump the value of $abc and also ..... the VARIABLE NAME "abc". C has a similar feature via the preprocessor stringize operator "#"

-- chapter on the standard string class -- practical, good for coding IV

* ways to initialize

* substring

* append

* insert

[[linux programmer's toolbox]]

MALLOC_CHECK_ is a glibc env var

--debugger on optimized code

P558 Sometimes without compiler optimization performance is unacceptable.

To prevent optimizer removing your variables, mark them volatile.

An inline function may not appear in call stack. Consider "-fno-inline"

--P569 double-free may not show issues until the next free() or malloc()

--P470 - 472 sar command 
can show per-process performance data

can monitor network devices

---P515 printf + macros for debugging

buffering behavior differs between terminal ^ log files

[[Hull]] estimating default probability from bond prices - learning notes

If we were to explain to people with basic math background, the
arithmetic on P524-525 could be expanded into a 5-pager. It's a good
example worth study.

There are 2 parts to the math. Using bond prices, Part A computes the
"expected" (probabilistic) loss from default to be $8.75 for a
notional/face value of $100. Alternatively assuming a constant hazard
rate, Part B computes the same to be $288.48*Q. Equating the 2 parts
gives Q =3.03%.

Q3: How is the 7% market yield used? Where in which part?

Q4: why assume defaults happen right before coupon date?
%%A: borrower would not declare "in 2 days I will fail to pay that
coupon" because it may receive help in the 11th hour.

--The continuous discounting in Table 23.3 is confusing
Q: Hull explained how the 3.5Y row in Table 23.3 is computed. But Why
discount to the T=3.5Y and not discounting to T=0Y ? Here's my long
answer.

The "risk-free value" (Column 4) has a confusing meaning. Hull
mentioned earlier a "similar risk-free bond" (a TBond). Right before
the 3.5Y moment, we know this risk-free bond is scheduled to pay all
cash flows at future times T=3.5Y, 4Y, 4.5Y, 5Y. That's 4 coupons +
principal. We use risk-free rate 5% to discount all 4+1 cash flows to
T=3.5Y. We get $104.34 as the value of the TBond cash flows
"discounted to T=3.5Y"

Column 5 builds on it giving the "loss due to default@3.5Y, discounted
to T=3.5Y". Iin Column 6, This value is further discounted from 3.5Y
to T=0Y.
---
Part B computes a PV relative to the TBond's value. Actually Part A is
also relative to the TBond's value.

In the model of Part B, there are 5 coin flips occurring every
mid-year at T=0.5Y 1.5Y 2.5Y 3.5Y 4.5Y with Pr(default_0.5) =
Pr(default_1.5) = … = Pr(default_4.5) = Q. Concretely, imagine that
Pr(flip = Tail) is 25%. Now Law of total prob states

100% = Pr(d05) + Pr(d15) + Pr(d25) + Pr(d35) + Pr(d45) + Pr(no d). If
we factor in the amount of loss at each flip we get

Pr(d05) * $65.08 + Pr(d15) * $61.20 + Pr(d25) * $57.52 + Pr(d35) *
$54.01 + Pr(d45) * $50.67 + Pr(no d, no loss) + $0 == $288.48*Q