pymc3.sample() not starting from the specified start value

[adrn]

(see also: https://discourse.pymc.io/t/pymc3-sample-not-starting-from-the-specified-start-value/7419)

Description of your problem

I would like to set the start value explicitly when calling pm.sample() using start=, but it seems like the tuning does not use the input. I know that for some initialization methods (e.g., jitter+adapt_diag), the init can override the start. However, I would not expect adapt_diag to override the input start. As example:

with pm.Model() as model:
    lnx = pm.Uniform('lnx', 0., 5.)
    infdata = pm.sample(tune=100, draws=0, 
                        start={'lnx': 1.},
                        init='adapt_diag',
                        return_inferencedata=True,
                        discard_tuned_samples=False, 
                        chains=1)

Please provide the full traceback.

I would expect infdata.warmup_posterior.lnx.values[0, 0] == 1. with the example above, but instead it seems to initialize at a random point.

Versions and main components

• PyMC3 Version: 3.11.1
• Aesara Version: n/a
• Python Version: 3.8
• Operating system: macOS
• How did you install PyMC3: pip

[ColCarroll]

Hey Adrian - I'm going to (unfortunately) mark this as "working as intended", though not going to close, since the API is pretty unforgiving:

1. You should actually use lnx_interval__ to specify a start point here, since it is transformed. You can use model.check_test_point() to see the names of the variables that need to be specified.
2. This start point is transformed! You can either look up the transformation, or use start={'lnx_interval__': lnx.transformation.forward(1.).eval()} to push 1 forward by the transformation.
3. The initial point is not recorded in the trace. I guess it could be, but I would consider that a little funny.
   For what it is worth, running

with pm.Model() as model:
    lnx = pm.Uniform('lnx', 0., 5.)
    infdata = pm.sample(tune=100, draws=0, 
                        start={'lnx_interval__': lnx.transformation.forward(1.).eval()},
                        init='adapt_diag',
                        step=pm.NUTS(step_scale=100),
                        return_inferencedata=True,
                        discard_tuned_samples=False, 
                        chains=1)

does The Right Thing. Notice that I provided a bad initial step scale, so that I would reject a few proposals, and they would get recorded in the trace.

[ColCarroll]

It may be helpful to know how much each of these things variously offends you (or anyone else!), and break them out into their own issues in case someone wants to pick them up?

[michaelosthege]

I frequently fall victim to this too. Last time it almost found it's way into the manuscript submission.

IMHO we should change the API such that it does what the user expects in this case. We could just loop over the transformed variables and look for entries that correspond to the untransformed name. Because these names are unique it won't be a problem at all.

[ricardoV94]

It may be helpful to know how much each of these things variously offends you (or anyone else!), and break them out into their own issues in case someone wants to pick them up?

I think @ColCarroll is right here. If there are specific problems we should open issues for them. This issue doesn't seem helpful on its own anymore