FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Fix: let `DiffractionObject.get_array_index` to use `xtype` from its inputs. by ycexiao · Pull Request #356 · diffpy/diffpy.utils · GitHub

  1. diffpy
  2. diffpy.utils

Repository navigation

Fix: let DiffractionObject.get_array_index to use xtype from its inputs. - #356

Merged
sbillinge merged 3 commits into
diffpy:mainfrom
ycexiao:fix-get-array-index
Jul 25, 2025
ConversationCommits (3)ChecksFiles changed
Merged

Fix: let DiffractionObject.get_array_index to use xtype from its inputs.#356
sbillinge merged 3 commits into
diffpy:mainfrom
ycexiao:fix-get-array-index

Conversation

ycexiao commented Jul 25, 2025

Copy link
Copy Markdown
Contributor

What problem does this PR address

Closes #355

What should the reviewer(s) do

Please check the tests and implementation

ycexiao commented Jul 25, 2025
View reviewed changes

ycexiao left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

@sbillinge, the test code is ready for review.

Comment thread tests/test_diffraction_objects.py Outdated
0,
),
(
( # 2. different xtype

ycexiao Jul 25, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

There was a test for the function. I modified it so that it can capture the bug now.

ycexiao marked this pull request as ready for review July 25, 2025 15:27
sbillinge reviewed Jul 25, 2025
View reviewed changes

sbillinge left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

I feel that the unfinished discussion is the behavior that we want and the function signature. The way the docstring is written it should be get_array_index(value, xtype=None), i.e., value is required but xtype not. If xtype is None: xtype=_initial_xtype.

Arguably, we could make xtype required. I think that this may make sense. I am not sure the UC where it is implicit. What do you think?

Comment thread tests/test_diffraction_objects.py Outdated
( # C2: Target value lies in the array, expect the (first) closest
# index
# C2: Target value lies in the array, expect the closest index
( # 1. same xtype

sbillinge Jul 25, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

what does "same xtype" mean? same as what?

ycexiao Jul 25, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

It means that the xtype of the original DiffractionObject and the xtype of the data from which the get_array_index gets the array index are the same.

I will modify the comment.

sbillinge Jul 25, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

This may not need to be changed depending on the outcome of the discussion above. I am thinking that we may want to make both variables required. Do you know of a particular UC that requires the other? Do we now anywhere where this is being used actually?

ycexiao Jul 25, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Do you know of a particular UC that requires the other?

No. I think what the function does is to find the index. xtype is not actually needed.

And if users want to locate a specific q or tth that is different from the _input_xtype, they can use diff_obj.on_xtype("<xtype>"). Also, this might not be a common need.

Do we now anywhere where this is being used actually?

At least in diffpy.utils, it is not referenced. It is just a helper function we provide to users.

ycexiao commented Jul 25, 2025

Copy link
Copy Markdown
Contributor Author

Arguably, we could make xtype required. I think that this may make sense. I am not sure the UC where it is implicit. What do you think?

I think xtype should be optional. DiffractionObject keeps a property _input_xtype. The expected behavior is that when xtype is not specified, diffpy.utils will operate on the data in its original format.

sbillinge commented Jul 25, 2025

Copy link
Copy Markdown
Contributor

Arguably, we could make xtype required. I think that this may make sense. I am not sure the UC where it is implicit. What do you think?

I think xtype should be optional. DiffractionObject keeps a property _input_xtype. The expected behavior is that when xtype is not specified, diffpy.utils will operate on the data in its original format.

I guess my question is what is the UC for that? Why not make it explicit? Even if you want the index in the original quantity, you can specify it? I mean I made that up in the first place, but I don't really think I know why. Sometimes simpler is better.

sbillinge commented Jul 25, 2025

Copy link
Copy Markdown
Contributor

On reflection, let's leave it as it is. I don't think there is a strong reason to change it and I may have had a reason I wanted it that way.

sbillinge commented Jul 25, 2025

Copy link
Copy Markdown
Contributor

Next, for the tests, can we dynamically load a list of xtypes that will automatically update in the future as we add more? Is there a way to do that? It would be good if that list could also be dynamically loaded in the docstring.

ycexiao commented Jul 25, 2025

Copy link
Copy Markdown
Contributor Author

Next, for the tests, can we dynamically load a list of xtypes that will automatically update in the future as we add more? Is there a way to do that? It would be good if that list could also be dynamically loaded in the docstring.

Yes, we can. The allowed xtypes are stored in a variable, and we can use a format string to write those docstrings.

ycexiao commented Jul 25, 2025
View reviewed changes

ycexiao left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

@sbillinge, It's ready for review.

codecov Bot commented Jul 25, 2025 •
edited
Loading

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (93bc105) to head (eaeafe5).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files 
@@            Coverage Diff            @@
##              main      #356   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            9         9           
  Lines          516       520    +4     
=========================================
+ Hits           516       520    +4
Files with missing lines Coverage Δ
tests/test_diffraction_objects.py 100.00% <100.00%> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

sbillinge merged commit 44328a2 into diffpy:main Jul 25, 2025

sbillinge commented Jul 25, 2025

Copy link
Copy Markdown
Contributor

Thanks for catching that and fixing the tests to catch the bad case

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Show hidden characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

sbillinge sbillinge left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

fix: get_array_index ignores the input xtype

2 participants

Back | FazBrowse Home | New Git URL