October 27th, 2011, 10:45 pm
QuoteOriginally posted by: outrun--------------------------------------------------------e.g. I don't like this QuantLib public interface: It's bloathware,--------------------------------------------------------boost::shared_ptr <PlainVanillaPayoff > vanillaPayoffPut( new PlainVanillaPayoff(Option:ut,K));BlackScholesCalculator vanillaPutPricer(vanillaPayoffPut,S0,forDisc,stdDev,domDisc); std::cout << "Value:" << vanillaPutPricer.value();--------------------------------------------------------This is much easier to learn and use-------------------------------------------------------std::cout << "Value:" << vanilla_put_price(S0,yield,vol, r, K,T)you can do both with a simple function wrapper, but you should at least prove a simple interface, which is also coherent: e.g. the first set of parameters are always related to the underlying process, the next set are defining the derivative contract. This interface should be standarized so that other modules can build build on top of it, and it should also implement global naming conventions across FFI. The goal is to make it easy and intuitive to use.I will have a few ideas on the internal interface / components talking to each other -- by analogy, let's refer to it as a Domestic Function Interface (DFI) perhaps? meaning solely (and strictly!) the QFCL project components internal communication/interoperability -- while maintaining the no-unnecessary-coupling constraint, will try to write up a post in proverbial spare time. Perhaps a separate thread is in order (I feel it might beneficial to keep the the DFI and FFI discussion uncoupled), will see.
Last edited by
Polter on October 27th, 2011, 10:00 pm, edited 1 time in total.