-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Changed Categorical to work with multidim p at the logp level #3383
Conversation
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.
LGTM. Nicely done.
pymc3/distributions/discrete.py
Outdated
|
||
if p.ndim > 1: | ||
a = tt.log(p[tt.arange(p.shape[0]), value_clip]) | ||
# Fancy trick to index the last axis without touching the other | ||
a = tt.log((p.T)[value_clip].T) |
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 got to be a better way to do two transpose, right? If it is really necessary, maybe it is easier to do np.swapaxes
or np.moveaxes
?
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.
Yup, np.moveaxes
is the best option. I was not aware that it worked well with theano tensors too.
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.
Actually I didnt realized it works with np.moveaxes
as well. So it works well with theano tensor i take it - would it be better use tt.dimshuffle? http://deeplearning.net/software/theano/library/tensor/basic.html#dimshuffle
Oops, I reverted this commit (de91752) accidentally. Can you reopen? |
This should close #2082. However, there is one very important point that we need to discuss:
When should
Categorical.p
be normalized to sum to 1?We must do the normalization for backwards compatibility. But normalizing may hide negative values supplied into
p
. I did some changes tologp
to normalizep
there, but still check for the negative values that could have been set inself.p
, but those changes may break earlier codes that relied on the default normalization. I can't come up with a way to handle the edge cases put forward by @kyleabeauchamp, that contained negative values inp
, still do the normalization well, and also test for weird values set by step_methods proposals.