-
Notifications
You must be signed in to change notification settings - Fork 17
Squeeze morph: Adding UCs tests #182
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
Changes from 5 commits
c4ed0e6
c59b09e
2320b82
ead3248
924872e
3538e4d
234b387
4c6d993
fcee820
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
**Added:** | ||
|
||
* Polynomial squeeze of x-axis of morphed data | ||
|
||
**Changed:** | ||
|
||
* <news item> | ||
|
||
**Deprecated:** | ||
|
||
* <news item> | ||
|
||
**Removed:** | ||
|
||
* <news item> | ||
|
||
**Fixed:** | ||
|
||
* <news item> | ||
|
||
**Security:** | ||
|
||
* <news item> |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,49 @@ | ||
from diffpy.morph.morphs.morph import LABEL_GR, LABEL_RA, Morph | ||
|
||
|
||
class MorphSqueeze(Morph): | ||
"""Squeeze the morph function. | ||
|
||
This applies a polynomial to squeeze the morph non-linearly. The morphed | ||
data is returned on the same grid as the unmorphed data. | ||
|
||
Configuration Variables | ||
----------------------- | ||
squeeze : list | ||
The polynomial coefficients [a0, a1, ..., an] for the squeeze function | ||
where the polynomial would be of the form a0 + a1*x + a2*x^2 and so | ||
on. The order of the polynomial is determined by the length of the | ||
list. | ||
|
||
Example | ||
------- | ||
>>> import numpy as np | ||
>>> from numpy.polynomial import Polynomial | ||
>>> from diffpy.morph.morphs.morphsqueeze import MorphSqueeze | ||
|
||
>>> x_target = np.linspace(0, 10, 101) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's remove this block of text because it will confuse people. This is us building a target, but the assumption is that the user already has a target, so none of this code is needed by people just to use the morph. |
||
>>> y_target = np.sin(x_target) | ||
>>> x_morph = np.linspace(0, 10, 101) | ||
>>> squeeze_coeff = [0.1, -0.01, 0.005] | ||
>>> poly = Polynomial(squeeze_coeff) | ||
>>> y_morph = np.sin(x_morph + poly(x_morph)) | ||
|
||
>>> morph = MorphSqueeze() | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this block is what we are after. We could add a few words about what the variables mean. Maybe also add a couple of lines that show other attributes that the user can access from the btw, this looks great in general. I am not sure if we have a "group standard" for these code blocks. I think that it is possible to write htese actually so that they can be run by some automated testing codes but we don't really do that. I just feel that, as a user, if there is a few lines of code showing how to use this, it can be super helpful. |
||
>>> morph.squeeze = squeeze_coeff | ||
>>> x_morph_out, y_morph_out, x_target_out, y_target_out = morph( | ||
... x_morph, y_morph, x_target, y_target) | ||
""" | ||
|
||
# Define input output types | ||
summary = "Squeeze morph by polynomial shift" | ||
xinlabel = LABEL_RA | ||
yinlabel = LABEL_GR | ||
xoutlabel = LABEL_RA | ||
youtlabel = LABEL_GR | ||
parnames = ["squeeze"] | ||
|
||
def morph(self, x_morph, y_morph, x_target, y_target): | ||
"""Apply a polynomial to squeeze the morph function""" | ||
Morph.morph(self, x_morph, y_morph, x_target, y_target) | ||
|
||
return self.xyallout |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,60 @@ | ||
import numpy as np | ||
import pytest | ||
from numpy.polynomial import Polynomial | ||
|
||
from diffpy.morph.morphs.morphsqueeze import MorphSqueeze | ||
|
||
squeeze_coeffs_list = [ | ||
# The order of coefficients is [a0, a1, a2, ..., an] | ||
# Negative cubic squeeze coefficients | ||
[-0.2, -0.01, -0.001, -0.001], | ||
# Positive cubic squeeze coefficients | ||
[0.2, 0.01, 0.001, 0.001], | ||
# Positive and negative cubic squeeze coefficients | ||
[0.2, -0.01, 0.002, -0.001], | ||
# Quadratic squeeze coefficients | ||
[-0.2, 0.005, -0.007], | ||
# Linear squeeze coefficients | ||
[0.1, 0.3], | ||
# 4th order squeeze coefficients | ||
[0.2, -0.01, 0.001, -0.001, 0.0004], | ||
# Zeros and non-zeros, the full polynomial is applied | ||
[0, 0.03, 0, -0.001], | ||
# Testing zeros, expect no squeezing | ||
[0, 0, 0, 0, 0, 0], | ||
] | ||
morph_target_grids = [ | ||
# UCs from issue 181: https://github.com/diffpy/diffpy.morph/issues/181 | ||
# UC2: Same range and same grid density | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is now fantastic! I love these tests. Future us will love you. |
||
(np.linspace(0, 10, 101), np.linspace(0, 10, 101)), | ||
# UC4: Target range wider than morph, same grid density | ||
(np.linspace(0, 10, 101), np.linspace(-2, 20, 221)), | ||
# UC6: Target range wider than morph, target grid density finer than morph | ||
(np.linspace(0, 10, 101), np.linspace(-2, 20, 421)), | ||
# UC8: Target range wider than morph, morph grid density finer than target | ||
(np.linspace(0, 10, 401), np.linspace(-2, 20, 200)), | ||
# UC10: Morph range starts and ends earlier than target, same grid density | ||
(np.linspace(-2, 10, 121), np.linspace(0, 20, 201)), | ||
# UC12: Morph range wider than target, same grid density | ||
(np.linspace(-2, 20, 221), np.linspace(0, 10, 101)), | ||
] | ||
|
||
|
||
@pytest.mark.parametrize("x_morph, x_target", morph_target_grids) | ||
@pytest.mark.parametrize("squeeze_coeffs", squeeze_coeffs_list) | ||
def test_morphsqueeze(x_morph, x_target, squeeze_coeffs): | ||
y_target = np.sin(x_target) | ||
squeeze_polynomial = Polynomial(squeeze_coeffs) | ||
x_squeezed = x_morph + squeeze_polynomial(x_morph) | ||
y_morph = np.sin(x_squeezed) | ||
x_morph_expected = x_morph | ||
y_morph_expected = np.sin(x_morph) | ||
morph = MorphSqueeze() | ||
morph.squeeze = squeeze_coeffs | ||
x_morph_actual, y_morph_actual, x_target_actual, y_target_actual = morph( | ||
x_morph, y_morph, x_target, y_target | ||
) | ||
assert np.allclose(y_morph_actual, y_morph_expected) | ||
assert np.allclose(x_morph_actual, x_morph_expected) | ||
assert np.allclose(x_target_actual, x_target) | ||
assert np.allclose(y_target_actual, y_target) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it may be nice to have a usage example in the docstring. Basically copy-paste the code from the test to show how the morph can be instantiated and then used.
We normally put docstrings in the methods and in the constructor (the
def __init__():
). This class is inheriting the constructor from the base class, so I am not 100% sure how the docstring propagates through in the documentation, but without that, but I think if we put a docstring under thedef morph():
which is overloading that method from the base class, it should become clear.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I was following the architecture of other morphs. They have a docstring bellow the class which is the main description and then another docstring under the function which are few words. Should I keep it consistent?
When I add an example in the docstring do I add it as code using >>>?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have a group standard for this, but more recently I think we are leaning towards having the class-level docstring to be just a few words about the high level intent of the class and the docstring of the constructor to be have more detail. I did look into this question at one point and formed an opinion, but I don't fully remember what I found. It could have been when I was working on my beloved "DiffractionObject"s in diffpy.utils but I am not sure. We could look there. All documentation is better than lack of documentation, so the standards are just for us to figure out the most effective (user-useful) way to write the docs so that any time we spend on it has the most impact.