HMM model not return the size of the discrete parameters

[bayesianbrad]

In this model the categorical is composed of 3 stacked lists. However, the returned size is None as the size list is empty:

	@classmethod
	def get_dist_parameter_size(self, name):
		dist_sizes = {}
		if name in dist_sizes:
			return dist_sizes[name]
		else:
			return None

when it should be 3, the number of columns.

(defn data [n]
  (let [points (vector 0.9 0.8 0.7 0.0 -0.025
                       5.0 2.0 0.1 0.0 0.13
                       0.45 6.0 0.2 0.3 -1.0 -1.0)]
    (get points n)))

;; Define the init, transition, and observation distributions
(defn get-init-params []
  (vector (/ 1. 3.) (/ 1. 3.) (/ 1. 3.)))

(defn get-trans-params [k]
  (nth (vector (vector 0.1  0.5  0.4 )
               (vector 0.2  0.2  0.6 )
               (vector 0.7 0.15 0.15 )) k))

(defn get-obs-dist [k]
  (nth (vector (normal -1. 1.)
               (normal  1. 1.)
               (normal  0. 1.)) k))  

;; Function to step through HMM and sample latent state
(defn hmm-step [n states]
  (let [next-state (sample (categorical (get-trans-params (last states))))]
    (observe (get-obs-dist next-state) (data n))
    (conj states next-state)))

;; Loop through the data
(let [init-state (sample (categorical (get-init-params)))]
  (loop 1 (vector init-state) hmm-step))

[Tobias-Kohn]

There are actually two categorical distributions in this code. The one at the very end sampling from get-init-params can be completely resolved by the compiler. However, the one inside the hmm-step is in fact beyond the reach of the compiler.
The current implementation of PyFOPPL does not have a type system. The compiler can therefore only reason about the size of symbols (such as function calls), if they can be completely resolved at compile time. Since get-trans-param is taking a random element out of the vector list, the compiler cannot resolve that symbol, but gets stuck.
Long story short: I cannot fix this issue here in any reasonable way. The new implementation PyFOPPL-2, however, uses a fully fledged type system and will be able to resolve the symbols in this model without problem.
I am sorry about that :,-(.

[bayesianbrad]

No worries, we will work together on Monday to get the code to run with the new interface, as it will be critical to get this feature working. It shouldn’t hopefully take too long, if we work at it for most of Monday. I have a meeting at 1:30 on Monday, but other than that I am free all day.
We have enough time to get this sorted :-)

[bayesianbrad]

The typed system will be a lot more useful. As here is another problem:

(let [mu1 (sample (normal -5 1))
      mu2 (sample (normal 5 1))
      sig1 (sample (poisson 2))
      mu (vector mu1 mu2)
      z (sample (categorical [0.1 0.9]))
      y 3]
  (observe (normal (get mu z) sig1) y)
  (vector z mu ))

So now sigma is a latent variable that we would like to infer, however when this compiles we get (this is a subset of the output):

p10002 = dist_x20003.log_pdf(x20003)
dist_y20005 = dist.Normal(mu=[x20001, x20002][int(x20004)], sigma=math.sqrt(x20003))

It may make more sense for you to remove the math.sqrt and I will just do that inside of the distribution classes instead. As other wise, not only will you need to cast the sigma parameter to a variable, you will also need torch to take the sqrt wherever the sig1 parameter appears.