Errors in uncertainty calculations

[nbrunett]

I think there are some errors in the way uncertainties are calculated on the cloud properties. I'm sorry I don't have more time to check these right now, but here is what I found. It's roughly ordered from what I'm more confident is incorrect to less. These are all in cloudalyze.py.

1. RAD_UC, RAD_NODC_UC, RAD_NOEX_UC, and RAD_NODC_NOEX_UC combine rmsx_* with itself in quadrature instead of rmsx_* with rmsy_*.
2. The uncertainty on the virial mass (line 431) should multiply the velocity dispersion uncertainty by 4, not 2. thiscloud["MVIR_UC"] = np.sqrt(thiscloud["RAD_UC"] ** 2 + 4 * thiscloud["SIGV_UC"] ** 2)
3. Should the uncertainties on the deconvolved quantities be multiplied by an extra factor from the deconvolution compared to the non-deconvolved versions?
   • E.g. the relative uncertainty on SIGV_KMS would be ((moments_rot['rmsv_ex'] * dv ** 2) / (moments_rot['rmsv_ex'] ** 2 * dv ** 2 - sigchan_kms ** 2)) * uc_dict['rmsv_ex'].
4. I think ucval and ucval_rot (lines 398 and 401) are supposed to be the relative standard error on the median. If that's right then here are a couple points.
   • Shouldn't the number of pixels per beam be replaced with the number of bootstrap samples?
   • Also, I think for the standard error on the median it should be np.sqrt(np.pi / 2) * (1 / np.sqrt(N + 2)) * (std / median) (from the approximation here, but could probably be improved with equation 2 here).

[low-sky]

Thanks @nbrunett (and sorry for the delay in responding). I've fixed 1 and 2 in db3ca6b

Re 3, maybe? We haven't done the full analysis of cloud errors yet to see if this is justified. Given the deconvolution is nominally perfectly known, this shouldn't change a fractional uncertainty. However, you can do this postdoc by scaling the UC but the further factor of SIGV_NOEX / SIGV_KMS.

Re 4, the pixels per beam is in there to reflect the oversampling of the beam so that a bootstrap draw thinks you have N data but you really have N/ppbeam independent data, so I think that's appropriate if are fine treating things in the Gaussian framework. I'm stared a bit at the efficiency of the median but didn't see a clean mapping into code given the mad_std estimator for the std.