January 17th, 2012, 2:07 pm
QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnIn fact, I think a given single path can be used to generate payoff for multiple option types, which improves performance. One issue as mentioned is to worry that RN sequences are interrelated.At this stage, I think MCMediator is a candidate for the concepts approach?Good idea about attaching multiple payoffs to a single path!This a very good idea for some applications, but a very bad one for others. For a snapshot pricing of instruments, this can be OK. But this approach will create correlation in the MC errors between different instruments that were co-simulated. If, for example, a particular run of RNs accidentally contain an over-abundance of high paths, then all call-like pay-offs will have a higher than true price and all put-like pay-offs will have a lower than true price. In general, any studies of correlations in prices of different instruments will find more extreme values of correlation that is true (higher positive correlations among all instruments with the same signs on delta and lower negative correlations among all instruments with opposite signs on delta).This issue is just another example of the non-trivial coupling between methods used inside a blackbox and spurious errors or pathologies created when that blackbox is used in certain ways.QuoteOriginally posted by: outrunI've thought about the independent RN before in a distributed project. One approach we wanted to take is to let the RN run once for a long time, and then log the state/seed every 1M or 1B. You can then use that list of seeds to draw independent chuncks (of max size 1M/1B).Also, some RN have random access seeds/forward stepping to the n-th draw, e.g. with Sobol you can easily (const time) skip forward 1M samples.Can we come up with something like this? Or something better? Should we investigate random stepping for e.g. de mersenne twister? A number of years ago, we talked about creating a buffered serial RNG that created and buffered RNs for use by parallel path/price calculators. One processor core would spend up to 100% of it's time creating RNs and storing them. A second dispatch process would deal the buffered FIFO buffer of RNs to the N-1 cores that consume RNs. As long as one core can create enough RNs to feed N-1 cores of path, price, and aggregation calculations, then the approach would be efficient.