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

Allow relbin's fiducial parameters to not be floats #4987

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

cdcapano
Copy link
Contributor

Currently the Relative model tries to cast all of the reference parameters specified in the model section to floats. This is a problem if you want to pass in, say, a string (like a different approximant name than what's in the static params) or another parameter type to be passed to the waveform generartor. This patch fixes the issue by first checking if it's a boolean parameter, then catching any attempt to cast to float that fails.

for p in cp.options("model"):
if p.endswith("_ref"):
val = cp.get("model", p)
if val == '':
Copy link
Member

Choose a reason for hiding this comment

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

There's a couple places now where we try to do this str -> something python conversion. Maybe we should centralize this now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That would make sense. This should probably be added to the workflow config parser code, maybe as an kwarg to the various get_opt functions. Do you agree? We could also try to be more sophisticated. The code I wrote above won't distinguish between ints and floats, which can be a problem for some things (numpy functions will raise an error if you try to pass in floats where it expects ints, for example). We could try to follow the Python conventions; e.g., '5' -> int; '5.' -> float.

Copy link
Member

Choose a reason for hiding this comment

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

Well, if we add it to a parser, it should be the base InterpolatingConfigParser, but yeah, that approach makes sense, e.g. extend get_opt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants