Intraday patch

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Intraday patch

Joseph Wang-4
I've just pushed up a patch to quantlib that provides basic support
for intraday calculations.  The patch consists of two new classes

timestamp - which is a simple UTC timestamp class.  It is a subclass
of Date, and can be used whereever date is.

continoustime - is a day counter that supports intraday calculations
with timestamp.  ContinousTime allows the user to specify the base
unit, so it is now possible to specify
interest rates and volatility per day, per week, or per month (which
is defined as 30 days) rather than per year.

The only non backward compartible part is the use of "yearFraction" to
specify something other than a fraction of a year.  There is a
function "timeFraction" which calls yearFraction.

Also this counter does not handle leap seconds, but I plan to add that.

I also intentionally left time zones out of these additions since
that's another level of complexity.

I can write some unit tests and I'll add some more comments.  However,
before I do, I'd like some feedback about the general class structure
and to go through a code review.

Below is python code that uses the new interface

def option(strike, vol, t, putcall):
    now = TimeStamp.now()
    Settings.instance().evaluationDate = now
    settlementDate = todaysDate + Period(3, Weeks)
    riskFreeRate = FlatForward(settlementDate, 0.00, ContinuousTime.perDay())

    # option parameters
    exercise = EuropeanExercise(settlementDate)
    payoff = PlainVanillaPayoff(Option.Call, strike)
    x = np.arange(strike*0.8, strike*1.2, 0.01);

    volatility = BlackConstantVol(todaysDate, TARGET(), vol,
ContinuousTime.perDay())
    dividendYield = FlatForward(settlementDate, 0.00, ContinuousTime.perDay())
    underlying = SimpleQuote(0.0)
    process = BlackScholesMertonProcess(QuoteHandle(underlying),
                                    YieldTermStructureHandle(dividendYield),
                                    YieldTermStructureHandle(riskFreeRate),
                                    BlackVolTermStructureHandle(volatility))
    option = VanillaOption(payoff, exercise)
    # method: analytic
    option.setPricingEngine(AnalyticEuropeanEngine(process))
    def myfunc(x):
        underlying .setValue(x)
        return option.NPV()
    def mydelta(x):
        underlying.setValue(x)
        return option.delta()
    def mytheta(x):
        underlying.setValue(x)
        return option.theta()
    plt.figure(1, figsize=(5,8))
    plt.subplot(211)
    y = map(payoff, x)
    plt.plot(x, y)
    plt.plot(x, map(myfunc,x))
    plt.subplot(212)
    plt.plot(x, map(mydelta,x))

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intraday patch

Klaus Spanderen-2
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/

regards
 Klaus

On Monday, December 22, 2014 03:58:19 PM Joseph Wang wrote:

> I've just pushed up a patch to quantlib that provides basic support
> for intraday calculations.  The patch consists of two new classes
>
> timestamp - which is a simple UTC timestamp class.  It is a subclass
> of Date, and can be used whereever date is.
>
> continoustime - is a day counter that supports intraday calculations
> with timestamp.  ContinousTime allows the user to specify the base
> unit, so it is now possible to specify
> interest rates and volatility per day, per week, or per month (which
> is defined as 30 days) rather than per year.
>
> The only non backward compartible part is the use of "yearFraction" to
> specify something other than a fraction of a year.  There is a
> function "timeFraction" which calls yearFraction.
>
> Also this counter does not handle leap seconds, but I plan to add that.
>
> I also intentionally left time zones out of these additions since
> that's another level of complexity.
>
> I can write some unit tests and I'll add some more comments.  However,
> before I do, I'd like some feedback about the general class structure
> and to go through a code review.
>
> Below is python code that uses the new interface
>
> def option(strike, vol, t, putcall):
>     now = TimeStamp.now()
>     Settings.instance().evaluationDate = now
>     settlementDate = todaysDate + Period(3, Weeks)
>     riskFreeRate = FlatForward(settlementDate, 0.00,
> ContinuousTime.perDay())
>
>     # option parameters
>     exercise = EuropeanExercise(settlementDate)
>     payoff = PlainVanillaPayoff(Option.Call, strike)
>     x = np.arange(strike*0.8, strike*1.2, 0.01);
>
>     volatility = BlackConstantVol(todaysDate, TARGET(), vol,
> ContinuousTime.perDay())
>     dividendYield = FlatForward(settlementDate, 0.00,
> ContinuousTime.perDay()) underlying = SimpleQuote(0.0)
>     process = BlackScholesMertonProcess(QuoteHandle(underlying),
>                                     YieldTermStructureHandle(dividendYield),
> YieldTermStructureHandle(riskFreeRate),
> BlackVolTermStructureHandle(volatility)) option = VanillaOption(payoff,
> exercise)
>     # method: analytic
>     option.setPricingEngine(AnalyticEuropeanEngine(process))
>     def myfunc(x):
>         underlying .setValue(x)
>         return option.NPV()
>     def mydelta(x):
>         underlying.setValue(x)
>         return option.delta()
>     def mytheta(x):
>         underlying.setValue(x)
>         return option.theta()
>     plt.figure(1, figsize=(5,8))
>     plt.subplot(211)
>     y = map(payoff, x)
>     plt.plot(x, y)
>     plt.plot(x, map(myfunc,x))
>     plt.subplot(212)
>     plt.plot(x, map(mydelta,x))
>
> ----------------------------------------------------------------------------
> -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intraday patch

Dirk Eddelbuettel

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 | [hidden email]

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intraday patch

Joseph Wang-4
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-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 | [hidden email]

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intraday patch

Klaus Spanderen-2
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.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
www.gigenet.com
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: Intraday patch

Joseph Wang-4
One other change that I'd like to see made is to rename the interface
"yearFraction" to "timeFraction" with yearFraction being a backward
compatible but deprecated interface.

The reason for this is that the ContinuousTime day counter allows one
to specific quantities in terms of perDay, perWeek, or perMonth
quantities, and this is relevant for bitcoin where interest rates are
specified per day rather than per year.

On Tue, Jan 13, 2015 at 2:09 AM, Joseph Wang <[hidden email]> wrote:

> 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.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
www.gigenet.com
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev