[[c++codingStandard]] point out the many subtle traps a beginner can hit when an implicit conversion is accidentally applied to her data type.
Therefore it’s good to spot any implicit conversion feature. For a custom class, there are only 2 ways to convert implicitly and one of them is a single-arg constructor. It’s implicit by default. You can disable the conversion capability by force it to be always-explicit
Rule: immutability is on objects, not on variables. Actually, same as other languages.
Rule: An object’s mutability is determined by its type; for instance, numbers, strings and tuples are immutable, while dictionaries and lists are mutable.
Examples of containers are tuples, lists and dictionaries. The value of an immutable container object (like a tuple instance) that contains a reference to a mutable object can change when the latter’s value is changed; however the container is still considered immutable, because the collection of objects it contains cannot be changed. So, immutability is not strictly the same as having an unchangeable content, it is more subtle. See http://docs.python.org/2/reference/datamodel.html
In most cases, when we talk about the value of a container, we imply the values, not the identities of the contained objects; however, when we talk about the mutability of a container, only the identities of the immediately contained objects are implied.
I think for a custom MyClass that HAS-A object field myField, MyClass immutability means the content of myField is unchangeable. That's the strict definition of immutability.
Q: Do you prefer a job (under a boss) you are comfortable with, at a typical IT salary? Or do you prefer a job with above-average income, but suppressive boss? In both cases, let’s assume long term job security is average (far from ideal), workload is reasonable.
A: I’d favor the income if it’s more than $1k diff, but not sure if I can cope with the unfriendly environmental factors.
Health + employability(security) are my real, long term priorities.
Recall the GS/Macquarie experience – workload, job nature, security.
Based on P78 [[DerivativeFinancialProducts]].
Most popular Compound option is a call on a put. (I think vanilla Puts are the overall most popular option in Eq and FX, and embedded Calls are the most popular bond options.) Given a lot of buyers are interested in puts, there’s a natural demand for calls-on-puts.
In a Compound option there are 2 layers of fees (i.e. premiums) and 2 expiry dates —
The front fee is what you pay up front to receive the front option. If you exercise front option, you do so by buying the back option, paying the back fee as a 2nd premium to the dealer. Therefore the back fee is a conditional fee.
At end of front option’s lifespan, the back option’s protection period would start. (Remember in this case the back option is a protective put.)
It’s quite common that at end of the front window, the back option has become unnecessary, or back fee has become too expensive given the now reduced risk.
I feel quant funds (including HFT funds)
* does a large number of small trades and
* relies on a large volume of market data for statistical research/analysis. Sample size must be statistically meaningful.
I guess most FI and commodity markets often don’t support these. Some popular FI/Comm instruments have rich data volume, but doesn’t support small in-and-out trades. In FI/Comm, you buy and hold, rather than quick in-and-out trades. But how about high-volume listed FI instruments (like ED futures?) I hope the bid/ask is small enough to support in-and-out.
How about listed options? I feel percentage spread (bid/ask spread divided by mid-quote) is usually too large, so quick in-and-out trades are not always possible?
Reason: a commercial bank makes money by lending to (credit worthy) borrowers but ROI of this traditional business model is modest. They get much better ROI from security trading.
Reason: a commercial bank often has excess liquidity. Out of $1b deposit, banks are regulated to lend out perhaps 75% (or 90% — known as LTD ratio) but must keep some 25% of the $1b in liquid cash. If the bank keeps 25.5%, then the .5% is excess liquidity. Note a bank can’t treat (total deposit minus total loan) as excess liquidity. Bank is regulated to keep some liquid cash to satisfy depositor withdrawals.
By default, the excess liquidity cash sits there earning 0 return. Security trading is one way to get some return.
Reason: a commercial bank often has FX risk to hedge. I think FX/derivative trading is one way to hedge. Bank must allocate some capital to the trading desk. Regulators would approve such capital allocation as it’s needed to reduce systemic risk and strengthen stability.
Reason: a commercial bank often has large enterprise customers who need tailor-made financial solutions. (I feel many mainstream derivative products originated in big bank’s structuring desks addressing the needs of big corporates.) When the corporate enters a derivative contract with the bank, the bank must hedge its risk by trading suitable securities on the open market. Bank must allocate some capital to the trading desk.
Reason: many banks started trading using it’s own excess liquidity. Then they realize ROI is sweet, so they started borrowing from other banks purely for security trading. This is another source of trading capital.
(Note virtually all MC apps use UDP.)
To understand MC efficency, we must compare with UC (unicast) and BC (broadcast). First we need some “codified” metrics —
TT = imposing extra Traffic on network, which happens when the same packet is sent multiple times through the same network.
RR = imposing extra processing workload on the Receiver host, because the packet is addressed TO “me” (pretending to be a receiver). If “my” address were not mentioned in the packet, then I would have ignored it without processing.
SS = imposing extra processing workload by the Sender — a relatively low priority.
Now we can contrast MC, UC and BC. Suppose there are 3 receiver hosts to be notified, and 97 other hosts to leave alone, and suppose you send the message via —
UC – TT not RR — sender dispatches 3 copies each addressed to a single host.
BC – RR not TT — every host on the network sees a packet addressed to it though most would process then ignore it, wasting receiver’s time. When CEO sends an announcement email, everyone is in the recipient list.
MC – not RR not TT. However, MC can still flood the network.