> 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 <
[hidden email]> 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-da> > | y-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 |
[hidden email]
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.