I'd like to use the interpolation classes as functors, but it seems to
be difficult because the operator takes both a the domain variable and an allowExtrapolation. I could try using bind2nd but I don't think that there is an adaptable typedef there. Any ideas? (The context is that I'm going through the finite differencing code and trying to replace for loops with STL transform functions.) |
On 11/15/2005 05:15:09 AM, Joseph Wang wrote:
> I'd like to use the interpolation classes as functors, but it seems > to be difficult because the operator takes both a the domain variable > and an allowExtrapolation. I could try using bind2nd but I don't > think that there is an adaptable typedef there. Joe, the extrapolation parameter is optional, so the interpolations can be used as a unary function. In what way it doesn't work? Is it because you do want to pass the parameter? Later, Luigi ---------------------------------------- Olmstead's Law: After all is said and done, a hell of a lot more is said than done. |
Luigi Ballabio wrote:
> > On 11/15/2005 05:15:09 AM, Joseph Wang wrote: > >> I'd like to use the interpolation classes as functors, but it seems >> to be difficult because the operator takes both a the domain >> variable and an allowExtrapolation. I could try using bind2nd but I >> don't think that there is an adaptable typedef there. > > > Joe, > the extrapolation parameter is optional, so the interpolations > can be used as a unary function. In what way it doesn't work? Is it > because you do want to pass the parameter? > would be easy to add it to C++ class, but that would break the bridge pattern. > Later, > Luigi > > > ---------------------------------------- > > Olmstead's Law: > After all is said and done, a hell of a lot more is said > than done. |
On Nov 15, 2005, at 7:25 PM, Joseph Wang wrote:
>> the extrapolation parameter is optional, so the interpolations >> can be used as a unary function. In what way it doesn't work? Is it >> because you do want to pass the parameter? >> > It's because I want to set extrapolate to true. At first I thought it > would be easy to add it to C++ class, but that would break the bridge > pattern. I see. I think it can be done---I'll try and change it tomorrow. Luigi |
In reply to this post by Joseph Wang
On 11/15/2005 07:25:57 PM, Joseph Wang wrote:
>> > It's because I want to set extrapolate to true. At first I thought > it would be easy to add it to C++ class, but that would break the > bridge pattern. Joseph, it's done. You can check out the modified code and look at the relevant test case in test-suite/interpolations.cpp to see how to enable extrapolation. On an unrelated note, I'm not sure that the transform() method you added really belongs to Array, since a) it just wraps a call to std::transform, b) it is less flexible, being only self-applied while std::transform allows writing to a different output array, and c) I'd like to keep class interfaces as lean as possible. Would it be a major inconvenience for you if I took it back? Later, Luigi ---------------------------------------- The shortest way to do many things is to do only one thing at once. -- Samuel Smiles |
I see your point. You can go ahead and remove it. You might have to
fix some places where that is used. Also, what is your opinion about using transform in sampled curve. One other thing, has anyone ever done an interactive code review online? Luigi Ballabio wrote: > > On 11/15/2005 07:25:57 PM, Joseph Wang wrote: > >>> >> It's because I want to set extrapolate to true. At first I thought >> it would be easy to add it to C++ class, but that would break the >> bridge pattern. > > > Joseph, > it's done. You can check out the modified code and look at the > relevant test case in test-suite/interpolations.cpp to see how to > enable extrapolation. > > On an unrelated note, I'm not sure that the transform() method you > added really belongs to Array, since a) it just wraps a call to > std::transform, b) it is less flexible, being only self-applied while > std::transform allows writing to a different output array, and c) I'd > like to keep class interfaces as lean as possible. Would it be a > major inconvenience for you if I took it back? > > Later, > Luigi > > ---------------------------------------- > > The shortest way to do many things is to do only one thing at once. > -- Samuel Smiles |
Hi Joseph,
at work already? Aren't you a few hours west of here? On 11/16/2005 01:00:57 PM, Joseph Wang wrote: > I see your point. You can go ahead and remove it. You might have to > fix some places where that is used. Ok, no problem for the fixes. > Also, what is your opinion about using transform in sampled curve. I'm agnostic. As it seems to me it's still a class in progress, we might postpone the judgment until the interface stabilizes. > One other thing, has anyone ever done an interactive code review > online? It could be a nice event to hold for the QuantLib anniversary (the library is going to turn 5-years old this December.) But I have no idea of the software we might need to do something of this kind. Are you aware of any such facility? Later, Luigi ---------------------------------------- Academic: a term of opprobrium applied to those that do their job well by those who cannot. -- Sir Ernest Gowers |
In reply to this post by Luigi Ballabio
Also, I should be starting second round interviews with a Wall Street
firm next week. One issue that will come up is how that meshes with my work on Quantlib. Something that I will insist on is that my employment not prevent me from contributing code back to Quantlib if that code doesn't have any proprietary methods. I don't have any problem with the employer keep secret stuff secret, but if the terms of my employment keep me from contributing *anything* to Quantlib, then its not a good deal for me long term. (It's also not a good deal for my employer since it means that they are going to be constantly reinventing the wheel. Whether they realize this or not is one criteria for taking the job or not.) If anyone has a similar situation let me know. If no one has a similar situation, I'd also like to know that since it means that I might have to hire an IP lawyer to draft a "Quantlib clause" to any NDA that I sign, and other people might be able to use that clause with their employers. I'm actually in a good position to negotiate something like this since I can and will reject a job offer if the employer is not willing to be flexible about this. Also a general brain dump for stuff that I almost certainly will not be able to talk about if I get hired. 1) Hypothesis: The model that most people use to value RMB currency forwards is wrong. RMB currency forwards are not valued by the future expectation of RMB appreciation, but rather by the current spot price of RMB and the interest rate parity equation. One consequence of this that you ought to expect that the value of RMB forwards to appreciate in the next few months as the Chinese government loosens monetary policy and the Fed tightens monetary policy. This will make absolutely no sense if you model currency forwards as a crystal ball. 2) Hypothesis: Once the RMB really starts to move, people will find that the world currency system is dynamically unstable. RMB moves, East Asian currency follows, if this feeds back to the RMB basket, then you end up with a positive feedback loop. This hasn't been much of an issue since the PBC is holding the value of the RMB constant. Where this will bite is if you have a currency crisis. 3) PRC markets are much more rational and amenable to quantitative methods than most people think. Yes, you have issues with illiquidity, capital controls, fraud, corruption, information asymmetry, but that a mathematical model can take all of that into account. You can mathematically model fraud and corruption, for example. 4) You can model a convertible model not only as call option with a bond but also like a put option with a stock. The latter may be more useful if you have a CB whose value is above the conversion ratio, and would give you a reason *not* to convert a bond, even if you can. 5) The Fokker-Planck equation models the evolution of probability distributions of a stochastic differential equation. If you try to write down the moments evolution of the FP equation, you end up with some very simple formulas. One thing that happens is that the higher order moments don't seem to feedback on the lower order ones like they do in the Navier-Stokes. 6) Information theory is underused in QF. Given a certain about of information, one can derive some equations using information theory so figure out what can be figured out from that data. This can tell you that you shouldn't bother making a more complex model because the data is too spotty for it to make a difference. The basic way this would work is to calculate the number of bits of the information that you have, and then you should be able to calculate the number of bits (i.e. the precision) of the output that you are calculating. 7) You should be able to go straight from a stochastic differential equation to a FDM scheme *without* going through a PDE. I've never seen someone do this or work out step by step the math for doing this, but it can be done. Calculating a PDE is totally unnecessary in doing FDM. 8) You can bring in all of the good stuff in axiomatic probability theory if you realize that changing a measure is mathematically the same as changing the grid in an FDM calculation. You can also relate this to topology since the zero points in a probability measure are your topological invariants. 9) Standard Wall Street hiring methods very much discourage creative thinking. Basically you get the job based on how will you've mastered text book techniques, but spending time doing that discourages you from rewriting the textbook. Anyway I haven't been hired yet, so if anyone wants to chat about these ideas I still can. I'm also still in the market for other job offers. Also, If anyone knows how to deal with this situation let me know. I give resume to school recruiter for firm. School recruiter is *very* busy, and I've gotten zero information from the recruiter or anyone else in the firm about status of resume. If my understanding is correct, I can now longer use a head hunter to forward resume to said firm. Suggestions about what to do? I've already spammed everyone I know in said firm, but I'm much too low of a priority to get anyone's attention. This is actually a fun Alice and Bob-type problem. I would like to get the attention of someone on this list from said firm, but I don't want to let anyone know else which firm it is. Standard solution is a shared secret.... Hmmm.... Fun problem..... I'd ask on Wilmott but I generally get side tracked there on discussion that keep me from coding quantlib. :-) :-) :-) |
7) You should be able to go
straight from a stochastic differential
equation to a FDM scheme *without* going through a PDE. I've never seen someone do this or work out step by step the math for doing this, but it can be done. Calculating a PDE is totally unnecessary in doing FDM. wow! Examples???
What about straight from a
PDE to FDM without SDE "preprocessor"?
That's the way it is in
CFD?
DD From: [hidden email] on behalf of Joseph Wang Sent: Wed 16/11/2005 13:58 To: [hidden email] Cc: [hidden email]; [hidden email] Subject: [Quantlib-users] Jobs status and brain dump Also, I should be starting second round interviews with a Wall
Street |
Daniel J. Duffy wrote:
> 7) You should be able to go straight from a stochastic differential > equation to a FDM scheme *without* going through a PDE. I've never seen > someone do this or work out step by step the math for doing this, but it > can be done. Calculating a PDE is totally unnecessary in doing FDM. > wow! Examples??? The basic idea is that people go directly from a SDE to a binomial tree model by matching moments and without explicitly writing down a PDE. Since a tree is just a badly implemented explicit differencing scheme, you can take the operator that you would have used on the binomial tree and use this directly in your finite differencing scheme. So you can take a process such as a short rate bond model like Vasicek and/or CIR and then write down the differential operator, and instead of dumping that into a binomial tree, you run it into a finite difference engine. (You can also go the other way, take a PDE, extract the differential operator and then run that into Monte Carlo. The time you'd want to do that is when your volatility or drift is a function of the history of the process, and the system is no longer Markovian.) I suspect that this technique hasn't been published in the quantitative finance literature, since you have a lot of literature in which people are trying to do weird things where a tree hits a boundary condition or weird complex things involving subtrees and American options where you want more time steps near the exercise date. All of this is unnecessary. Once you have written down the differential operator from the SDE, then you can control your time steps however you want. You can also fix your boundary conditions exactly, shift your grid to deal with dividend payments. Whatever..... Also, I suspect that this formalism also handles jump-diffusion problems nicely. Jump is represented in the PDE world as just another term. So you take your SDE operator for the diffusion part, add the PDE operator for the jump part, and what you end up is nicely numerically behaved. > > What about straight from a PDE to FDM without SDE "preprocessor"? > > That's the way it is in CFD? I think in a lot of CFD, they treat the differencing engine as a black box. In CFD, your differential equations don't change, but your boundary conditions do. |
Free forum by Nabble | Edit this page |