Serving the Quantitative Finance Community

 
User avatar
katastrofa
Topic Author
Posts: 7440
Joined: August 16th, 2007, 5:36 am
Location: Alpha Centauri

Dating

June 12th, 2016, 3:16 pm

Thank you, Polter!
 
User avatar
rmax
Posts: 374
Joined: December 8th, 2005, 9:31 am

Re: Dating

August 24th, 2016, 9:57 am

I thought it was a pun, and so I reciprocated (I'm using C++11 and up) :-)Like I said, my issue is speed. Date calculations are not a significant part of the program logic, but they take a large fraction of the total execution time, hence my candidate for optimisation...
Did you solve this one? I once had a problem with the speed of an algo that kept being called. I instead just filled out a table with the necessary outputs, so the calculation happened once, and then a lookup was performed - much faster and happened to work well in that specific example.
 
User avatar
katastrofa
Topic Author
Posts: 7440
Joined: August 16th, 2007, 5:36 am
Location: Alpha Centauri

Re: Dating

August 28th, 2016, 7:11 pm

I thought it was a pun, and so I reciprocated (I'm using C++11 and up) :-)Like I said, my issue is speed. Date calculations are not a significant part of the program logic, but they take a large fraction of the total execution time, hence my candidate for optimisation...
Did you solve this one? I once had a problem with the speed of an algo that kept being called. I instead just filled out a table with the necessary outputs, so the calculation happened once, and then a lookup was performed - much faster and happened to work well in that specific example.
Thanks for the suggestion, but your case was probably something to do with swap pricing, where the number of dates was relatively small. In my case I have to do calculations on a large set of dates, so caching doesn't give any performance benefit (I tried it - cache lookups were even more expensive than date calculations).
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

Re: Dating

August 29th, 2016, 7:54 am

Seriously, what about this kind of approach.

https://www.quora.com/What-are-the-best ... om-filters
Last edited by Cuchulainn on August 29th, 2016, 2:58 pm, edited 1 time in total.
 
User avatar
Traden4Alpha
Posts: 3300
Joined: September 20th, 2002, 8:30 pm

Re: Dating

August 29th, 2016, 11:36 am

I thought it was a pun, and so I reciprocated (I'm using C++11 and up) :-)Like I said, my issue is speed. Date calculations are not a significant part of the program logic, but they take a large fraction of the total execution time, hence my candidate for optimisation...
Did you solve this one? I once had a problem with the speed of an algo that kept being called. I instead just filled out a table with the necessary outputs, so the calculation happened once, and then a lookup was performed - much faster and happened to work well in that specific example.
Thanks for the suggestion, but your case was probably something to do with swap pricing, where the number of dates was relatively small. In my case I have to do calculations on a large set of dates, so caching doesn't give any performance benefit (I tried it - cache lookups were even more expensive than date calculations).
Might there be a way to pre-process the raw data so that all dates are in some linear simple data type (e.g., 64-bit nanoseconds)?
 
User avatar
outrun
Posts: 4573
Joined: January 1st, 1970, 12:00 am

Re: Dates

August 29th, 2016, 5:14 pm

So do you have more details? What kind op date operations? and what is the starting representation of a date? Maybe it can be done branch-free?
 
User avatar
DavidJN
Posts: 242
Joined: July 14th, 2002, 3:00 am

Re: Dates

September 4th, 2016, 5:26 pm

Are you looking for the basic rudiments of a date library (e.g. constructing date numbers from month, day and year, or vice versa, and incrementing dates by days, weeks, months and years) or do you want the code to handle financial details like date rolls and computation of accruals? The reason I ask is that the very basics can be very efficiently accomplished with a handful of simple functions whereas the financial details are where the devils reside.

In my experience dealing date math proves to be a substantial part of a financial library and is often the source of errors encountered in fixed income calculations.