long-term daily stock returns ~ N(m, sigma)

Label: intuitiveFinance

A basic assumption in BS and most models can be loosely stated as

“Daily stock returns are normally distributed, approximately.” I used

to question this assumption. I used to feel that if the 90% confidence

interval of an absolute price change in IBM is $10 then it will be

that way 20 years from now. Now I think differently.

When IBM price was $1, daily return was typically a few percent, i.e.

a few cents of rise or fall.

When IBM price was $100, daily return was still a few percent, i.e. a

few dollars of rise or fall.

So the return tends to stay within a narrow range like (-2%, 2%),

regardless of the magnitude of price.

More precisely, the BS assumption is about log return i.e. log(price

relative). This makes sense. If %return is normal, then what is a

-150% return?

Fwd: techies’ common complaints about jobs

label: orig, z_job

Hi friends,

Most techies (including developers) probably feel undervalued, and

have a lot of potential not utilized on the current job.

We blame our company or our team or our job. Maybe it's too easy;

maybe it's too repetitive; maybe it's too niche. We look up at some

high flyer and ask “what if I'm given that role… I may not do better

than that person, but surely I will be competent and up to the job. It

may be boring and stressful but Hey I will earn so much more!”

In many over-staffed IT departments, about 20% of the roles are

critical and some 20% of the roles are dedicated to “peripheral”

systems that no business users care about. Perhaps that system is

lightly used, and users don't trust the output anyway.



Well, my current job gives me a lot of opportunities to push myself

higher. It's not too niche (like Quartz/Athena/SecDB). It offers

complexity and depth. Not mindless and repetitive. Not something I

feel already too familiar with (and jaded). I can see the impact

quickly. The impact is on many people. The impact is on front office.

Still I'm not so fired-up. I guess there are always better roles out

there. Better condition our mind not to think that way. Instead make

the best use of the current role. “When life gives you lemons, make

lemonade”

set up dependency between two c++ projects

I will mostly talk about MSVS but will mention linux build too.

The common methods to set up the dependency, all done inside project BB

1) specify project dependency in MSVS

2) define include path to cover the header from AA

3) define library path to cover the object file from AA

Suppose project BB uses “things” in project AA. Say a file in BB #-includes a header in AA. I think it's not necessary to have any. This is important when you debug the dependency. You may fail to find any trace of the dependency in any of those places. The file in BB can simply #-include the full/relative path to the header from AA.

http://blogs.msdn.com/b/vcblog/archive/2010/02/16/project-settings-changes-with-vs2010.aspx describes project reference vs project dependency….

….. much more to say.

c++ compiler must know data type sizes

http://stackoverflow.com/questions/6264249/how-does-the-compilation-linking-process-work points out

So what the compiler outputs is rough machine code that is not yet fully built, but is laid out so we know the size of everything, in other words so we can start to calculate where all of the absolute addresses will be located. The compiler also outputs a list of symbols which are name/address pairs. The symbols relate a memory offset in the machine code in the module with a name. The offset being the absolute distance to the memory location of the symbol in the module.

new-expression alloates AND invokes ctor…most of the time

Neither the allocation or the ctor step is universal and guaranteed to happen.

1) ctor

new int; // This won't invoke any ctor since “int” is not a class/struct and doesn't have a ctor.

More importantly, if allocation fails then no “raw memory” is there to initialize.

2) allocation

It's possible to bypass the allocation, if you use placement-new

c++ threading support – historically

[[c++concurrencyInAction]] has a concise historical review…

* POSIX is a platform-specific C api, just like the Windows API. 
I feel this is an OS-level API. Every OS-level API tends to be in C (not c++), so various languages can all use it. OS-level API tend to “present” the hardware as is. The hardware has no concepts of object orientation or exceptions. The C language is the natural language for the hardware.
* Threading is a low-level, OS-level feature. (Kernel support? Not sure about the jargon). Naturally, threading is implemented in C and exposed first as C api. Many c++ threading developers simply use C api without any motivation to use c++.
* There's no surprise that the early c++ concurrency libraries are wrappers over the existing C api. Examples include MFC and Boost.
* Note low-level C api is usually platform-dependent. The c++ wrapper api has an opportunity to smooth out the platform differences.