what's atmf exactly?
An ATM is an option where the strike is the same as the current observed underlying which can be the current spot, forward rate or delta neutral straddle. You can have an:
ATMS (at-the-money spot) option, where the strike is the same as the current spot rate.
ATMF (at-the-money forward) option, where the strike is the same at the current forward rate.
ATM delta neutral straddle, where the strike gives a delta neutral straddle .
The default ATM in the:
FX market is the delta neutral straddle.
IR market is the forward rate.
CM (commodity) market is the forward rate.
EQ market is the spot price.
 net delta = 0. Therefore for small fluctuations in underlier, portfolio MV doesn't change.
In most multi-threading domains, the driving force is often one of throughput, latency and parallelism. Yet The most prevalent motivation goes “processor clock speed is reaching a plateau, so the only way ahead is multi-core. Without multi-threading, the multiple cores lay waste.” This is like scale-out vs scale-up. This is the resource “utilization” argument. Any resource underutilized is a “guilt” and shame to some managers.
In GUI space, however, the real motivation is not “utilization” per se but Responsiveness.
I have seen many GUI apps that can't keep up with the live market data rate — latency.
I have seen many GUI apps that leave a long ugly trail when you move/resize a window.
Most GUI threading problems and techniques are related to Responsive not performance or throughput. Even “latency” is not really appropriate. In latency sensitive systems, Latency is often measured in clock cycles and microseconds, sometimes sub-micro, but Responsiveness doesn't need that. Such latency techniques can lead to over-engineering.
http://www.columbia.edu/~mh2078/FX_Quanto.pdf says “as the exchange rate moves, the volatility of an option with a given strike is also assumed to move in such a way that the volatility skew, as a function of delta, does not move“. By “skew” I take it to mean curve shape. By “function” I take it to mean a curve with delta as the x-axis.
If you refresh your USD/JPY vol surface every hour, you will see the surface moves. Let's keep things simple and just focus on the 1-year smile curve. This curve moves but its shape stays fairly constant. It stays constant if you plot (imp) vol against delta. I believe the shape doesn't stay constant if you plot vol against strike. We say FX vol is sticky delta not sticky strike.
A strong flow vol business Drastically reduces hedging cost of a structured vol deal maker.
A structured vol trader in a sell-side basically constructs structured deals for hedge fund, mutual fund, insurer and other institutional clients. Typically based on client request, but the sell side could presumably market a given instrument to a client on an unsolicited basis too. As a sell-side, this trader always, always need to hedge her exposure. Being a structured vol trader, the biggest exposure isn’t rates or credit but vol. The way to hedge away vol exposure is to enter into positions in options or var swaps — using Flow volatility instruments.
Since the vol exposure in a structured deal can be large in dollar terms, the hedge involves large flow vol trades. These trades tend to entail sizable amount of transaction cost, which is factored into the quote to client. The lower this hedging cost, the more competitive is our quote.
Best way to lower the hedging cost is a strong flow vol business. In the same way, a strong cash equity business reduces hedging cost of an equity volatility trader and makes his bid/ask more competitive.
For a commercial bank, it’s relatively easy to become a structured vol solution-provider. It’s harder to build flow vol business, the traditional strength of investment banks (and broker/dealers?).
In the retail space, there are parallels. Target sells lots of shoes and pays lots of rent, so it wants to make shoes and also buy (rather than rent) commercial property so as to drive down cost and offer more competitive prices to consumers.
— Based on [[c++InANutshell]] —
Template declarations describe a class (or function) but do not create any actual classes (or functions). To do these things, you must instantiate a template.
Most often, you implicitly instantiate a template by using it. An Actual template instance requires a template type argument for each dummy type. The arguments can be
– explicit or
** default arguments for class templates or
** deduced arguments for function templates, not class templates
Update: it looks like Command Source is usually a user input thingy?
Buttons, MenuItems, Hyperlinks, KeyGestures are command source objects. A command source Instance is a (typically) stateful object. Users issue commands via a command source.
Technically, CommandSource objects are instances of ICommandSource (ICS). It’s revealing to examine the properties of ICS….
Besides the ICS properties, the most important thing to Keep in mind is that Command Source objects subscribe to CanExecuteChanged events, by adding a (2-pointer) delegate instance into the invocation list (behind the event pseudo-field) inside the command object.
What a mouthful! Let’s try again. An event is a (pseudo) field inside a command. The command object “fires event A” by invoking callbacks in A’s invocation list. Each command source instance bundles “this” and one of its non-static methods into a callback object and appends it to the invocation list. Event A is the “CanExecuteChanged” event.
When a command source gets called back up on this event, it queries the command’s CanExecute() and gets a yes/no, and disables/enables itself accordingly. Note in a simple commanding usage, this even never fires and CanExecute() always returns true.
Restriction — a delegate is immutable, just like a string object. When you append or remove on a delegate instance, a new instance
is Returned (from a Method).
Restriction — when you remove the last item from the inv list, the delegate variable becomes null. You can’t have an non-null empty