See that negative -1.776357e-15 at ht$a[32]? There's the problem. Essentially its a floating point error: sometimes subtracting ht$t-ht$e produces a small negative value very close to 0 (that isn't zero), and when you take that to a power...
But that's a crazy kludge. There's probably better ways to deal with this floating value issue, but I'm not a good enough programmer to know them.
I haven't investigated very extensively, but its possible this issue affects other rescale.phylo models too, if they take the power of a different between ht$t-ht$e.
Hello all,
This only crops up with a small number of simulated trees I've encountered (maybe 5% of the time) so I'll include a reproducible example.
What's the problem you might ask? Look at the edge lengths.
Whoops! Where's that come from? I did a little tracking of the NaN value and it is produced early in the .delta.rescale code (https://github.com/mwpennell/geiger-v2/blob/master/R/utilities-phylo.R#L1595-L1601). Let's take a closer look...
See that negative -1.776357e-15 at
ht$a[32]
? There's the problem. Essentially its a floating point error: sometimes subtractinght$t-ht$e
produces a small negative value very close to 0 (that isn't zero), and when you take that to a power...You get NaNs.
One kludge to fix this would be to ask for the abs(), as apparently R doesn't mind taking the exponential of very tiny positive values so much.
But that's a crazy kludge. There's probably better ways to deal with this floating value issue, but I'm not a good enough programmer to know them.
I haven't investigated very extensively, but its possible this issue affects other rescale.phylo models too, if they take the power of a different between
ht$t-ht$e
.I hope this is helpful.