You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @champost. Nathan has just been running into a strong inconsistency within DECX output, currently flawing his PhD manuscript. He has been able to reproduce with the following reduced analysis: Pipridae.zip [Harvey 2020]
The problem in this example is that some ancestral nodes are being inferred to range in regions that were not supposed to exist at all at the time. Here for instance, the region labeled DC is supposed not to exist prior to 11Ma according to the adjacency matrices, but the model finds it likely that ancestral node number 98 (age 11.6406Ma) was ranging over AM_AF_DC.
I have reverted the project to commit 68a5a1b to assert that this behaviour was already present then. Today in d8b390a, I have featured a special --check-considered-ranges-detail argument to display the detail of RateModel::incldists_per_period. ASAIU, the faulty region does not appear within these "considered ranges", which makes it very surprising that it eventually ends up ranked as one of the most likely guesses from DECX.
Are the model constraints specified with the adjacency matrices supposed to be absolutely respected? Or are they just smooth indications given to the optimizer? If they are supposed to be hard constraints, then I believe the above behaviour is a bug.
I have worked so far on improving the program interface and portability, and never actually had to open up the underlying DEC implementation which we've been just trusting. Now that we are finding a suspicious behaviour within it, I have no code documentation or rigourous tests suite to rely on and to help me track this down. Maybe your input would be helpful here because you authored it? Otherwise, I would have to read through the old codebase, and through Ree 2005, Ree 2008 and your preprint to get a sense of the problem and I unfortunately don't have the bandwidth to get this deep into it :\
The text was updated successfully, but these errors were encountered:
Hi @champost. Nathan has just been running into a strong inconsistency within DECX output, currently flawing his PhD manuscript. He has been able to reproduce with the following reduced analysis: Pipridae.zip [Harvey 2020]
The problem in this example is that some ancestral nodes are being inferred to range in regions that were not supposed to exist at all at the time. Here for instance, the region labeled
DC
is supposed not to exist prior to 11Ma according to the adjacency matrices, but the model finds it likely that ancestral node number 98 (age 11.6406Ma) was ranging overAM_AF_DC
.I have reverted the project to commit 68a5a1b to assert that this behaviour was already present then. Today in d8b390a, I have featured a special
--check-considered-ranges-detail
argument to display the detail ofRateModel::incldists_per_period
. ASAIU, the faulty region does not appear within these "considered ranges", which makes it very surprising that it eventually ends up ranked as one of the most likely guesses from DECX.Are the model constraints specified with the adjacency matrices supposed to be absolutely respected? Or are they just smooth indications given to the optimizer? If they are supposed to be hard constraints, then I believe the above behaviour is a bug.
I have worked so far on improving the program interface and portability, and never actually had to open up the underlying DEC implementation which we've been just trusting. Now that we are finding a suspicious behaviour within it, I have no code documentation or rigourous tests suite to rely on and to help me track this down. Maybe your input would be helpful here because you authored it? Otherwise, I would have to read through the old codebase, and through Ree 2005, Ree 2008 and your preprint to get a sense of the problem and I unfortunately don't have the bandwidth to get this deep into it :\
The text was updated successfully, but these errors were encountered: