fix: add a separate feature for each holiday's lower/upper windows #179
Conversation
WalkthroughThe changes in this pull request primarily focus on the Changes
Possibly related PRs
Poem
Warning Rate limit exceeded@sd2k has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 7 minutes and 43 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Deploying augurs with
|
| Latest commit: |
7b6281c
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://b9ac006b.augurs.pages.dev |
| Branch Preview URL: | https://holiday-reuse-features.augurs.pages.dev |
Reading through the original Prophet Python code, it looks like we're supposed to add a single feature for each value in the window of each holiday, rather than a separate feature every time the holiday occurs. This commit does so by creating a map of features and updating the relevant column in the map while iterating over the holidays occurrences.
sd2k
force-pushed
the
holiday-reuse-features
branch
from
301388c to
f8aa7bb
Compare
sd2k
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (2)
crates/augurs-prophet/src/features.rs (1)
61-61: Consider adding similar date examples in upper_window documentationFor consistency, consider adding specific date examples in the upper_window documentation similar to those added for lower_window.
/// Set the upper window for the holiday. /// /// The upper window is the number of days after the holiday /// that it is observed. For example, if the holiday is on - /// 2023-01-01 and the upper window is 1, then the holiday will - /// _also_ be observed on 2023-01-02. + /// 2023-01-01 and the upper window is 1, then the holiday will + /// _also_ be observed on 2023-01-02.crates/augurs-prophet/src/prophet/prep.rs (1)
719-731: Consider simplifying the loop when adding holiday features and prior scales.The current loop iterates over
this_holiday_feature_namesto push features and prior scales individually. If the order of features and scales is guaranteed, consider pushing them directly fromthis_holiday_featuresto reduce potential mismatches.Apply this diff to refactor the loop:
for col_name in this_holiday_feature_names { features.push( col_name.clone(), this_holiday_features.remove(&col_name).unwrap(), ); prior_scales.push( holiday .prior_scale .unwrap_or(self.opts.holidays_prior_scale), ); } +// Alternatively, iterate directly over this_holiday_features +for (col_name, col_values) in this_holiday_features.drain() { + features.push(col_name.clone(), col_values); + prior_scales.push( + holiday + .prior_scale + .unwrap_or(self.opts.holidays_prior_scale), + ); +}This change simplifies the code and reduces reliance on the separate
this_holiday_feature_namesvector.
🛑 Comments failed to post (3)
js/augurs-prophet-js/src/lib.rs (1)
1236-1236: 💡 Codebase verification
Type change requires attention in conversion code
The verification revealed that while the type has been changed to
u32in the struct definitions, there's a conversion toi32in the implementation that needs attention:
- In
crates/augurs-prophet/src/prophet/prep.rs, the window values are being converted fromu32toi32:Box::new(x.iter().copied().map(|x| x as i32)) as Box<dyn Iterator<Item = i32>>This conversion could potentially lose the benefits of using
u32and should be reviewed to determine if the internal logic actually requires signed integers.🔗 Analysis chain
Type change improves safety and correctness.
Changing from
Option<Vec<i32>>toOption<Vec<u32>>for both window fields is a good improvement because:
- Window sizes are naturally non-negative values
- It prevents potential bugs from negative window sizes
- It better represents the domain concept of future/past days
Let's verify that all related code has been updated to handle the new type:
Also applies to: 1245-1245
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining i32 references related to window fields # and verify that all conversions handle the new u32 type properly # Search for any remaining i32 references related to windows rg -i "window.*i32|i32.*window" # Search for potential type conversion code that might need updates ast-grep --pattern 'as i32'Length of output: 63
Script:
#!/bin/bash # Let's try a more comprehensive search approach # Search for window-related code to verify type usage rg -A 5 -B 5 "lower_window|upper_window" # Search for any i32 usage in the same file rg "i32" "js/augurs-prophet-js/src/lib.rs" # Find all files that might reference these window fields rg -l "window"Length of output: 12202
crates/augurs-prophet/src/prophet/prep.rs (2)
675-677:
⚠️ Potential issuePotential integer overflow when casting
u32toi32.Casting
u32values toi32can result in integer overflow if theu32values exceedi32::MAX. This may lead to unexpected behavior or runtime panics when processing large window values. Consider usingi64to safely accommodate the full range ofu32values.Apply this diff to address the issue:
let lower = holiday .lower_window .as_ref() .map(|x| { - Box::new(x.iter().copied().map(|x| x as i32)) as Box<dyn Iterator<Item = i32>> + Box::new(x.iter().copied().map(|x| x as i64)) as Box<dyn Iterator<Item = i64>> }) .unwrap_or_else(|| Box::new(std::iter::repeat(0))); let upper = holiday .upper_window .as_ref() .map(|x| { - Box::new(x.iter().copied().map(|x| x as i32)) as Box<dyn Iterator<Item = i32>> + Box::new(x.iter().copied().map(|x| x as i64)) as Box<dyn Iterator<Item = i64>> }) .unwrap_or_else(|| Box::new(std::iter::repeat(0)));Additionally, update the types in related variables and calculations to use
i64instead ofi32to ensure consistency and prevent overflow.Also applies to: 683-684
693-695:
⚠️ Potential issueInteger overflow risk when negating
lowerwindow values.Negating an
i32value derived from au32can cause overflow iflowerexceedsi32::MAX. Sinceloweroriginates from au32and may have large values, negating it may result in ani32overflow. To prevent this, consider usingi64foroffsetcalculations.Apply this diff to address the issue:
- for offset in -lower..=upper { + for offset in -lower..=upper { + let lower = lower as i64; + let upper = upper as i64; + for offset in -lower..=upper { let offset_seconds = offset as i64 * ONE_DAY_IN_SECONDS as i64; let occurrence = dt_date + offset_seconds; let col_name = FeatureName::Holiday { name: name.clone(), _offset: offset as i32, };Ensure that all related variables and computations use
i64to handle larger integer values safely.Committable suggestion skipped: line range outside the PR's diff.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
crates/augurs-prophet/src/prophet/prep.rs (2)
Line range hint
124-150: Consider usingu32for holiday offset as per PR objectives.The
_offsetfield in theHolidayvariant is still usingi32, but according to the PR objectives, we should be usingu32for the lower and upper windows.Consider updating the type:
Holiday { name: String, - _offset: i32, + _offset: u32, },
Line range hint
663-731: LGTM! Consider a small optimization for feature allocation.The new implementation effectively manages holiday features using a HashMap while preserving order. The separation of features for each holiday's lower and upper windows is well implemented.
A minor optimization could be to pre-allocate the HashMap with the expected capacity based on the window sizes.
Consider pre-allocating the HashMap:
- let mut this_holiday_features: HashMap<FeatureName, Vec<f64>> = HashMap::new(); + let capacity = (lower.size_hint().0 + upper.size_hint().0 + 1) as usize; + let mut this_holiday_features: HashMap<FeatureName, Vec<f64>> = HashMap::with_capacity(capacity);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
crates/augurs-prophet/src/prophet/prep.rs(4 hunks)
🔇 Additional comments (1)
crates/augurs-prophet/src/prophet/prep.rs (1)
Line range hint 663-731: Verify the impact of type changes and test coverage.
The changes to use a HashMap for holiday features and the proposed change to use u32 for offsets might affect other parts of the codebase.
Let's verify the impact:
✅ Verification successful
Based on the gathered information from all verification attempts, I can now provide the final response:
The type changes for holiday offsets appear to be localized and safe.
The verification shows that:
- The
_offsetfield is only used within theFeatureName::Holidayvariant - All usages of holiday offsets are contained within the same file (prep.rs)
- The changes to use HashMap for holiday features are internal to the implementation
- No test cases directly assert holiday offset values
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for other usages of holiday offsets and related tests
# Check for other occurrences of holiday offsets
echo "Checking for holiday offset usages:"
rg -A 2 "_offset.*i32"
# Check for related test files
echo "Checking for related tests:"
fd -e rs "test" -x rg -l "Holiday.*offset"
Length of output: 379
Script:
#!/bin/bash
# Let's check for holiday-related tests and feature name usages with a broader search
# Check for Holiday enum variant and its usages
echo "Checking Holiday enum variant and usages:"
rg -A 5 "Holiday\s*{"
# Check for tests containing 'holiday' keyword
echo "Checking holiday-related tests:"
rg -l "holiday.*test|test.*holiday"
# Check for any holiday-related feature name handling
echo "Checking holiday feature name handling:"
rg -A 3 "FeatureName::Holiday"
Length of output: 1760
Script:
#!/bin/bash
# Let's check the Holiday enum definition and test cases with fixed regex
# Check Holiday enum definition
echo "Checking Holiday enum definition:"
rg -A 2 "enum FeatureName"
# Check holiday-related test cases in prophet.rs
echo "Checking holiday test cases:"
rg -A 10 "holiday.*#\[test\]|#\[test\].*holiday" crates/augurs-prophet/src/prophet.rs
# Check for any holiday struct or type definitions
echo "Checking holiday struct definitions:"
ast-grep --pattern 'struct Holiday {
$$$
}'
Length of output: 596
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
crates/augurs-prophet/src/prophet/prep.rs (1)
Line range hint
663-723: Excellent refactor of holiday feature handling.The changes effectively implement separate features for each holiday window value:
- Uses a
HashMapfor efficient feature management- Properly handles holiday windows through offset calculations
- Follows idiomatic Rust patterns for memory management
- Maintains good performance characteristics
The implementation aligns well with the original Prophet Python code's functionality regarding holiday features.
Consider adding unit tests specifically for edge cases in holiday window handling to ensure continued reliability of this critical feature.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
crates/augurs-prophet/src/prophet/prep.rs(4 hunks)
🔇 Additional comments (1)
crates/augurs-prophet/src/prophet/prep.rs (1)
Line range hint 124-146: LGTM: Well-structured enum with appropriate trait implementations.
The FeatureName enum is well-designed with clear documentation for each variant. The addition of the Hash trait is appropriate for its use as a key in hash-based collections.
Reading through the original Prophet Python code, it looks like we're
supposed to add a single feature for each value in the window of each
holiday, rather than a separate feature every time the holiday occurs.
This commit does so by creating a map of features and updating the
relevant column in the map while iterating over the holidays
occurrences.
Summary by CodeRabbit
New Features
Bug Fixes