Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use packed data within ChineseBasedYearInfo #4465

Merged
merged 7 commits into from
Dec 18, 2023

Conversation

Manishearth
Copy link
Member

Part of #3933

This does not yet add data loading, but it gets very close to it.

This PR makes the size of Date not bloat too much, without requiring much computation for any of the getters -- they're all basic bit operations.

@Manishearth Manishearth requested review from sffc and a team as code owners December 16, 2023 01:12
Copy link
Member

@sffc sffc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice

/// ```
///
/// Where the New Year Offset is the offset from ISO Jan 21 of that year for Chinese New Year,
/// the month lengths are stored as 1 = 30, 0 = 29 for each month including the leap month.
#[derive(Debug, Copy, Clone)]
///
/// Should not
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should not what?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... I have absolutely no idea

Copy link
Member Author

@Manishearth Manishearth Dec 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll fix this in the upcoming PR; this type will probably move to provider/chinese_based.rs anyway

!month_lengths[12] || leap_month_idx.is_some(),
"Last month length should not be set for non-leap years"
);
debug_assert!(ny_offset < 32, "Year offset too big to store");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought: You don't have much wiggle room here; I think you are making use of all 32 values :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potentially 31, but yes. Andrew and I spent some time researching this but I do plan to run a test on every year to check this property.

Comment on lines +192 to +193
prev_month_lengths += long_month_bits.count_ones().try_into().unwrap_or(0);
prev_month_lengths
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Praise: clever use of count_ones()

@Manishearth Manishearth merged commit 7a27226 into unicode-org:main Dec 18, 2023
29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants