You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, RustQuant lacks a robust mechanism to generate cashflow schedules that can be utilized in conjunction with pricing models and financial instruments. This functionality is essential for accurately pricing a wide range of financial products, such as bonds, options, and swaps. The absence of this feature makes it challenging to perform comprehensive pricing and risk management.
I propose implementing a schedule generation feature within the time module. This feature will enable the creation of cashflow schedules based on specified parameters such as start date, end date, frequency, and conventions (day counting and date rolling). The generated schedules will integrate seamlessly with existing models and instruments, facilitating accurate pricing and valuation.
Describe alternatives:
Manually inputting cashflow dates for each instrument, which is time-consuming and error-prone.
Using external libraries for schedule generation, which might not align perfectly with RustQuant's architecture and conventions.
Additional context:
The implementation will involve:
Creating functions to generate schedules based on input parameters (start date, end date, frequency, etc.).
Ensuring compatibility with date rolling conventions and day counting conventions.
Adding unit tests to validate the correctness of the generated schedules.
Document the new functionality and provide examples of usage.
This enhancement will significantly improve RustQuant's ability to handle a variety of financial instruments and streamline the pricing and risk assessment process.
The text was updated successfully, but these errors were encountered:
// Test for non-matching dates during addition (should panic).#[test]#[should_panic(expected = "Dates must match.")]fntest_non_matching_dates_add(){let date1 = OffsetDateTime::now_utc();let date2 = date1 + Duration::days(1);let cf1 = SimpleCashflow::new(100.0, date1);let cf2 = SimpleCashflow::new(50.0, date2);let _ = cf1 + cf2;}
```
Due the comparison among self.date and rhs.date is not working
```rust
impl std::ops::AddforSimpleCashflow{
type Output = Self;fnadd(self,rhs:Self) -> Self::Output{assert_eq!(self.date, rhs.date, "Dates must match.");Self{amount:self.amount + rhs.amount,date:self.date,}}}
Steps to Reproduce
Run the test test_non_matching_dates_add in the test suite.
Observe the test failing due to the assert_eq!(self.date, rhs.date, "Dates must match."); not working correctly.
Expected Behavior
The test should pass by panicking with the message "Dates must match." when self.date and rhs.date are not equal.
Environment
Rust version: 1.79.0
time crate version: v0.3.34
Possible Solution
Ensure that the OffsetDateTime comparison is correctly implemented or consider an alternative approach for comparing dates within the SimpleCashflow struct.
Currently, RustQuant lacks a robust mechanism to generate cashflow schedules that can be utilized in conjunction with pricing models and financial instruments. This functionality is essential for accurately pricing a wide range of financial products, such as bonds, options, and swaps. The absence of this feature makes it challenging to perform comprehensive pricing and risk management.
I propose implementing a schedule generation feature within the time module. This feature will enable the creation of cashflow schedules based on specified parameters such as start date, end date, frequency, and conventions (day counting and date rolling). The generated schedules will integrate seamlessly with existing models and instruments, facilitating accurate pricing and valuation.
Describe alternatives:
Additional context:
The implementation will involve:
This enhancement will significantly improve RustQuant's ability to handle a variety of financial instruments and streamline the pricing and risk assessment process.
The text was updated successfully, but these errors were encountered: