Default priors in BEAUTi still lead to IMPROPER posterior

[GoogleCodeExporter]

CP*.mu and clock.rate still have improper priors that lead to improper 
(non-existent posteriors).   This is a critical problem.

Original issue reported on code.google.com by msuch...@gmail.com on 17 Jun 2010 at 3:26

[GoogleCodeExporter]

We can't produce a proper default prior for clock.rate because the scale of 
that parameter is *completely* unknown. It could be 1e-9 or 1 or 1e9 or 
something else entirely. Any even weakly informative default prior will lead to 
badness. I think we should just provide a very clear statement that the default 
[0, Double.MAX_VALUE] is very dangerous in the hand of a novice (especially 
with limited data) and that we strongly advise using an informative prior like 
lognormal or gamma with a high variance and a mean appropriate for the organism 
and units of rate employed. Walter is working on this.

Alexei

Original comment by dong.w.xie@gmail.com on 28 Jul 2010 at 12:28

• Added labels: 1.6, BEAUti

[GoogleCodeExporter]

CP*.mu should always be relative rates so should be possible to give an proper 
and reasonable prior on them.

Original comment by ramb...@gmail.com on 18 Aug 2010 at 12:36

[GoogleCodeExporter]

CP*.mu already have proper priors as a result of the operators maintaining 
their mean at 1. This is equivalent to a Dirichlet(1,1,...,1), scaled so that 
mean is 1 rather than the sum, and therefore its basically an Exponential(1) 
prior on each individual rate.

Original comment by alexei.drummond on 18 Aug 2010 at 12:39

[GoogleCodeExporter]

I have marked this as fixed for v1.6 as we now have explicit warnings about 
improper priors and mandated choice of prior for rates on partitions of size 1.

Original comment by ramb...@gmail.com on 10 Sep 2010 at 11:15

• Added labels: 1.5.4
• Removed labels: 1.6

[GoogleCodeExporter]

Original comment by ramb...@gmail.com on 10 Sep 2010 at 11:15

• Changed state: Fixed