Skip to content

Conversation

@ycexiao
Copy link
Collaborator

@ycexiao ycexiao commented Aug 25, 2025

What problem does this PR address?

Address the issue mentioned in #243. Create a warning for extrapolation in morphsqeeze.

What should the reviewer(s) do?

Please check the implementation.

@codecov
Copy link

codecov bot commented Aug 25, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.92%. Comparing base (3908d63) to head (e165b41).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #250   +/-   ##
=======================================
  Coverage   99.92%   99.92%           
=======================================
  Files          23       23           
  Lines        1318     1354   +36     
=======================================
+ Hits         1317     1353   +36     
  Misses          1        1           
Files with missing lines Coverage Δ
tests/test_morphsqueeze.py 100.00% <100.00%> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Collaborator Author

@ycexiao ycexiao left a comment

Choose a reason for hiding this comment

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

@sbillinge @Sparks29032, it's ready for review.

self.extrap_index_low = low_extrap[-1] if low_extrap.size else None
self.extrap_index_high = high_extrap[0] if high_extrap.size else None

low_extrap_x = x_squeezed[0] - self.x_morph_in[0]
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think the length of r being extrapolated is more direct than the number of points being extrapolated.

Copy link
Collaborator

@Sparks29032 Sparks29032 Aug 25, 2025

Choose a reason for hiding this comment

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

I think the length of r being extrapolated is more direct than the number of points being extrapolated.

The number of points is probably better. Let's say the user is told that the lower 10 points and upper 20 are being extrapolated. Then, they can simply take array[10:-20] if they do not want to work with extrapolated data.

See most recent comment.

Copy link
Collaborator

@Sparks29032 Sparks29032 Aug 25, 2025

Choose a reason for hiding this comment

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

I think the best would just be to say something like: "Warning: all points below {low} and above {high} are extrapolated using cubic spline etc. etc."

Make it clear that the low and high thresholds are for the grid (can't think of a proper way to word it right now).

Best to mention the method of extrapolation used (cubic spline I believe).

Edit for clarity: The low and high shouldn't be the lengths currently reported but rather the locations above/below which extrapolation is happening.

@ycexiao ycexiao marked this pull request as ready for review August 25, 2025 18:38
@ycexiao
Copy link
Collaborator Author

ycexiao commented Aug 25, 2025

I will add a test for it if we are sure this implementation is what we want.

if low_extrap_x > 0 or high_extrap_x > 0:
wmsg = "Extrapolating the morphed function: "
if low_extrap_x > 0:
wmsg += f"extrapolating length in the lowe r {low_extrap_x} "
Copy link
Collaborator

Choose a reason for hiding this comment

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

Typo?

Copy link
Contributor

Choose a reason for hiding this comment

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

@Sparks29032 is the implement ok, typo aside? Then @ycexiao can write a test.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'd prefer the grid values above/below which extrapolation occur be reported rather than the extrapolation length since the former quantity if probably more useful (made a comment above about this).

@Sparks29032
Copy link
Collaborator

"Warning: Points with grid values below {begin_end_sqeeze[0]} and above {begin_end_sqeeze[1]} will be extrapolated via cubic spline."

@ycexiao Maybe something like this? No capitals since we are not talking about the Python class, but rather the technique. Also make clear it is the grid. We don't need to tell them that we are obtaining points between x and y as a user of squeeze should already know this from the docs or manual.

@Sparks29032
Copy link
Collaborator

Sparks29032 commented Aug 26, 2025

Can you also test it for the CLI case? Thanks

Copy link
Collaborator Author

@ycexiao ycexiao left a comment

Choose a reason for hiding this comment

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

@Sparks29032 @sbillinge, it's ready for review.

self.x_morph_in
)
low_extrap = np.where(self.x_morph_in < x_squeezed[0])[0]
high_extrap = np.where(self.x_morph_in > x_squeezed[-1])[0]
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Do we want to remove these few lines of code? I can't find other references to the variables defined here.

Copy link
Collaborator

@Sparks29032 Sparks29032 Aug 26, 2025

Choose a reason for hiding this comment

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

These were variables we made before to store what you have now called begin_end_squeeze. You can delete it if you prefer using begin_end_squeeze.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I find these variables provide a handy interface to test the extrapolated effect in test_morphsqueeze, so I think we should keep them.

begin_end_sqeeze[0] <= begin_end_in[0]
and begin_end_in[-1] >= begin_end_in[-1]
):
wmsg = (
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Output effect:
image

Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you make it say Warning: on the CLI as well?

@Sparks29032
Copy link
Collaborator

I liked the behavior before where you only say extrapolatipn below if there is extrapolation below and above if there is above. So if only the above side has the warning:

Warning: Points with grid values above {begin_end_sqeeze[1]} will be extrapolated via cubic spline.

@ycexiao
Copy link
Collaborator Author

ycexiao commented Aug 26, 2025

We don't need to tell them that we are obtaining points between x and y, as a user of Squeeze should already know this from the docs or manual.

I think it would be helpful to reduce the bandwidth for users when they are tuning the coefficient to choose a moderate extrapolation length if we have both the expected x range and actual x range. Or do we prefer simplicity here?

@Sparks29032
Copy link
Collaborator

Sparks29032 commented Aug 26, 2025

The expected x range is just the target grid range. Also they cannot choose the extrapolation length, the refinement upon compression does so. There is no variable or user input to choose where they want to extrapolate.

When the user plots or obtains the data, all they need to know is where are the cutoff where data is extrapolated. Thus, if wonky behavior occurs in those ranges, they know why.

Imo, the point of this warning is to tell the user where the function will fail to do the expected behavior, not tell the user the expected behavior.

@ycexiao
Copy link
Collaborator Author

ycexiao commented Aug 26, 2025

Thank you! Good to know.

Copy link
Collaborator Author

@ycexiao ycexiao left a comment

Choose a reason for hiding this comment

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

@Sparks29032 @sbillinge, it's ready for review.

self.x_morph_in
)
low_extrap = np.where(self.x_morph_in < x_squeezed[0])[0]
high_extrap = np.where(self.x_morph_in > x_squeezed[-1])[0]
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I find these variables provide a handy interface to test the extrapolated effect in test_morphsqueeze, so I think we should keep them.

assert expected_wmsg in result.stderr


def create_morph_data_file(
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Do we want to create a helper.py module in \tests? If we want to add more CLI tests, we might need a handy function to create temporary *.cgr files. We can write this function in helper.py, and other tests can import it.

Copy link
Collaborator

Choose a reason for hiding this comment

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

That would be helpful! (see #233)

@ycexiao
Copy link
Collaborator Author

ycexiao commented Aug 26, 2025

CLI Warning output:
image

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.

3 participants