The existing setup for discrete trait analyses is to simply log the relative rate and rate indicator parameters. This is a problem for two reasons:
The parameter indices are difficult to interpret when the trait can take many values, especially when symmetric rate matrices are enforced. (The expressions for determining the row and column of the rate matrix element that correspond to given parameter index require some thought.)
I think we should avoid letting users access the rate parameters and the rate indicators separately. This separation is an inference method detail and it is easy to get the wrong idea by looking at the rate parameter posterior without considering the indicator variables. We should only ever log the product imo.
This commit includes a logger that logs this product, as well as providing sensible log file headings for the rate matrix elements. These can either include the actual trait/location names (default):
or they can be integer location codes:
I've modified the BEAUti template to include this logger. I've left in the raw parameter loggers for now, but it would be great if we could remove these at some stage. (See point 2 above.)
The existing setup for discrete trait analyses is to simply log the relative rate and rate indicator parameters. This is a problem for two reasons:
This commit includes a logger that logs this product, as well as providing sensible log file headings for the rate matrix elements. These can either include the actual trait/location names (default):
or they can be integer location codes:
I've modified the BEAUti template to include this logger. I've left in the raw parameter loggers for now, but it would be great if we could remove these at some stage. (See point 2 above.)