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

feat(ShiftRA): add option to make shift 360-degree-periodic #226

Merged
merged 1 commit into from
Mar 21, 2023

Conversation

sjforeman
Copy link
Contributor

Adds an option to ShiftRA to periodically wrap shifted RA coordinates, and the RA axis of any relevant dataset

@sjforeman sjforeman force-pushed the sf/shift-ra-periodic branch 2 times, most recently from b3ffd86 to 49ffbec Compare February 11, 2023 00:48
@sjforeman
Copy link
Contributor Author

@ljgray The black check is failing here, and I recently saw your (now closed) PR that noted the changes in the latest version of black. Is there a plan to apply the new version to the radiocosmology codes, or pin the black version in the CI, or something else?

@ljgray
Copy link
Contributor

ljgray commented Feb 11, 2023

@ljgray The black check is failing here, and I recently saw your (now closed) PR that noted the changes in the latest version of black. Is there a plan to apply the new version to the radiocosmology codes, or pin the black version in the CI, or something else?

Ah, yeah I should have mentioned that somewhere. I think we settled on just having whoever opens a PR that fails due to black just update and run the newest version of black and include that as a commit in the PR (I think it's black 23.1 ). So I guess just run the newest version of black over everything here and include those changes in anther commit, and it'll get included when this is merged. I've already done this on ch_pipeline and ch_util

@sjforeman
Copy link
Contributor Author

Ah, yeah I should have mentioned that somewhere. I think we settled on just having whoever opens a PR that fails due to black just update and run the newest version of black and include that as a commit in the PR (I think it's black 23.1 ). So I guess just run the newest version of black over everything here and include those changes in anther commit, and it'll get included when this is merged. I've already done this on ch_pipeline and ch_util

@ljgray Sounds good, thanks for clarifying!

@ljgray
Copy link
Contributor

ljgray commented Feb 14, 2023

FYI, I merged in another PR that updated the black formatting, so there might be a merge conflict to deal with

@sjforeman sjforeman force-pushed the sf/shift-ra-periodic branch 2 times, most recently from 5fcf2cb to 4ace641 Compare February 15, 2023 21:34
Copy link
Contributor

@ljgray ljgray left a comment

Choose a reason for hiding this comment

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

Overall I think the implementation is good. I wonder if we should separate the behaviour of wrapping the ra axis and actually applying the shift to the datasets into two separate flags, like periodic and apply_to_data. As far as I understand, the original reason for this task was to properly align the ra axis stamps with the underlying data, so modifying the underlying data has a slightly different effect than what was previously being done.

@sjforeman
Copy link
Contributor Author

Overall I think the implementation is good. I wonder if we should separate the behaviour of wrapping the ra axis and actually applying the shift to the datasets into two separate flags, like periodic and apply_to_data. As far as I understand, the original reason for this task was to properly align the ra axis stamps with the underlying data, so modifying the underlying data has a slightly different effect than what was previously being done.

I'm not sure I understand the case you're describing, where you would want to shift and wrap the ra axis but not the data itself. Suppose the RA coordinates are accidentally 2deg behind the true RAs of each sample, and suppose the final sample in the axis is labelled as 359deg. You'd want to apply a +2deg shift to that, so it becomes 361deg. But, some tasks expect the RA axis to be monotonically increasing, so we'd like the periodic=True option to wrap the 361deg sample around to the beginning of the axis and relabel it as 1deg. In that case, I'd also expect that we want to wrap the datasets in the same way, such that the old RA=359deg data line up with the relabelled RA=1deg element.

@ljgray
Copy link
Contributor

ljgray commented Mar 17, 2023

I'm not sure I understand the case you're describing, where you would want to shift and wrap the ra axis but not the data itself. Suppose the RA coordinates are accidentally 2deg behind the true RAs of each sample, and suppose the final sample in the axis is labelled as 359deg. You'd want to apply a +2deg shift to that, so it becomes 361deg. But, some tasks expect the RA axis to be monotonically increasing, so we'd like the periodic=True option to wrap the 361deg sample around to the beginning of the axis and relabel it as 1deg. In that case, I'd also expect that we want to wrap the datasets in the same way, such that the old RA=359deg data line up with the relabelled RA=1deg element.

Ah, yes I see what you mean

@sjforeman sjforeman merged commit 173236e into master Mar 21, 2023
@sjforeman sjforeman deleted the sf/shift-ra-periodic branch March 21, 2023 18:37
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