Remove the LogLikelihood class

[MichaelClerx]

It doesn't add any functionality, just indicated that a certain LogPDF is intended as a LogLikelihood.

In some cases, we test to see if something is a LogLikelihood, but I'm wondering if those checks shouldn't be replaced by a check to see if it's just any old LogPDF...

[martinjrobins]

I can't see any reason to keep LogLikelihood, its only in there since we didn't have a LogPDF at the time I think.

[mirams]

I would be expecting a pdf to integrate to one, but not a likelihood...

[MichaelClerx]

https://pints.readthedocs.io/en/latest/log_pdfs.html

Nothing needs to sum to 1 in Pints! We do say that a PDF probably doesn't, and a Prior probably does, but that's about it.

[MichaelClerx]

More importantly, why were you two discussing this on a sunday night before a bank holiday :p

[ben18785]

I like keeping it because it is part of the (classical and Bayesian) inference process.

[MichaelClerx]

I'm still on the fence! Notice how I left it out in yesterday's diagram and nobody complained...

[martinjrobins]

I'm in favour of getting rid of it. all the likelihoods are still being called that (e.g. KnownNoiseLogLikelihood), but there is no sense keeping LogLikelihood around if it doesn't actually do anything.

[sanmitraghosh]

@MichaelClerx I think the the functionality is important, thus externally a user can access the likelihood explicitly as well as internally (I have done this in the power_posterior branch where I have raised the likelihood to the power) inside an algorithm such as smc. You can get rid of a separate class as long as this functionality is intact.

[mirams]

Can we just rename logPDF to logLikelihood if the thing really is a non-normalised likelihood and not a PDF? Or would it be too confusing to consider priors and posteriors to inherit from (be special cases of) a likelihood @ben18785 I know likelihood has a special meaning in terms of data|model and model|data for Bayesians?