speaker-0: How how did you end up implementing that? Like are you using vanilla GPs, are you using approximations? How is the how are you handling the the speed and efficiency side of the GP sampling?

speaker-1: Yeah, there there's a couple of ways. At the moment, the GPs are still exact, and that's simply because so far most of the data sets that I've come across haven't been crazy in the number of sites that they have. So often you'll have like hundred or a few hundred, which I feel still works well for an exact GP. ⁓ also I have built in a feature where often we'll have different grids of cameras in different locations. So essentially independent grids. And when I have independent grids, it does a separate smaller GP for each region, which just assumes that the regions are independent. They still share the same hyperparameters, but you don't need to construct a full covariance matrix. You do it by region. So if you have a thousand cameras in your data set, that would be an expensive GP to compute. But if those thousand cameras are split between ten different grids, then you've got ten smaller ones, which is actually way easier to manage. And it is definitely ⁓ something I wanna add is some form of a ⁓ approximation and someone recently told me about GP tools, which is a a I think it's some sort of package that's implemented in Stan that lets you ⁓ base I think I wanna say it's Fourier transform GPs. ⁓ but some sort of approximation for the inevitable case that you do have a huge data set where you actually need a massive covariance matrix.

speaker-0: Hm. Yeah. Yeah, I don't know GP tools per se, but maybe they're using HSGP under the hood most of the time. ⁓ if you're in a maximum three D case for GP, that's gonna be that's gonna be extremely helpful. and so for spatial temporal data, should work because that's three D. ⁓ and that's yeah, same flavor as if we transfer. And that really is ⁓ really is a game changer for big data set because it just becomes almost linear in in compute time with ⁓ with your data data size. So that's

speaker-1: Yeah, no, I I I do have code laying around 'cause I've implemented them in the past for the HS G P stuff, so it's it's honestly probably something that will be in the package in the next month or so.

speaker-0: Mm-hmm. Yeah. Yeah. I mean that's really ⁓ that's really helpful. I mean if most of your data set are not too big, that's awesome. You know, that means you can't use exact GPs. ⁓ this is rare, but ⁓ this is this is great to hear that is that is possible.

speaker-1: It's not that rare in camera trapping because just most most of the time people are bottlenecked by by resources and ⁓ I think it would be not uncommon to have a data set of thousands of cameras. I do think it would be unusual for all of them to be part of the same grid as opposed to ⁓ split into multiple smaller grids where you can actually just do them separately within each region. But even there the approximations would ⁓ end up being faster, I'm sure. So ⁓ worth implementing regardless.

speaker-0: I mean yeah, I mean depends on the approximation because you have some approximations that actually work less well than a vanilla GP if the data set's not big enough. So, you know, kind of like ⁓ central limit theorem kind of stuff where it's if you're not in the regime where the approximation ⁓ accuracy kicks in, then you actually want the vanilla GP. So You can use the vanilla GP, just do that.

speaker-1: I've actually

speaker-0: It's like you you have the mathematical guarantee and and that's great. In my case that's been super rare. Like most of the time I cannot use vanina GPs and I've had to use approximations and thankfully there are some now. And also the compute we can use is just so much better now.