A rule of thumb:

When the dimensionality exceeds 5, then PDE solver often becomes too complex too slow, and Monte Carlo (as a methodology, not a technology) becomes more reasonable.

Skip to content
# keep learning 活到老学到老

## to remove two-column,resize your browser window to narrow

# Category: compFinance

# at what point MonteCarlo looks more promising than PDE

# solving PDE often need system of linear equations

# PDE option pricer software – dW term@@

# removing outlier in Monte Carlo

# return a matrix – imitate pthread_create()

# pass a matrix into a (language-neutral) math DLL

computational finance

A rule of thumb:

When the dimensionality exceeds 5, then PDE solver often becomes too complex too slow, and Monte Carlo (as a methodology, not a technology) becomes more reasonable.

Advertisements

This is to my surprise.

See also my book on numerical methods

See also [[Crack]]

See also D Duffy’s c++ book

I think the PDE (in physical science or finance) doesn’t have dW terms. The hedging derivation on Crack P75 seems to cancel out the dW term – a crucial step in the derivation.

In a monte carlo simulation, I feel we should never remove any outlier.

The special event we are trying to capture could be an extreme event, such as a deep OTM option getting exercised. Perhaps one in 9 billion realizations is an interesting data point.

Removing any outlier would alter the probability distribution. So our Monte Carlo estimate is no longer unbiased estimate.

However, if there’s a data point with operational or technical error it needs to be removed. Not removing it would also mess up the probability distribution.

As explained in other blog posts, a language-neutral dll (dynamic link library) should not receive or return an instance of C++ matrix type, since another language may not know its memory layout. So how does a function return a matrix (or 2 matrices?)

I feel we can take a page from pthread_create(), where the parameter representing the new thread is a pre-allocated but empty buffer. The pthread_create() function-call populates that buffer.

Well, some people don't like pre-allocation. They want to return a pointer. Where is the pointee physically?

– stack? pointee will be bulldozed before use

– global area like a global variable? next call to the same function will overwrite it. Concurrent call to the function will lead to “overwrite each other”

– heap? who will free the memory? Has to be caller. Caller would need to copy the data somewhere if it is not in a position to “free it after use”

In the pre-allocate scenario, the caller would set up an empty matrix in the format of the library, pass its address to the function, and later read the populated matrix. Matrix can be on heap, stack or global.

The argument passing convention might be different between languages. For our math DLL to be callable from fortran/C (the 2 basic languages for numerical computing?), I feel the lowest common denominator is a pointer to a buffer.

__ __

Caller would populate the buffer with the numbers of the matrix. Each number should be in a language-neutral binary format, following a specific bit layout, in case different languages represent a double differently. Something like 53 bits for the fraction, and 11 bits for the exponent.

__ __

Then caller invokes the library routine passing in the address. Inside the routine, we read the buffer to reconstruct the matrix into our own proprietary (C++) matrix instance and proceed. After this point, we are in c++ land and need not worry about other languages.

__ __

(purely my personal design.)