Interpolator semantics

[Joseph Wang]

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.)

[Luigi Ballabio]

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.

[Joseph Wang]

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?
>

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.

> Later,
>     Luigi
>
>
> ----------------------------------------
>
> Olmstead's Law:
>         After all is said and done, a hell of a lot more is said
>         than done.

[Luigi Ballabio]

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

[Luigi Ballabio]

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

[Joseph Wang]

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

[Luigi Ballabio]

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

[Joseph Wang]

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. :-) :-) :-)

[cuchulainn]

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
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. :-) :-) :-)




-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Quantlib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Joseph Wang]

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.