DOCS - Adding in explanation of counter intuitive behaviour of Logp

[springcoil]

I've screwed up this branch - definitely don't merge yet.

• Fixed now.

[springcoil]

@junpenglao I'm a bit confused about the documentation - do I submit the ipynb with the cells run or does someone else run them?

[junpenglao]

I think you should submit with the cell run, @twiecki?

[springcoil]

I'll submit with the cell run then.

[junpenglao]

LGTM.

[springcoil]

cc - #2489

[twiecki]

Definitely need the outputs.

[springcoil]

Thanks @twiecki I just ran it now. I wasn't sure if we did or not.

[twiecki]

LGTM.

[springcoil]

Going to merge it in now once the checks complete :)

[ferrine]

What about having fn cache that is cleaned after new var is added?

[springcoil]

Hmm that might work - do you have a toy example to illustrate?

[aseyboldt]

I think it is cleaner to return objects that encapsulate the functions. There is also other state to keep track of, for example the mapping between array space and dict space. When we add more variables, the meaning of an array changes. That is cleaner if it is all part of a separate object, that itself is immutable. It also makes it much easier to see where something is compiled, which makes tracking down errors or slowdown easier. Something like model.logp_dlogp_function().