Sarah Lutteropp

The speedup potential of this is HUGE, as it will give us back true incremental loglikelihood computation in networks!!! :-) (Also, I already have an idea for a very ad-hoc...

Topologies like this one complicate things, due to not only reticulations, but also dead nodes. I have annotated the reticulation configurations for the displayed trees that need to be stored...

Done! It works nicely and is ready to be integrated into the master branch. :sunglasses:

Yes, but it gets downscaled by the displayed tree probability. This is the part that worries me.

I have the intuition that it would make more sense to not downscale the partition-loglikelihood by the probability of the best displayed tree it chose...

Especially, if we do not have number_of_partitions = number_of_displayed_trees. I expect that in a real-world dataset with unknown number of reticulation events, number_of_partitions can be much smaller than the number...

Yeah, probably people had a reason to put the inheritance probs into this definition... But about the partitions issue: - If we have only 1 partition in the MSA, then...

We also have to distinguish between the case of unlinked mode (each partition has its own branch lengths and reticulation probs) and linked mode (all partitions share the same branch...

Okay... I tried coming up with a counterexample, but failed. Starting to believe this definition now. LikelihoodType.BEST, 1 reticulation (i.e., 2 displayed trees), 2 partitions in the MSA: - displayed_tree_1...

In case of all partitions of the network choosing the same displayed tree, the loglikelihood value we get is not comparable to the loglikelihood value we would get with standard...