"The Yule model is not particularly suitable for linguistic analyses, however it is currently the best BEAST has to offer."

[SimonGreenhill]

"The Yule model is not particularly suitable for linguistic analyses, however it is currently the best BEAST has to offer."

[SimonGreenhill]

you should discuss this with Denise while you're in Jena.

[Anaphory]

Fair! Do you know anything apart from Taraka Rama's paper that explicitly looks at tree priors suitable for linguistics?

I have Beastling code for (F?)BD priors and uniform priors, and I used it in our TAP phylogenetics paper. I think it's in here already. It may need testing, but it definitely needs that bit of the documentation updated. Maintaining up-to-date documentation is just so hard…

[SimonGreenhill]

Sure, If you assume Yule, you assume (a) complete sampling of all languages, (b) no extinction (=no dead tips). Both of which are dubious. There's plenty of work outside linguistics evaluating these, so no need for Taraka's paper. In principle one of the BD models is always more correct, probably the BD contemp, if not the FBD.

[Anaphory]

Yes, even deducing from first principles Yule is a special case of *BD priors with additional axioms that we should not assume. I didn't mean to deny that.

I was thinking that given that this means we do want to add tree priors and change defaults, do we have any evidence what our new default should be, and which tree priors are worth implementing? What would be the most appropriate prior?

[lmaurits]

I'm very open to changing the default tree prior if there is something currently implemented in BEAST which can be convincingly argued as better than Yule, and I'm inclined to agree that a BD model fits that bill. My original idea was always that BEASTling's default model decisions would be updated to track what seemed to be the consensus best practice as the field developed, so that people could just bring a dataset (ideally CLDF!) to the party and get something state-of-the-art or close to it (although the defaults do skew toward simplicity/minimalism as well - I'm not averse at all to us maintaining a fuller-flavoured "state of the art template" configuration that people can use by e.g. changing the data filename and adding some calibrations).

Gereon, it does look like your code for BirthDeathGernhard08Model is already in develop. I'm happy to help with testing and documentation if we want to make an effort to get this into the mainstream sooner rather than later? If we can also come up with a good solution to the CLDF problems I recently raised, it might even be worth cutting a new release sometime soonish? Most of the open 1.5.0 Issues are "only" test related...

[lmaurits]

Will do. As of yesterday, birth-death tree priors can now be used by specifying tree_prior = birthdeath in the [languages] section, so at least we are no-longer Yule only.

[Anaphory]

I have also just implemented a fossilized birth death prior, which would be a better prior for calibrated tips than coalescent, so I would also be happy to remove coalescent as fallback and only add it when really explicitly asked for. (That would definitely be a breach of API and require going to version 2.X.X.)