Skip to content

Need solution to the problem of default (global?) settings. #304

@avhz

Description

@avhz

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions