JumpProposal simplification

[siyuan-chen]

I have noticed that there are several draw_from_X function in the JumpProposal object in model_utils.py (sampler.py). It would probably be good to generalize that to a function, where you can input your signal name. It removes a lot of copy-pasted code and also allow users to easier select targeted JumpProposals. A similar thing can be done for the parameter prior jump proposals.
I will have a go at coding that...

[bvgoncharov]

Hi All , it looks like there are still quite a few lines with hardcoded priors in custom jump proposals. They biased some of my recent parameter-estimation runs. Is there a plan to replace all custom jump proposals with a loop through all parameters that simply adds functions that draw samples from parameter priors?

[siyuan-chen]

Hi @bvgoncharov , what exactly do you mean? I have seen a few bugs in the code in the master branch, those have been fixed in my fork. But, I am not sure that there are hardcoded priors in custom jump proposal. Ok, it reuses the .sample() function from the PTA parameter object. But, that should be from the input priors.

[bvgoncharov]

Hi @siyuan-chen , I am referring to a long list of jump proposals in hypermodel.py. For example, this line adds jump proposals to the gwb signal:

enterprise_extensions/enterprise_extensions/hypermodel.py

Line 245 in 321e941

# GWB uniform distribution draw

It turns out, jp.draw_from_gwb_log_uniform_distribution defined in sampler.py contains prior (-18; -11):

enterprise_extensions/enterprise_extensions/sampler.py

Line 276 in 321e941

q[idx] = np.random.uniform(-18, -11)

The same works for BayesEphem, and maybe for other signals. As a result, the result is strongly biased when a non-standard prior is chosen. Perhaps it is worth only leaving the prior-draw jump proposal here?

enterprise_extensions/enterprise_extensions/hypermodel.py

Line 197 in 321e941

# always add draw from prior

My understanding is that jump proposals help to avoid situations when the PTMCMCSampler is getting stuck in one point in parameter space. I am not 100% sure if keeping only the jump proposal at line 197 will be sufficient, but I think this might be enough.

[siyuan-chen]

Ah, I see what you mean. The range (-18,-11) is somewhat hardcoded in

enterprise_extensions/enterprise_extensions/blocks.py

Line 525 in 321e941

log10_Agw = parameter.LinearExp(-18, -11)(amp_name)

So, the idea is that because the ranges are the same between the JumpProposal and the PTA object, there should not be biasing. I am not sure if it would even if that was not the case. JumpProposal should help to get the sampler unstuck, the sampler still decides whether it will jump there or not. This decision should be based on the likelihood and not on the range of the jumpproposal.

jp.draw_from_gwb_log_uniform_distribution is meant to be used in upper limit analysis to help the sampler also cover the lower amplitudes.

Yeah, I think the list of jumpproposal in hypermodel can be replaced by a custom list and a looped call to the draw_from_par_prior function. I just didn't want to hugely overwrite the existing structure. Others should chime in, if that is something they want to see.