|
From: Joseph W. <joe...@gm...> - 2015-01-05 02:03:35
|
I think that both patches would work for different use cases. My patch was specifically focused on dealing with bitcoin derivatives, so it intentionally works as only a UTC timestamp without any additional timezone data. Also bitcoin does everything on a per day basis, which means that I had to create a new day counter. One thing that I've seen done which would require some more sophistication in the Date class is to have special tags for "start of day" and "end of day". Also there is massively interesting quant work to be done with bitcoin futures. 1) there are two types of futures on bitmex. One is quanto style. The other is inverse style. Details on the each type are on their site, but there appears to be a convexity adjustment between the two. 2) counterparty risk modelling - The Chinese exchanges have something called "loss socialization". This is a situation in which they mess up margining, the exchange ends up with a loss, which they "socialize" against the people that made money. Modelling this is quite interesting. One thing that is particularly interesting is that counterparty risk does not affect price. It does affect volume in a big way. The Chinese exchanges are very liquid with short dated futures, but volume goes down dramatically for long dated futures. 3) general trading issues - This is where derivatives pricing meets trading. Derivative pricing has traditionally not involved many issues of flow trading. However, with bitcoin futures, you end up having to deal with things like bid-ask spreads. 4) Bootstrapping an IR curve - You can think of bitcoin futures as an interest rate product, which means that the only way you get a term structure curve with bitcoin is through the futures market. There is now enough data to start modelling that curve. In particular, the low end of that curve is fixed by the BFX swap markets. On Mon, Jan 5, 2015 at 6:36 AM, Dirk Eddelbuettel <ed...@de...> wrote: > > Klaus, > > On 4 January 2015 at 22:58, Klaus Spanderen wrote: > | Hi Joe, > | > | I was struggling with the same problem of intraday pricing a while ago. I've > | now found the time to bundle my solution into a patch. > | > | In short, I've added intraday resolution directly to QuantLib's Date class > | using boost::posix_time::ptime while keeping the existing interfaces and > | behavior the same. The test suite runs unchanged with the new Date class. If > | you are interest then please find more details > | > | https://hpcquantlib.wordpress.com/2015/01/04/intraday-high-resolution-day-counters/ > > This sounds excellent, and reads very well. Wonderful news! > > That said, I don't mean to take away from Joe's work which I meant to look at > but had not found time to actually do so. Being backwards compatible could > well be the key feature here. > > Exciting times ahead, along with Peter's AD magic... > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | ed...@de... |