There are some places in the pygwb pipeline and modules where we are using the word 'integrand.' The point estimate and sigma quantities defined at each frequency in the old Matlab codes are 'integrands' while in the pygwb they are 'estimates'. The difference is that the 'integrand' value at each frequency in the old format does not truly reflect the quantity we are trying to estimate (only the value 'integrated' over all frequencies corresponds to the quantities of interest) while in pygwb at each frequency it actually corresponds to the quantity we are trying to estimate. So, I think we should avoid using the word 'integrand', unless it actually corresponds to the integrand.
There is one place where we actually need the integrand, which is the compute_ifft_integrand
in statistical_checks
module. The function actually needs the integrand to calculate IFFT. Since we have not made the distinction, we are actually feeding the 'estimates' to it. When correctly done, The zero-lag value of the IFFT should correspond to the final point estimate we get from our analysis. In general, the fluctuations in the IFFT plot should be on the same scale as the final point estimate (for noise-dominated cases). Also, the std of the IFFT should be close to the final sigma we get. However, currently, they differ by orders of magnitude. To fix this, we have to calculate the integrands and then pass them to compute_ifft_integrand
. However, I do believe that the qualitative picture provided by the current compute_ifft_integrand
is still reasonable.