Skip to content
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

CrossCorrelation Gives Strange Results #592

Closed
wendeborn8 opened this issue Sep 10, 2021 · 4 comments · Fixed by #647
Closed

CrossCorrelation Gives Strange Results #592

wendeborn8 opened this issue Sep 10, 2021 · 4 comments · Fixed by #647
Labels
good first issue If you're new to Stingray and want to contribute, start here. GSoC Great for students interested in GSoC to tackle. help wanted We need additional help with these issues!

Comments

@wendeborn8
Copy link

I am using Stingray's CrossCorrelation function to determine the time-lag between two light-curves, but am having some trouble.

As a simple case, if I calculate the time-lag between two identical light-curves, the result of stingray.crosscorrelation.time_shift depends on the number of data points. An odd number of points yields a time-shift of 0, as one would expect. However, an even number of points yields some fraction of the time sampling. This is also reflected when plotting the CrossCorrelation for various time lags.

Code to reproduce:

from stingray import Lightcurve as LC
from stingray.crosscorrelation import CrossCorrelation as XC

n = 15
dt = 1
times = np.arange(0, n * dt, dt)
data = np.sin(times)
lc = LC(times, data)
xc = XC(lc, lc) # CrossCorrelation of identical light-curves

print(xc.time_shift)

For any odd n, the result is 0. But for any even n, the result is >~0.5, getting closer to 0.5 for larger n. For n=2, the result is 1.0. The final result approximates half the value of dt.

Am I using/interpreting these functions incorrectly, or is Stingray doing something wrong here?

@matteobachetti
Copy link
Member

matteobachetti commented Sep 13, 2021

Thanks @wendeborn8 !
I think this is something unsurprising but nonetheless troubling :D
Unsurprising, because it is common for these methods to have corner cases based on the evenness/oddity of the input light curves.
Troubling, because we should account for them making the result as intuitive as possible for the users, and we thought we had done it right.
We'll investigate it. In the mean time, please consider a half step in those conditions as a zero lag.

@matteobachetti matteobachetti added good first issue If you're new to Stingray and want to contribute, start here. GSoC Great for students interested in GSoC to tackle. help wanted We need additional help with these issues! labels Feb 4, 2022
@mihirtripathi97
Copy link
Contributor

Working on this!

1 similar comment
@Ayushag1
Copy link

Working on this!

@mihirtripathi97
Copy link
Contributor

Working on this!

Hey, I have already almost done the work on this as commented earlier. Please find another issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue If you're new to Stingray and want to contribute, start here. GSoC Great for students interested in GSoC to tackle. help wanted We need additional help with these issues!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants