|
|
Here are some very rough ideas on modifying the finite difference engine
to handle systems of PDE's. Please feel free to point out flaws and
problems in these ideas, as I'd like to have a consensus that this
redesign is in the right direction before I start any coding.
The first issue is how to represent a system of PDE's. I propose two
objects
StateModel - Which is an abstract object that represents the current
state of the system
and
DynamicalModel - which is an object that includes one or more operators
and boundary conditions, step condition for the operators.
The idea that I'm playing with is to create an TimeStepper object which
sits under the FiniteDifferenceModel, takes the StateModel and
DynamicalModel and time steps it one step. The TimeStepper object would
then use the infrastructure of operators and such to calculate a single
time step.
It also occurs to me that the first thing that could be done with this
infrastructure is to clean up the ControlVariate code. The system of
PDE's would include both the price and the control prices in a single
framework. To retrofit the current code, we'd create a
SingleFunctionStateModel (i.e. a grid) and
SingleFunctionDynamicalModel (which encapuslates the operator, the
boundary conditions, and the step function conditions in one object)
As far as use cases, right now I'm thinking about two
* allowing the calculation of convertible bonds through the TF model
* making the control variate code a bit more elegant. One could put
both the main equation and the control variate equation into the same
system. Also, one could create an addControlVariate function which
would take a dynamic system and create a new dynamic system with a
control variate added.
Thoughts....
Thoughts?
|
Locked
