| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## main #250 +/- ##
=======================================
Coverage 99.92% 99.92%
=======================================
Files 23 23
Lines 1318 1354 +36
=======================================
+ Hits 1317 1353 +36
Misses 1 1
|
Sorry, something went wrong.
There was a problem hiding this comment.
@sbillinge @Sparks29032, it's ready for review.
Sorry, something went wrong.
| 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] |
There was a problem hiding this comment.
I think the length of r being extrapolated is more direct than the number of points being extrapolated.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
|
I will add a test for it if we are sure this implementation is what we want. |
Sorry, something went wrong.
| 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} " |
There was a problem hiding this comment.
Typo?
Sorry, something went wrong.
There was a problem hiding this comment.
@Sparks29032 is the implement ok, typo aside? Then @ycexiao can write a test.
Sorry, something went wrong.
There was a problem hiding this comment.
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).
Sorry, something went wrong.
|
"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. |
Sorry, something went wrong.
|
Can you also test it for the CLI case? Thanks |
Sorry, something went wrong.
There was a problem hiding this comment.
@Sparks29032 @sbillinge, it's ready for review.
Sorry, something went wrong.
| @@ -85,4 +94,22 @@ def morph(self, x_morph, y_morph, x_target, y_target): | |||
| high_extrap = np.where(self.x_morph_in > x_squeezed[-1])[0] | |||
There was a problem hiding this comment.
Do we want to remove these few lines of code? I can't find other references to the variables defined here.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
I find these variables provide a handy interface to test the extrapolated effect in test_morphsqueeze, so I think we should keep them.
Sorry, something went wrong.
| begin_end_sqeeze[0] <= begin_end_in[0] | ||
| and begin_end_in[-1] >= begin_end_in[-1] | ||
| ): | ||
| wmsg = ( |
Sorry, something went wrong.
There was a problem hiding this comment.
Can you make it say Warning: on the CLI as well?
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
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? |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
Thank you! Good to know. |
Sorry, something went wrong.
There was a problem hiding this comment.
@Sparks29032 @sbillinge, it's ready for review.
Sorry, something went wrong.
| @@ -85,4 +94,22 @@ def morph(self, x_morph, y_morph, x_target, y_target): | |||
| high_extrap = np.where(self.x_morph_in > x_squeezed[-1])[0] | |||
There was a problem hiding this comment.
I find these variables provide a handy interface to test the extrapolated effect in test_morphsqueeze, so I think we should keep them.
Sorry, something went wrong.
| assert expected_wmsg in result.stderr | ||
|
|
||
|
|
||
| def create_morph_data_file( |
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
That would be helpful! (see #233)
Sorry, something went wrong.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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.