-
Notifications
You must be signed in to change notification settings - Fork 7
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
feat: add Hypatia2
pdf
#84
base: develop
Are you sure you want to change the base?
Conversation
Hi @qishi-hep. Thanks for making this.
|
Hi @ikrommyd, I modified the code according to your comments. The test again RooFit passed locally. You can have a look :) |
zfit_physics/models/pdf_hypatia2.py
Outdated
second_cond = tf.logical_and(tf.logical_and(x < 1.0e-04, nu > 0.0), nu < 55) | ||
third_cond = tf.logical_and(x < 0.1, nu >= 55) | ||
cond = tf.logical_or(first_cond, tf.logical_or(second_cond, third_cond)) | ||
return znp.where(cond, low_x_BK(nu, x), bessel_kv_func(nu, x)) |
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.
Slightly concerned about this one: Will the wrong numbers cause issues anywhere here, i.e. Nans in the bessel_kv_func?
The point is that both branches are evaluated, and while it's fine for the normal where, unfortunately the gradient can be affected by this (yep, annoying), as it's calculated by multiplying the not-used branch by 0. But this results again in NaNs.
Can we check the gradients of the function too? @ikrommyd we did that already in the past, didn't we? I just could not find the pdf, was it zfit?
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 didn't check gradients in ci. But I did that manually for the Faddeeva function. For PDFs so far we just knew that we weren't doing any operations that may cause this.
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.
Ah okay! Probably worth to add a check then
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.
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.
Great, thanks a lot for checking! Okay, yep, I guess we need again "safe values", do you remember how that works? We need to first create an array of arguments where the unused arguments, the ones that should not be taken and evaluate to NaNs are actually set to something harmless that does not produce anything wrong (i.e. a small, constant value). The value we use doesn't matter as we won't use it later on, since we use the where, but it's just not to screw up the gradient (i.e. the boolean to decide what goes where is gonna be used two times (or more)
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.
There is the safe_where
function in zfit.z
as well no?
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.
I added safe wheres but it doesn't fix the problem. Gradients are still nan. See 3b95ae2
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.
Maybe there is another problem somewhere else. I'll try to check again tomorrow.
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.
@qishi-hep There are some issues with the gradients. They start from tfp probably because the Bessel kve doesn't have a gradient with respect to one parameter. There may probably be places elsewhere that make the gradiends go nan. We'll debug and see what we can do about it.
Hi @qishi-hep thanks a lot for the PR and welcome to the contributors! It looks overall quite good to me. |
Looks good to me as well. I will add a little bit more testing and maybe a gradiends check. |
I think the main argument would be to be consintent with the CBs that we have, but that agrees with RooFits. The only inconsistency I se now is that we call it so fal |
Hmm, yeah I did the change to be consistent with the paper and add more tests, I can change a->alpha sure. |
... we can also change the other way around, all alphal -> al in the other PDFs, no strong feelings about it (but consistency could be nice, it seems like RooFit is inconsistetn here with CrystalBall vs Hypathia2) |
Thanks for the great changes 👍. For variable name, I think alphal is better, changing alphal to al in other PDFs can break a lot of existing code. |
10bba2e
to
99684eb
Compare
Hi @qishi-hep and @ikrommyd , I've added a feature in zfit to specify the parameters that support automatic gradients (by default all). If I remember correctly @ikrommyd , it was lambda that wasn't diffable? I've force pushed and rebased, as I've restructured the repos a bit. Make sure to first pull! |
7bdb6cc
to
25c0ee3
Compare
It's the first argument of |
Yes, I remember the same and that it was'nt realistically possible to get it right, and that's lambda propagated, afai can see |
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
25c0ee3
to
ee0bec5
Compare
Add
Hypatia2
pdf, two-sided version of the Hypatia distribution described in https://arxiv.org/abs/1312.5000, based on this snippetProposed Changes
zfit_physics/models/pdf_hypatia2.py
Tests added
tests/test_pdf_hypatia2.py
Checklist