-
-
Notifications
You must be signed in to change notification settings - Fork 173
Description
Generally pricing requires context data, such as an evaluation date, some conventions like day counting, etc.
A challenge is deciding whether to use a global config, like QuantLib has done with their Settings
class. For example:
Settings::instance().evaluationDate() = d;
This is fine for most use cases, but it primarily becomes an issue when a user decides they want to do some multithreading.
We could use something like the following:
// MSRV: 1.80
static EVALUATION_DATE: LazyLock<Mutex<Date>> = LazyLock::new(|| Mutex::new(today()));
This will work fine across threads (assuming they don't get poisoned), but if the user is using multithreading in order to price instruments with different contexts then it is useless.
We can use thread_local!
for different contexts across threads, but this has it's own challenges, and makes it more complex for users who just want some performance benefits without using different contexts.
Another solution is to require a context when pricing each instrument. But this will make the API somewhat unwieldy, since we would need to do something like:
instrument.price(&context)
If anyone has any thoughts/suggestions on the best way forward, that would be amazing.