Allow functionality for single expparams value (introduction_to_bayes_smc.ipynb)

[cbevington]

Attribute error arises when calling model.likelihood for the case of a single expparams value (N, number of coin flips, in this case) if not converted to a numpy array. Fixed with with np.asarray.

[csferrie]

Thanks, Connor! I'm wondering about this error you are getting because I'm not seeing it.

[cbevington]

I was talking with another guy from the lab and we were wondering if it was a problem with Python or the code itself. The problem in question is when model.likelihood is called. As it stands in the code from the Jupyter nb now, expparams is defined to be the single integer N. Somewhere behind the scenes in the model.likelihood call reverts to a library file abstract_model.py, wherein we have the following definition for likelihood:

def likelihood(self, outcomes, modelparams, expparams):
    # Count the number of times the inner-most loop is called.
    self._call_count += outcomes.shape[0] * modelparams.shape[0] * expparams.shape[0]

Python then notes an attribute error, since it is asking for the shape of an integer in expparams.shape[0]. This would happen to the outcome object as well if it were not reformatted as an array, as noted in the code:

# In the model we asked for outcomes.shape[0], so we have to define it as an object with a shape!
outcome = np.array([0])

I just downloaded the latest qinfer files last week and I ran the script in Python 3.5 through Spyder and an IPython console, both yielding this error. However, strangely, in Python 2.7 through Spyder no error arises. So my guess is that this is a Python error and not a code error. Finally, an easier fix to the code to resolve the 3.5 error than I suggested would be to simply change expparams = N to expparams = np.array([N]), like was done with outcome above. This fits more in line with general cases where multiple experimental parameters exist and an array would be constructed anyway.

[cgranade]

The code in abstract_model.py that you're referring to was changed in QInfer/python-qinfer@5790445 to be robust in precisely the way you suggest here. Thus, I suspect your Python 3.5 and 2.7 environments have different versions of QInfer installed, one with and one without the improvements from QInfer/python-qinfer@5790445. Could you confirm if this is the case? Thanks!

[cbevington]

It appears so! Comparing the lib files from each version somehow the 3.5 version was without the improvements. I did a little investigating... for the 3.5 environment I downloaded QInfer directly from PyPI, and for 2.7 I downloaded it with Git and pip. The code in abstract_model.py downloaded from PyPI (filename QInfer-1.0b4.tar.gz at https://pypi.python.org/pypi/QInfer) is without the improvements, whereas the code through Git is updated. This is my first go through QInfer but I'll make sure to update to the latest version through Git in the future. It looks like the .tar file was last updated in May, whereas your revisions to call_count were made in June.