hi @daragallagher

Thanks for your well written question! I think I might have a very simple answer: you may have been bitten by a GPflow 2.0 gotcha.

The solution is to replace m.likelihood.variance = 0.01 with m.likelihood.variance.assign(0.01), then your example works great :)

The behaviour of gpflow's parameters has changed with version 2.0 to match that of tensorflow Variables. @awav , could you point @daragallagher to the gpflow2.0 gotchas notebook, please?

@jameshensman, yes, that's the case.
@daragallagher, https://github.com/GPflow/GPflow/blob/develop/doc/source/notebooks/intro_to_gpflow2.ipynb.

Could you repost this question on StackOverflow with gpflow tag? Thanks.

Thanks for the quick response. I thought it might be something like that.

@awav I had read (quickly) through that intro notebook but missed the assign recommendation. Nearly all of the sample code that appears in google search results is understandably for gpflow 1.x so I think this gotcha may catch quite a few noobs like myself. It's probably not practical to support the older style?

Anyway, in case it helps others, I've posted this issue as a SO question here: https://stackoverflow.com/questions/60055919/gpflow-2-0-issue-with-default-float-and-likelihood-variance

@awav I also see now that my suggestion that gpflow add code to convert to the default float for the sake of API consistency will not really help since the issue really originates in tensorflow itself and has infected modules built on top of tensorflow like tensorflow-probability. So there is little that can be done in gpflow to address the consistency issues this causes. I see you've already raised this as a tensorflow issue here: tensorflow/tensorflow#26033

Here is an example of the sort of inconsistency that has bothered me, taken from one of the example notebooks;

adaptive_hmc = tfp.mcmc.SimpleStepSizeAdaptation(
    hmc, 
    num_adaptation_steps=10, 
    target_accept_prob=tf.cast(0.75, dtype=tf.float64),
    adaptation_rate=0.1
)

If using float64, one argument, adaptation_rate, does not require a cast, while the other, target_accept_prob, requires one.

This makes (IMHO) the API quite user hostile. Either the user must defensively wrap every float argument in a cast, or use a debugger to locate the source of a float argument that eventually raise an "expected to be a double tensor but is a float tensor" exception.

If tensorflow were to provide a default float setting, then this inconsistency would not arise. Even my initial example would have worked fine as tf.fill would have defaulted to float64.

I think many users of tensorflow are focused on deep learning and so never look beyond float32 which I suspect is the reason the issue hasn't been prioritized. This is unfortunate for libraries that build on tensorflow where the numeric properties of float64s make more sense.

So I'll add a "me too" comment to tensorflow issue 26033 and close this one.

@daragallagher thank you for such a well-written issue report!