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
[sdba] Refactor interp_on_quantiles #941
Conversation
Last commits went deeper and refactored
Should we remove |
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.
Does it make sense to repurpose test_extrapolate_qm to test the new extrapolation code ? I know its implicitly tested elsewhere, but still.
The new extrapolation code is explicitly tested in I would rather suggest to remove |
All good then. |
…/xclim into indices/potential_evapotranspiration * 'indices/potential_evapotranspiration' of github.com:UCL/xclim: [sdba] Refactor interp_on_quantiles (Ouranosinc#941) Indices/heat index (Ouranosinc#915)
Pull Request Checklist:
number
) and pull request (:pull:number
) has been added.bumpversion patch
has been called on this branch.zenodo.json
What kind of change does this PR introduce?
I though the changes in #914 would address a bug I saw while computing ESPO-R. However, I had forgotten about the splitting pathways for
group='time'
vsgroup='time.prop'
. That also meant testing was not sufficient. This PR changesxclim.sdba.utils.interp_on_quantiles
so that:interp1d
, has the advantage that NaNs in the new coord are not considered "out of bounds", but NaNs. They return NaN in the output, not an extrapolated value.Does this PR introduce a breaking change?
Other information:
The docstring was improved.
I realized that
method='cubic'
does not respect the constant extrapolation as set byextrapolate_qm
... I added a note to the doc, but I'm not sure what to do here. @huard ? The logic we used works well with 'nearest' and 'linear', but as 'cubic' fetches a third point it estimates something else.EDIT:
I compared the performance before and after the change and it is insignificant.
griddata
andinterp1d
are much slower than any numpy overhead I added, so I did not see any timing difference.