-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overlap function #13
Comments
Hi Andrew, I have also found this exact problem and desperately need to calculate the overlap area between two standard ellipses for my PhD thesis. I had performed this before on the old siar but cannot now re-do the analyses. Is there any way to do this in SIBER? Many thanks, Georgina |
hi both i have added some example code in a new vignette in the development release hope that helps best wishes andrew On 16 August 2016 at 12:29, GeorginaBusst notifications@github.com wrote:
*You can now follow SIAR Dr Andrew Jackson |
Hi,
If I am wrong please correct me. Cheers, |
Yes, SarinaJ, I believe you're correct for both. I have an additional issue: In determining the coordinates for each ellipse (lines 74-93), I get an error message indicating that “small.sample” and “do.plot” are not graphical parameters. More generally, I can’t figure out how one would even apply the sample-size correction in determining the coordinates of the ellipse. That is, it makes sense to me that one can multiple SEA by (n-1)/(n-2) to get SEAc (i.e. correcting the overall area). However, I don’t see how one would apply the correction to infer the new coordinates (i.e. of the ellipse corresponding to SEAc). Thanks |
hi Sarina thanks for pointing out those two mistakes. i have fixed them in the vignette on github. You can get overlaps greater than 1 as they are expressed in units squared, which in isotope spave would be permil^2. They only become less than one if you make them a proportion of something. mark: im not entirely sure, but i suspect you are running this vignette on an older version of SIBER. Install from github which hopefully has the newer versions of the plotting functions. |
Hi Andrew, I do have a follow-up question though: Thanks!
|
Hi mark
This is very useful having you looking at that code as I'm uploading. I will check but may not get to it today.
I can't remember but the correction should be square rooted for one of them and maybe I forgot. Else, if it's off by only a small amount it could be the computational method rather than analytic. Bumping up n in call to maxlikOverlap might fix that. If that's a thing
Best wishes
Andrew
… On 21 Feb 2017, at 05:56, Mark Novak ***@***.***> wrote:
Hi Andrew,
Thanks for the super speedy reply! You must be in the midst of uploading fixes, 'cuz the two errors I reported are indeed gone and the new maxLikOverlap is very convenient (and I now see how the sample size correction is implemented in determining the coordinates).
I do have a follow-up question though:
Looking at the code for maxLikOverlap it appears that the default is for the sample size correction to be performed. Hence, shouldn't the areas given by maxLikOverlap be the same (or similar to) the results of SEAc from groupMetricsML for a given p.interval (incl. NULL)? It looks like they're in between, but generally closer to SEA. Apologies if I'm misunderstanding something basic, but is it simply that applying the (n-1)/(n-2) correction directly to SEA (to get SEAc) is not quite the same as applying it to the eigenvalues? Or is it something to do with the scaling of the sigma before determining the eigenvalues? (Or am I off track completely?)
Thanks!
groupMetricsML(siber.example)
1.1 1.2 1.3 2.1 2.2 2.3
TA 21.924922 10.917715 17.945127 3.0714363 11.476354 1.4818061
SEA 5.783417 3.254484 5.131601 0.8623300 3.458824 0.4430053
SEAc 5.989967 3.370715 5.314872 0.8931275 3.582354 0.4588269
maxLikOverlap("1.2", "1.3", siber.example, p.interval = NULL, n = 100)
area.1 area.2 overlap
3.28548611 5.18048437 0.06872133
maxLikOverlap("1.1", "2.2", siber.example, p.interval = NULL, n = 100)
area.1 area.2 overlap
5.838510 3.491773 0.000000
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
hi again
it does look like its the computational vs analytic estimates of area, but
annoyingly it seems to be converging on the SEA and not the SEAc... more
hunting required
sdd <- createSiberObject(demo.siber.data)
ml <- groupMetricsML(sdd)
maxLikOverlap("1.2","1.3",sdd, p.interval=NULL, n = 1080)
cheers
andrew
On 21 February 2017 at 07:54, Jackson.andrew.lloyd@gmail.com <
a.jackson@tcd.ie> wrote:
… Hi mark
This is very useful having you looking at that code as I'm uploading. I
will check but may not get to it today.
I can't remember but the correction should be square rooted for one of
them and maybe I forgot. Else, if it's off by only a small amount it could
be the computational method rather than analytic. Bumping up n in call to
maxlikOverlap might fix that. If that's a thing
Best wishes
Andrew
On 21 Feb 2017, at 05:56, Mark Novak ***@***.***> wrote:
Hi Andrew,
Thanks for the super speedy reply! You must be in the midst of uploading
fixes, 'cuz the two errors I reported are indeed gone and the new
maxLikOverlap is very convenient (and I now see how the sample size
correction is implemented in determining the coordinates).
I do have a follow-up question though:
Looking at the code for maxLikOverlap it appears that the default is for
the sample size correction to be performed. Hence, shouldn't the areas
given by maxLikOverlap be the same (or similar to) the results of SEAc
from groupMetricsML for a given p.interval (incl. NULL)? It looks like
they're in between, but generally closer to SEA. Apologies if I'm
misunderstanding something basic, but is it simply that applying the
(n-1)/(n-2) correction directly to SEA (to get SEAc) is not quite the same
as applying it to the eigenvalues? Or is it something to do with the
scaling of the sigma before determining the eigenvalues? (Or am I off track
completely?)
Thanks!
groupMetricsML(siber.example)
1.1 1.2 1.3 2.1 2.2 2.3
TA 21.924922 10.917715 17.945127 3.0714363 11.476354 1.4818061
SEA 5.783417 3.254484 5.131601 0.8623300 3.458824 0.4430053
SEAc 5.989967 3.370715 5.314872 0.8931275 3.582354 0.4588269
maxLikOverlap("1.2", "1.3", siber.example, p.interval = NULL, n = 100)
area.1 area.2 overlap
3.28548611 5.18048437 0.06872133 <(068)%2072133>
maxLikOverlap("1.1", "2.2", siber.example, p.interval = NULL, n = 100)
area.1 area.2 overlap
5.838510 3.491773 0.000000
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#13 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADK1sOa5p21fDkSKgbU6uR3YvKMuk-L0ks5renx4gaJpZM4G11Az>
.
--
*You can now follow SIAR
<http://www.facebook.com/pages/SIAR-Stable-Isotope-Analysis-in-R/148501811896914>
on Facebook or try my video podcasts
<http://www.tcd.ie/Zoology/research/research/theoretical/Rpodcasts.php> for
R
Dr Andrew Jackson
Associate Professor
School of Natural Sciences
Zoology Building, Trinity College Dublin, Dublin 2, Ireland
Tel. + 353 1 896 2728, Fax. + 353 1 677 8094, Email. a.jackson@tcd.ie,
Twitter: @yodacomplex <https://twitter.com/yodacomplex>
http://www.tcd.ie/Zoology/research/research/theoretical/AndrewJackson.php
|
got it
there was a bug in the new addEllipse function which was incorrectly using
the number of points to draw the circle "n", rather than the sample size of
the data "m" when calculating the small sample size correction.
thanks for your help picking this up
andrew
…On 21 February 2017 at 08:16, Andrew Jackson ***@***.***> wrote:
hi again
it does look like its the computational vs analytic estimates of area, but
annoyingly it seems to be converging on the SEA and not the SEAc... more
hunting required
sdd <- createSiberObject(demo.siber.data)
ml <- groupMetricsML(sdd)
maxLikOverlap("1.2","1.3",sdd, p.interval=NULL, n = 1080)
cheers
andrew
On 21 February 2017 at 07:54, ***@***.*** <
***@***.***> wrote:
> Hi mark
>
> This is very useful having you looking at that code as I'm uploading. I
> will check but may not get to it today.
>
> I can't remember but the correction should be square rooted for one of
> them and maybe I forgot. Else, if it's off by only a small amount it could
> be the computational method rather than analytic. Bumping up n in call to
> maxlikOverlap might fix that. If that's a thing
>
> Best wishes
> Andrew
>
> On 21 Feb 2017, at 05:56, Mark Novak ***@***.***> wrote:
>
> Hi Andrew,
> Thanks for the super speedy reply! You must be in the midst of uploading
> fixes, 'cuz the two errors I reported are indeed gone and the new
> maxLikOverlap is very convenient (and I now see how the sample size
> correction is implemented in determining the coordinates).
>
> I do have a follow-up question though:
> Looking at the code for maxLikOverlap it appears that the default is for
> the sample size correction to be performed. Hence, shouldn't the areas
> given by maxLikOverlap be the same (or similar to) the results of SEAc
> from groupMetricsML for a given p.interval (incl. NULL)? It looks like
> they're in between, but generally closer to SEA. Apologies if I'm
> misunderstanding something basic, but is it simply that applying the
> (n-1)/(n-2) correction directly to SEA (to get SEAc) is not quite the same
> as applying it to the eigenvalues? Or is it something to do with the
> scaling of the sigma before determining the eigenvalues? (Or am I off track
> completely?)
>
> Thanks!
>
> groupMetricsML(siber.example)
> 1.1 1.2 1.3 2.1 2.2 2.3
> TA 21.924922 10.917715 17.945127 3.0714363 11.476354 1.4818061
> SEA 5.783417 3.254484 5.131601 0.8623300 3.458824 0.4430053
> SEAc 5.989967 3.370715 5.314872 0.8931275 3.582354 0.4588269
>
> maxLikOverlap("1.2", "1.3", siber.example, p.interval = NULL, n = 100)
> area.1 area.2 overlap
> 3.28548611 5.18048437 0.06872133 <(068)%2072133>
>
> maxLikOverlap("1.1", "2.2", siber.example, p.interval = NULL, n = 100)
> area.1 area.2 overlap
> 5.838510 3.491773 0.000000
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#13 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ADK1sOa5p21fDkSKgbU6uR3YvKMuk-L0ks5renx4gaJpZM4G11Az>
> .
>
>
--
*You can now follow SIAR
<http://www.facebook.com/pages/SIAR-Stable-Isotope-Analysis-in-R/148501811896914>
on Facebook or try my video podcasts
<http://www.tcd.ie/Zoology/research/research/theoretical/Rpodcasts.php> for
R
Dr Andrew Jackson
Associate Professor
School of Natural Sciences
Zoology Building, Trinity College Dublin, Dublin 2, Ireland
Tel. + 353 1 896 2728 <(01)%20896%202728>, Fax. + 353 1 677 8094
<(01)%20677%208094>, Email. ***@***.***,
Twitter: @yodacomplex <https://twitter.com/yodacomplex>
http://www.tcd.ie/Zoology/research/research/theoretical/AndrewJackson.php
--
*You can now follow SIAR
<http://www.facebook.com/pages/SIAR-Stable-Isotope-Analysis-in-R/148501811896914>
on Facebook or try my video podcasts
<http://www.tcd.ie/Zoology/research/research/theoretical/Rpodcasts.php> for
R
Dr Andrew Jackson
Associate Professor
School of Natural Sciences
Zoology Building, Trinity College Dublin, Dublin 2, Ireland
Tel. + 353 1 896 2728, Fax. + 353 1 677 8094, Email. a.jackson@tcd.ie,
Twitter: @yodacomplex <https://twitter.com/yodacomplex>
http://www.tcd.ie/Zoology/research/research/theoretical/AndrewJackson.php
|
You rock, Andrew! Thanks again for the quick and helpful replies. I have, however, found another bug for you...just a simple typo though! (One that SarinaJ noted, but that seems not to have made it into the new It's in the final section of the function that uses thanks
|
Doh! Thanks again. I just pushed to cran last night. Will have to push a quick hot fix later.
… On 22 Feb 2017, at 05:52, Mark Novak ***@***.***> wrote:
You rock, Andrew! Thanks again for the quick and helpful replies.
I have, however, found another bug for you...just a simple typo though! (One that SarinaJ noted, but that seems not to have made it into the new bayesianOverlap function.)
It's in the final section of the function that uses spatstat. You've got coord.2 referenced three times when I think you want the first reference to be coord.1.
thanks
Here's your full function (as currently written) for reference:
> bayesianOverlap
function (ellipse1, ellipse2, ellipses.posterior, draws = 10,
p.interval = 0.95, n = 100, do.plot = FALSE)
{
if (is.null(draws))
draws = nrow(ellipses.posterior[[1]])
out <- data.frame(area1 = double(draws), area2 = double(draws),
overlap = double(draws))
for (i in 1:draws) {
coords.1 <- addEllipse(ellipses.posterior[[ellipse1]][i,
5:6], matrix(ellipses.posterior[[ellipse1]][i, 1:4],
nrow = 2, ncol = 2), p.interval = p.interval, n = n,
do.plot = do.plot, small.sample = FALSE)
area.1 <- hullArea(coords.1[, 1], coords.1[, 2])
coords.2 <- addEllipse(ellipses.posterior[[ellipse2]][i,
5:6], matrix(ellipses.posterior[[ellipse2]][i, 1:4],
nrow = 2, ncol = 2), p.interval = p.interval, n = n,
do.plot = do.plot, small.sample = FALSE)
area.2 <- hullArea(coords.2[, 1], coords.2[, 2])
overlap <- abs(spatstat::overlap.xypolygon(list(x = coords.1[,
1], y = coords.2[, 2]), list(x = coords.2[, 1], y = coords.2[,
2])))
out[i, 1:3] <- c(area.1, area.2, overlap)
}
return(out)
}
<environment: namespace:SIBER>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
hi Mark. I just pushed a hotfix to the master branch on github. I will have to wait a couple of days to push to CRAN. hopefully thats all the big bugs for now! thanks very much again for the help. |
all well under v2.1.999 |
Works like a charm. Thanks! |
I am having problem with the new overlap code. Error: 'overlap.xypolygon' is not an exported object from 'namespace:spatstat' |
I'm also having problems running the code from the niche overlap vignette and receive the same Error: 'overlap.xypolygon' is not an exported object from 'namespace:spatstat' R is up to date (version 3.3.3) and I've also tried stalling spatstat.utils Any pointers greatly appreciated. |
I wanted to rerun my script as well as I got some comments back from my supervisors and I got this one as well. The Problem lies within the function of the SIBER package that references back to spatstat directly and as @Perko84 pointed out the function 'overlap.xypolygon' is no longer part of this package but is outsourced to 'spatstat.utils'. When you look at the R code here on GitHub you can find the updated version of the function. I therefore installed the latest development version (see welcome page of SIBER) and it is working again. |
Hello there! I want to estimate the overlap between ONLY two species and express it as a proportion, but I’m not sure if I’m doing right, especially when assigning the denominator in the last step of the script. Could someone please check where (or if) I got wrong? Instead of getting ‘overlap’ in the end of the script I got ‘area.2’. Thanks in advance for any help!
area.1 area.2 overlap
area.1 area.2 overlap
area.2 |
Hi Andrew, I want to estimate the overlap between two groups, I was using the "maxLikOverlap" but then i got confused when I saw another example using only "overlap", so I wanted to know if they are the same function... I hope you can help me, thank you! |
Hi, just wondering if the overlap function only works for ellipses? What about convex hulls? Is it possible to calculate the overlapped area between convex hulls? Thanks in advance! |
Hi
As currently written it only works on ellipses and not hulls.
Best wishes
Andrew
…--
Dr Andrew Jackson, PhD, FTCD
Associate Professor
Irish Research Council Laureate
School of Natural Sciences, Department of Zoology
Trinity College Dublin, the University of Dublin
Dublin 2, Ireland.
+353 1 896 2728 | a.jackson@tcd.ie<mailto:a.jackson@tcd.ie>
Twitter: @yodacomplex<https://twitter.com/yodacomplex>
http://www.tcd.ie/Zoology/research/<http://www.tcd.ie/Zoology/research/groups/jackson/>groups/jackson/
From: christina-cheung <notifications@github.com>
Reply to: AndrewLJackson/SIBER <reply@reply.github.com>
Date: Wednesday 5 February 2020 at 10:35
To: AndrewLJackson/SIBER <SIBER@noreply.github.com>
Cc: Andrew Jackson <JACKSOAN@tcd.ie>, State change <state_change@noreply.github.com>
Subject: Re: [AndrewLJackson/SIBER] Overlap function (#13)
Hi, just wondering if the overlap function only works for ellipses? What about convex hulls? Is it possible to calculate the overlapped area between convex hulls? Thanks in advance!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub<#13?email_source=notifications&email_token=AAZLLMDEPPWPBNG7NUTLAGLRBKI7HA5CNFSM4BWXKAZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK257KA#issuecomment-582344616>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAZLLMFAQ6TFIRP73QOKLDLRBKI7HANCNFSM4BWXKAZQ>.
|
Thank you for your quick reply!! |
Hi Andrew,
Is the overlap function included in the standalone SIBER package? I received the following error when trying the original overlap code:
thanks,
Harri
The text was updated successfully, but these errors were encountered: