Page 2 of 2

Dating

Posted: June 12th, 2016, 3:16 pm
by katastrofa
Thank you, Polter!

Re: Dating

Posted: August 24th, 2016, 9:57 am
by rmax
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.

Re: Dating

Posted: August 28th, 2016, 7:11 pm
by katastrofa
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).

Re: Dating

Posted: August 29th, 2016, 7:54 am
by Cuchulainn
Seriously, what about this kind of approach.

https://www.quora.com/What-are-the-best ... om-filters

Re: Dating

Posted: August 29th, 2016, 11:36 am
by Traden4Alpha
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)?

Re: Dates

Posted: August 29th, 2016, 5:14 pm
by outrun
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?

Re: Dates

Posted: September 4th, 2016, 5:26 pm
by DavidJN
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.