Pricing for single-name CDS.

Requires specification.

If a set of market data mappings has no mapping for a market data key, the result is a call to a default mapping that throws an exception. This will cause the engine to fail non-gracefully.

A better approach would be for the mappings to return a market data ID containing details of the problem. A corresponding MarketDataBuilder could be created that always returns a failure in the market data with a description of the cause.

If a set of market data rules doesn't match a calculation target, the result is a call to a default mapping that throws an exception. This will cause the engine to fail non-gracefully.

A better approach would be for the mappings to return a market data ID containing details of the problem. A corresponding MarketDataBuilder could be created that always returns a failure in the market data with a description of the cause.

Currently the market data containers only contain valid market data. Any failures that occur when building market data are returned separately. The reasoning behind this design is that failures are transient and probably shouldn't be persisted with market data.

This design isn't so good when using the higher level CalculationEngine API. Details of the failures are discarded and the calculation results contain error messages that say "No market data available for XYZ" without any details of why the market data was not available.

The failures should be included in the market data so the errors in the results can include the details of why the market data is not available.

In addition to the full debugging API, it should be possible to access the curves used on a trade-by-trade basis as part of a standard calculation.

Performance optimisation for groups of measures which can be calculated together more efficiently than they can be calculated separately.

In the simplest example, for swaps, we have measures for PV, and PV of an individual leg. With this optimisation each leg would only have to be priced once in order to return all three measures.

combineWith does an intersection so that would be a more sensible name. And it would make sense to have a corresponding union operation with the same semantics as Map.merge.

Integrate the Analytics repo.

A trade domain model for CDS index.

In an interpolated curve definition, we need the ability to:

• at the curve level, specify a minimum period between nodes
• at the node level, specify a relative node priority

When processing the curve definition prior to calibration, the builder should identify any pair of nodes that infringe the minimum period and drop the node with the lowest relative priority to resolve the infringement.

This is useful when some nodes occur at fixed dates which move relative to the valuation date (futures), and others are a fixed period from the valuation date.

WrappingVectorEngineFunction invokes a scalar function multiple times to calculate values for multiple scenarios and packs the values into a list. When the number of scenarios is 1 it unpacks the list and returns the single value.

This behaviour makes sense if the user is consuming the trade level results, but not so much if the results are being fed into an aggregation function. In order to handle this behaviour:

• The aggregation function would have to handle both list and single values
• A different aggregation function would be needed depending on the number of scenarios

Neither of these options smells good.

Maybe the unwrapping behaviour in the function should be aware of what's consuming the results. Although that's not particularly elegant.

Or maybe the behaviour should be revert to the original behaviour of always producing a list. This would allow a consistent API for aggregation. For the case where there is only a single scenario, the results could be unpacked from the lists as a final post-processing step on the Results.

These results will need to be more than just a double[] - the sensitivities will always be interpreted as the sensitivity to a point on the curve, so some information about each point will be necessary.

By default the instrument implies the node date passed to the analytics during calibration (and the subsequent x value of that node on the calibrated curve), but it needs to be possible to override this regardless of the date implied by the instrument.

This is primarily to support node dates that align with ECB meeting dates. In this case, the node date would be defined as an index (after the current date) into a list of meeting dates.

We may also want to support overriding the node date to an alternative absolute or relative date as part of this.

Requires specification.

Separating the API from the Implementation for pricers is a good idea, but struggles to work in practical terms. The interfaces in pricer are fine, except that they are never likely to have an alternate implementation. Fast pricers will be totally different. And alternate models tend to need to take in different parameters.

Delete strata-pricer-impl and merge all code into strata-pricer.

It might include something like these methods:

• cancel
• isComplete
• completedCount
• expectedCount

Add support for conventions and templates in preparation for curve nodes.

A Template will consist of one or more underlying conventions. Templates will be persisted, conventions may be.

Requires specification.

Since the changes in commit #72, observable market data has been treated separately from other market data in the market data factory. This means it is possible to get rid of ObservablesMapping and for MarketDataMappings to contain the MarketDataVendor and to call MarketDataKey.toObservableId directly.

This will allow large portfolios to be handled using much less memory if the outputs are aggregate values and the trade level values can be discarded and GC'd once they are aggregated.

Defined simply as a curve that references two other curves. The value on the calibrated spread curve at any given tenor is the sum of the values on the other two curves at that tenor.

The two other curves may themselves be spread curves, or a more primitive type of curve.

High-level API which operates in terms of reports - at the closest level to the business user.

Each supported report type would be produced through a two-step process:

1. Invoking the CalculationEngine API to obtain the set of results necessary to produce the report.
2. Transforming the calculation engine results into the report format.

It should be possible to save the results of step 1 and run step 2 independently. This would allow an advanced user to produce a set of calculation results (via step 1 or separately through the CalculationEngine) which can be transformed into many different reports.

This is the level at which, for example, expression-based columns would be evaluated.

There are currently two result models, and this should be resolved into one.

Proposal is for the combined result to be keyed by int indices, to minimise the serialized form. For efficiency, a single array with (row * columnSize + column) will probably need to be used.

If we add column names as a concept, then the result model could also contain "Trade Id" and "Column Name" lists, similar to the API of Guava Table.

PV01 and Gamma are tested by replicating the formulas in the tests. They should also be tested by a local expansion: write the change of PV as an expansion in Delta and Gamma and compare with the full reval value.

Pricing for CDS index.

Much like an interpolated curve definition, but:

• nodes are only ZC inflation swaps
• the curve definition probably includes seasonality adjustments (a list of 12 monthly adjustments to be repeated each year) to be applied during calibration

It works for one trade but throws an exception for multiple trades.

Trade model for single-name CDS.

This is the higher level API that will be the default way for users to perform calculations.

SimpleMarketDataRules provides very limited functionality and was a placeholder implementation to get us up and running. It needs to be replaced with a MarketDataRules implementation that provides more power and flexibility, similar to DefaultPricingRules.

Ability to drill into a single calculation, capturing all intermediate values and market data.

Debugging explanation for swap PV.