> The only reason I created a subclass of Date was to avoid making any
> changes to the Date class. If there is a consensus to go with the new
> Date classes, then once that is in place, I can port the
> ContinuousTime date counters to use the new Date class.
>
> On Tue, Jan 13, 2015 at 1:54 AM, Klaus Spanderen <
[hidden email]> wrote:
>> Hi Joseph
>>
>> what is the best approach to merge both solutions? I do like your way of
>> adding new day counters which can deal with intraday resolution, especially a
>> Actual365 day counter, which reflects the opening hours of the exchange is a
>> good idea for non-bitcoin stuff.
>>
>> But the concepts for he Date classes are mutual exclusive.
>>
>> regards
>> Klaus
>>
>> On Monday, January 05, 2015 10:03:28 AM Joseph Wang wrote:
>>> 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.