Python import statement has many trivial or non-trivial scenarios. Here are some common ones:
Common scenario 1: we “import modu2” to execute modu2.py and also exposes all the “public” objects and functions in modu2 as modu2.something
(Simplest scenario but still not known to some programmers.)
Common scenario 2: if pack3 is a directory containing some python modules, we can
“import pack3.modu5” or “from pack3 import modu5”. Easy to understand.
Here’s a relative unusual scenario:
./pip install --verbose --no-deps --index-url=http://ficlonapd05.macbank:9090/api/ pymodels-linux==0.0.1.480 # assuming 0.0.1.480 is the pymodels version to test
>>> import pymodels
>>> pymodels.BlackImplyVol(.2, 3,3, 1, 0, 1,1)
In this case, there’s a pymodels directory but BlackImplVol is a function in the compiled library ./pymodels/pymodels_imp.so. How is this function accessible?
A: when “import pymodels” is run, the ./pymodels/__init__.py script executes, which does “from pymodels_imp import * “
My quant friend told me that the Hull-white model requires calibration via PDE solver. It can take a few seconds just to price a deal. If a spreadsheet has many deals the computational cost can add p to become non-trivial.
In contrast, the SABR model is much simpler – find a vol and plug it into BS formula.
https://en.wikipedia.org/wiki/Caret_notation explains the caret notation.
q(less) and many other unix tools prints “funny characters” in caret notation.
Programmer is one of few skill with a good “market depth”:
* a mediocre talent can find jobs to pay a decent blue-color knowledge worker wage
* a top talent can always find challenging and well-paying roles. There’s over-demand for the next 100 years. * Any talent level in between can easily find jobs with a suitable salary. * You can even teach this skill at various schools
I guess healthcare as a skill is similar.
Basketballers (any professional athletes) – very few get paid a good salary.
Mathematicians – I only know the teaching and quant jobs.
http://stackoverflow.com/questions/11108328/double-alignment Wug’s answer echoes Ashish’s comment that char fields should be grouped together.
Rule 1: For a given no-dividend stock, early exercise of American call is never optimal.
Rule 1b: therefore, the price is similar to a European call. In other words, the early exercise feature is worthless.
To simplify (not over-simplify) the explanation, it’s useful to assume zero interest rate.
The key insight is that short-selling stock is always better than exercise. Given strike is $100 but the current price is super high at $150.
* Exercise means “sell at $150 immediately after buying underlier at $100”.
* Short means “sell at $150 but delay the buying till expiry”
Why *delay* the buy? Because we hold a right not an obligation to buy.
– If terminal price is $201 or anything above strike, then the final buy is at $100, same as the Exercise route.
– If terminal price is $89 or anything below strike, then the final buy is BETTER than the Exercise route.
You can also think in terms of a super-replicating portfolio, but I find it less intuitive.
So in real markets when stock is very high and you are tempted to exercise, don’t sit there and risk losing the opportunity. 1) Short sell if you are allowed
2) Exercise if you can’t short sell
When interest rate is present, the argument is only slightly different. Invest the short sell proceeds in a bond.
See other posts about volatile, in both c++ and java.
[[c++succinctly]] also firmly denounced volatile keyword’s usage for concurrency.
[[effectiveModernC++]] echos in Item 40: Use std::atomic for concurrency, volatile for special memory.
For a “volatile” variable, c++ (unlike java) compiler is not required to introduce memory fence i.e. updates by one thread is not guaranteed to be visible globally. See Eric Lippert on http://stackoverflow.com/questions/26307071/does-the-c-volatile-keyword-introduce-a-memory-fence
This skillset is more like C and less like java. 90% of the java/py/c/… “tough systems” I required the same code tracing.
See ##transparent^semi-transparent^opaque languages