Hi Klaus,
I will add an option 'method' to this function so that its definition
will be:
is.ultrametric(phy, tol = .Machine$double.eps^0.5, option = 1)
option = 1 => using the criterion you suggested below
option = 2 => using the current 'variance' criterion
And other criteria could be
Hi Emmanuel,
it wasn't so much about the precision, but that it is not invariant against
linear transformation of the edge length.
At the moment the criterion inside is.ultrametric is the following:
var(xx[1:n])
where xx[1:n] is a vector with the tip-to-toot differences. And
is.ultrametric
Comparing floating point numbers is (at least for me) pretty scary when you get
down into it.
Here are some more accessible treatments (although Goldberg’s paper seems to be
the definitive treatment on the subject):
What Every Programmer Should Know About Floating-Point Arithmetic:
We should consider to improve is.ultrametric to use as tolerance a certain
number significant figures (e.g. 8-10 digits). This way tol would only
depend on the tip-to-root distance and not a machine dependent minimal
value. I find the use of significant figures suits really well as a
stopping
Actually I did play around with different tol values and I could get
is.ultrametric to recognize my tree. But, exactly as Joseph says, this doesn't
really help. Anyway, Liam's suggestion solved the problem.
Martin
Am 16.08.2016 um 16:22 schrieb Joseph W. Brown:
> That�s a good tip, but the
That’s a good tip, but the issue here is that many packages use is.ultrametric
internally with a hard-coded (likely, default) value of tol. In this case,
Martin simply cannot perform the analyses he wants to run because this option
is inaccessible.
JWB
Hello all,
this may come be surprising to many, but consulting the manual
?is.ultrametric can be helpful. Why not simply try e.g.
is.ultrametric(tree, tol=.01)
So in this sense RTFM
Regards,
Klaus
On Aug 16, 2016 9:31 AM, "Martin Dohrmann"
wrote:
>
> Am
Am 16.08.2016 um 15:20 schrieb Joseph W. Brown:
> I agree that it is almost certainly numerical precision, as rescaling the
> tree fixes things:
>
> > is.ultrametric(phy);
> [1] FALSE
> > fie <- phy;
> > fie$edge.length <- fie$edge.length * 0.1;
> > is.ultrametric(fie);
> [1] TRUE
>
> I�ve
I agree that it is almost certainly numerical precision, as rescaling the tree
fixes things:
> is.ultrametric(phy);
[1] FALSE
> fie <- phy;
> fie$edge.length <- fie$edge.length * 0.1;
> is.ultrametric(fie);
[1] TRUE
I’ve also tested the ultrametricity(?) with a non-R program and the results are
Thanks a lot, that did the trick!
(the last line should read "is.ultrametric(nnls)" though)
Best wishes,
Martin
Am 16.08.2016 um 14:53 schrieb Liam J. Revell:
> Hi Martin.
>
> Since you are writing & reading trees to file, my guess is that it has to do
> with numerical precision - that is,
Hi Martin.
Since you are writing & reading trees to file, my guess is that it has
to do with numerical precision - that is, the rounding of your edge
lengths when they are written to file.
Does your tree look ultrametric when plotted in R? If so, this is
probably the case.
My
11 matches
Mail list logo