opengamma / strata Goto Github PK
View Code? Open in Web Editor NEWOpen source analytics and market risk library from OpenGamma
Home Page: http://strata.opengamma.io
License: Apache License 2.0
Open source analytics and market risk library from OpenGamma
Home Page: http://strata.opengamma.io
License: Apache License 2.0
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:
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.
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.
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
.
In an interpolated curve definition, we need the ability to:
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.
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
.
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:
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
.
Requires specification.
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.
It works for one trade but throws an exception for multiple trades.
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.
A trade domain model for CDS index.
Requires specification.
Debugging explanation for swap PV.
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.
Integrate the Analytics repo.
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.
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.
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.
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.
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.
Pricing for single-name CDS.
Trade model for single-name CDS.
Requires specification.
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
.
Ability to drill into a single calculation, capturing all intermediate values and market data.
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.
This is the higher level API that will be the default way for users to perform calculations.
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.
Pricing for CDS index.
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.
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.
It might include something like these methods:
cancel
isComplete
completedCount
expectedCount
Much like an interpolated curve definition, but:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.