"mean of multivariate normal Y[1,1] must have the same number of components as Y[1,1]" - Error in WinBUGS - bayesian
How to deal with compilation error which says: "mean of multivariate normal Y[1,1] must have the same number of components as Y[1,1]"?
Here are my code and data in WinBugs:
model{
for (i in 1:10){
Y[i, 1:8] ~ dmnorm(mu[,], Omega[ , ])
mu[i,1]<-a[1]+a[2]*ExitsCount_Dens[i,1]+a[3]*LanesCount[i,1]
mu[i,2]<-b[1]+b[2]*ExitsCount_Dens[i,2]+b[3]*LanesCount[i,2]
mu[i,3]<-c[1]+c[2]*ExitsCount_Dens[i,3]+c[3]*LanesCount[i,3]
mu[i,4]<-d[1]+d[2]*ExitsCount_Dens[i,4]+d[3]*LanesCount[i,4]
mu[i,5]<-e[1]+e[2]*ExitsCount_Dens[i,5]+e[3]*LanesCount[i,5]
mu[i,6]<-f[1]+f[2]*ExitsCount_Dens[i,6]+f[3]*LanesCount[i,6]
mu[i,7]<-g[1]+g[2]*ExitsCount_Dens[i,7]+g[3]*LanesCount[i,7]
mu[i,8]<-h[1]+h[2]*ExitsCount_Dens[i,8]+h[3]*LanesCount[i,8]
}
Omega[1 : 8 , 1 : 8] ~ dwish(R[ , ], 8)
Sigma[1 : 8 , 1 : 8] <- inverse(Omega[ , ])
#priors:
for (k in 1:3) {a[k] ~dnorm(0.0, 1.0E-5)}
for (l in 1:3) {b[l] ~dnorm(0.0, 1.0E-5)}
for (m in 1:3) {c[m] ~dnorm(0.0, 1.0E-5)}
for (n in 1:3) {d[n] ~dnorm(0.0, 1.0E-5)}
for (o in 1:3) {e[o] ~dnorm(0.0, 1.0E-5)}
for (p in 1:3) {f[p] ~dnorm(0.0, 1.0E-5)}
for (q in 1:3) {g[q] ~dnorm(0.0, 1.0E-5)}
for (r in 1:3) {h[r] ~dnorm(0.0, 1.0E-5)}
#priors:
for (t in 1:8) {R[t,t]<-1}
}
Data:
list(
Y=structure(.Data=c(
19.848,20.054,21.209,21.777,17.038,16.54,16.335,17.694,
3.742,14.1375,24.533,14.2415,3.95,27.179,28.515,29.851,
27.964,28.133,28.887,30.721,29.609,27.005,27.497,28.925,
10.829,10.515,11.213,11.82,7.935,8.323,7.102,8.034,
21.169,21.025,22.795,21.98,19.414,18.975,18.02,21.142,
28.263,27.163,19.495,23.436,29.234,30.363,28.305,23.896,
14.141,17.957,20.248,21.678,21.411,21.125,18.633,19.594,
24.485,23.817,25.554,25.251,19.599,24.184,18.141,22.705,
12.89,15.456,18.661,19.931,18.758,19.15,17.978,19.828,
14.557,15.134,25.8,20.574,12.168,38.655,14.36,7.093
),.Dim=c(10,8)),
LanesCount = structure(.Data = c(
2,2,2,2,2,2,2,2,
2,2,2,2,2,2,2,2,
5,5,5,5,5,5,5,5,
2,2,2,2,2,2,2,2,
5,5,5,5,5,5,5,5,
2,2,2,2,2,2,2,2,
5,5,5,5,5,5,5,5,
4,4,4,4,4,4,4,4,
2,2,2,2,2,2,2,2,
3,3,3,3,3,3,3,3
),.Dim = c(10,8)),
ExitsCount_Dens = structure(.Data = c(
2.215,2.215,2.215,2.215,2.215,2.215,2.215,2.215,
2.703,2.703,2.703,2.703,2.703,2.703,2.703,2.703,
2.703,2.703,2.703,2.703,2.703,2.703,2.703,2.703,
2.761,2.761,2.761,2.761,2.761,2.761,2.761,2.761,
2.761,2.761,2.761,2.761,2.761,2.761,2.761,2.761,
2.747,2.747,2.747,2.747,2.747,2.747,2.747,2.747,
2.747,2.747,2.747,2.747,2.747,2.747,2.747,2.747,
4.757,4.757,4.757,4.757,4.757,4.757,4.757,4.757,
4.757,4.757,4.757,4.757,4.757,4.757,4.757,4.757,
4.757,4.757,4.757,4.757,4.757,4.757,4.757,4.757
),.Dim = c(10,8)))
#initials:
list(
a=c(1,1,1),
b=c(1,1,1),
c=c(1,1,1),
d=c(1,1,1),
e=c(1,1,1),
f=c(1,1,1),
g=c(1,1,1),
h=c(1,1,1)
)
The multivariate normal function dmnorm() expects a vector of length N for the mean and an NxN covariance matrix. Currently, you're passing the full 10x8 matrix of mu values by using mu[,], but instead you only want to pass the 1x8 row vector of mu's that correspond to the i-th iteration, i.e.,
Y[i, 1:8] ~ dmnorm(mu[i,], Omega[,])
Related
Debugging specialize and/or apply errors in Coq
I'm trying to figure out the source of the following error with the apply (list2map_not_in_default [(k, v)] i) in H2. command. Here is the list2map_not_in_default type: list2map_not_in_default : forall (al : list (key * V)) (i : key), ~ (exists v : V, In (i, v) al) -> list2map al i = default And the error: Error: Unable to apply lemma of type "~ (exists v0 : V, In (i, v0) [(k, v)]) -> list2map [(k, v)] i = default" on hypothesis of type "~ (exists v : V, In (i, v) [(k, v)])". Alternatively apply (list2map_not_in_default [(k, v)] i) in H2. , can be seen as the following error, whereby you can see my context fully. Error: In environment V : Type default : V lo : key l : tree k : key v : V r : tree hi : key H0_ : SearchTree' lo l k H0_0 : SearchTree' (S k) r hi i : nat Hleft : ~ (exists v : V, In (i, v) (slow_elements l)) H : i < k H0 : k <> i H1 : list2map (slow_elements l) i = default H2 : ~ (exists v : V, In (i, v) [(k, v)]) The term "H2" has type "~ (exists v : V, In (i, v) [(k, v)])" while it is expected to have type "~ (exists v0 : V, In (?i, v0) ?al)". Earlier in the proof I use the exact same lemma specialize (list2map_not_in_default _ _ Hleft). with no problems. This applied in the following context V : Type default : V lo : key l : tree k : key v : V r : tree hi : key H0_ : SearchTree' lo l k H0_0 : SearchTree' (S k) r hi i : nat Hleft : ~ (exists v : V, In (i, v) (slow_elements l)) H : i < k H0 : k <> i ============================ list2map (slow_elements l ++ [(k, v)] ++ slow_elements r) i = list2map (slow_elements l) i yields a goal with the desired application. list2map (slow_elements l) i = default -> list2map (slow_elements l ++ [(k, v)] ++ slow_elements r) i = list2map (slow_elements l) i What is happening here? Any suggestions on how I can fix it?
The unification algorithm used by apply in is exceedingly weak. There is nothing you can do about it (except opening bug reports and hoping someone fixes it). Just use some other tactic. As you already noticed, specialize works better, since you are explicitly writing a lambda-term. Another similar tactic is assert (H3 := list2map_not_in_default _ _ Hleft). Or you can go to the most expressive tactic of all: (simple) refine (let H3 := list2map_not_in_default _ _ Hleft in _).
How to rewrite: Vect (S (S (n + m))) a -> Vect (S (plus n (S m))) a
I am stuck with Idris (again, sigh). I am doing an exercise on merge sort from the type driven development with Idris book on chapter 10. I have this:
import Data.Vect
import Data.Vect.Views
sort2 : Ord a => (l: a) -> (r: a) -> (a, a)
sort2 l r = if l <= r then (l, r) else (r, l)
needHelp : Vect (S (S (n + m))) a -> Vect (S (plus n (S m))) a
needHelp {n=(S n)} {m=(S m)} (x :: xs) = ?help
vectMerge : Ord a => Vect n a -> Vect m a -> Vect (n + m) a
vectMerge [] ys = ys
vectMerge {n} xs [] = rewrite plusZeroRightNeutral n in xs
vectMerge {n=(S n)} {m=(S m)} (x :: xs) (y :: ys) =
let (f, s) = sort2 x y in
needHelp (f :: s :: (vectMerge xs ys))
I have isolated the needHelp function so you can see the rewrite that I want to achieve. I tried this:
vectMerge : Ord a => Vect n a -> Vect m a -> Vect (n + m) a
vectMerge [] ys = ys
vectMerge {n} xs [] = rewrite plusZeroRightNeutral n in xs
vectMerge {n=(S n)} {m=(S m)} (x :: xs) (y :: ys) =
let (f, s) = sort2 x y in
let tail = (rewrite plusSuccRightSucc n m in s :: vectMerge xs ys) in
f :: tail
But Idris complains:
When checking right hand side of Main.case block in vectMerge with expected type
Vect (S (plus n (S m))) a
rewriting S (plus n m) to plus n (S m) did not change type letty
I don't understand why this doesn't work. Help much appreciated.
rewrite works with respect to your current goal, not wrt to the term you are trying to use to solve the goal (I tried to illustrate it in this answer).
So, here is a possible solution:
import Data.Vect
sort2 : Ord a => (l: a) -> (r: a) -> (a, a)
sort2 l r = if l <= r then (l, r) else (r, l)
vectMerge : Ord a => Vect n a -> Vect m a -> Vect (n + m) a
vectMerge [] ys = ys
vectMerge {n} xs [] = rewrite plusZeroRightNeutral n in xs
vectMerge {n=(S n)} {m=(S m)} (x :: xs) (y :: ys) =
let (f, s) = sort2 x y in
rewrite sym $ plusSuccRightSucc n m in
(f :: s :: (vectMerge xs ys))
sym in sym $ plusSuccRightSucc n m reverses the direction of rewrite.
Z3 OCaml API Recursive Function
Let's say I want to check if the formula x+y=z (x,y,z integers) is satisfiable. Using Z3 i could input something like:
(declare-fun x () Int)
(declare-fun y () Int)
(declare-fun z () Int)
(assert (= z (+ x y)))
(check-sat)
I could equivalently use the OCaml api and write the following code:
let ctx=Z3.mk_context [("model", "true"); ("proof", "false")] in
let v1=(Z3.Arithmetic.Integer.mk_const_s ctx "x") in
let v2=(Z3.Arithmetic.Integer.mk_const_s ctx "y") in
let res=(Z3.Arithmetic.Integer.mk_const_s ctx "z") in
let sum=Z3.Arithmetic.mk_add ctx [ v1 ; v2] in
let phi=Z3.Boolean.mk_eq ctx sum res in
let solver = (Z3.Solver.mk_solver ctx None) in
let _= Z3.Solver.add solver [phi] in
let is_sat=Z3.Solver.check solver [] in
match is_sat with
| UNSATISFIABLE -> Printf.printf "unsat";
| SATISFIABLE -> Printf.printf "sat";
| UNKNOWN -> Printf.printf "unknown";
I would like to use the ocaml api of z3 to check the satisfiability of
the following factorial implementation, so that I get a value for x (if it exists).
(declare-fun x () Int)
(define-fun-rec f ((x Int)) Int
(ite (> x 1)
(* (f (- x 1))
x)
1))
(assert (= x (f 10)))
(check-sat)
(get-model)
Unfortunately, I can't find an example of recursive definitions using the ml api of z3.
What does the error message "Universe inconsistency" mean when working with higher-rank types?
Given the following Idris code:
import Data.Vect
import Data.Fin
%default total
fins : Vect n (Fin n)
fins {n = Z} = []
fins {n = S n} = FZ :: map FS fins
Permutation : Nat -> Type
Permutation n = {a : Type} -> Vect n a -> Vect n a
permutations : {n : Nat} -> Vect (fact n) (Permutation n)
permutations {n = Z} = [id]
permutations {n = S n} =
rewrite multCommutative (S n) (fact n) in
concat $ map inserts (permutations {n = n})
where
inserts : Permutation k -> Vect (S k) (Permutation (S k))
inserts pi = map (\i => \(x :: xs) => insertAt i x . pi $ xs) fins
I am getting the following error message from Idris 0.9.16 (and no further details):
Type checking .\Permutations.idr
Permutations.idr:15:14:Universe inconsistency
However, by changing it just so slightly, so that the second clause of permutations becomes
permutations {n = S n} =
rewrite multCommutative (S n) (fact n) in
concat . map inserts $ permutations {n = n}
then it suddenly typechecks.
Is there some special magic going on inside Idris perhaps in the handling of ($) and (.), similar to what GHC does so that they work in the presence of higher-rank types?
As of Idris 0.10.2, my original code (using concat $ map inserts (permutations {n = n}) in the definition of permutations) typechecks without hiccup.
How to enumerate the elements of a list by `Fin`s in linear time?
We can enumerate the elements of a list like this:
-- enumerate-ℕ = zip [0..]
enumerate-ℕ : ∀ {α} {A : Set α} -> List A -> List (ℕ × A)
enumerate-ℕ = go 0 where
go : ∀ {α} {A : Set α} -> ℕ -> List A -> List (ℕ × A)
go n [] = []
go n (x ∷ xs) = (n , x) ∷ go (ℕ.suc n) xs
E.g. enumerate-ℕ (1 ∷ 3 ∷ 2 ∷ 5 ∷ []) is equal to (0 , 1) ∷ (1 , 3) ∷ (2 , 2) ∷ (3 , 5) ∷ []. Assuming there is sharing in Agda, the function is linear.
However if we try to enumerate the elements of a list by Fins rather than ℕs, the function becomes quadratic:
enumerate-Fin : ∀ {α} {A : Set α} -> (xs : List A) -> List (Fin (length xs) × A)
enumerate-Fin [] = []
enumerate-Fin (x ∷ xs) = (zero , x) ∷ map (pmap suc id) (enumerate-Fin xs)
Is it possible to enumerate by Fins in linear time?
Consider this as a first attempt:
go : ∀ {m α} {A : Set α} -> Fin m -> (xs : List A) -> List (Fin (m + length xs) × A)
go i [] = []
go i (x ∷ xs) = (inject+ _ i , x) ∷ {!go (suc i) xs!}
i grows at each recursive call as it should, but there is a mismatch:
the type of the goal is List (Fin (.m + suc (length xs)) × .A)
the type of the expression insise the hole is List (Fin (suc (.m + length xs)) × .A)
It's easy to prove that two types are equal, but it's also dirty. This is a common problem: one argument grows and the other lowers, so we need definitionally commutative _+_ to handle both the cases, but there is no way to define it. The solution is to use CPS:
go : ∀ {α} {A : Set α} -> (k : ℕ -> ℕ) -> (xs : List A) -> List (Fin (k (length xs)) × A)
go k [] = []
go k (x ∷ xs) = ({!!} , x) ∷ go (k ∘ suc) xs
(k ∘ suc) (length xs) is the same thing as k (length (x ∷ xs)), hence the mismatch is fixed, but what is i now? The type of the hole is Fin (k (suc (length xs))) and it's uninhabited in the current context, so let's introduce some inhabitant:
go : ∀ {α} {A : Set α}
-> (k : ℕ -> ℕ)
-> (∀ {n} -> Fin (k (suc n)))
-> (xs : List A)
-> List (Fin (k (length xs)) × A)
go k i [] = []
go k i (x ∷ xs) = (i , x) ∷ go (k ∘ suc) {!!} xs
The type of the new hole is {n : ℕ} → Fin (k (suc (suc n))). We can fill it with i, but i must grow at each recursive call. However suc and k doesn't commute, so suc i is Fin (suc (k (suc (_n_65 k i x xs)))). So we add another argument that sucs under k, and the final definition is
enumerate-Fin : ∀ {α} {A : Set α} -> (xs : List A) -> List (Fin (length xs) × A)
enumerate-Fin = go id suc zero where
go : ∀ {α} {A : Set α}
-> (k : ℕ -> ℕ)
-> (∀ {n} -> Fin (k n) -> Fin (k (suc n)))
-> (∀ {n} -> Fin (k (suc n)))
-> (xs : List A)
-> List (Fin (k (length xs)) × A)
go k s i [] = []
go k s i (x ∷ xs) = (i , x) ∷ go (k ∘ suc) s (s i) xs
which works, because s : {n : ℕ} → Fin (k n) → Fin (k (suc n)) can be treated as {n : ℕ} → Fin (k (suc n)) → Fin (k (suc (suc n))).
A test: C-c C-n enumerate-Fin (1 ∷ 3 ∷ 2 ∷ 5 ∷ []) gives
(zero , 1) ∷
(suc zero , 3) ∷
(suc (suc zero) , 2) ∷ (suc (suc (suc zero)) , 5) ∷ []
Now note that in enumerate-Fin k always follows Fin in the types. Hence we can abstract Fin ∘ k and get a generic version of the function that works with both ℕ and Fin:
genumerate : ∀ {α β} {A : Set α}
-> (B : ℕ -> Set β)
-> (∀ {n} -> B n -> B (suc n))
-> (∀ {n} -> B (suc n))
-> (xs : List A)
-> List (B (length xs) × A)
genumerate B s i [] = []
genumerate B s i (x ∷ xs) = (i , x) ∷ genumerate (B ∘ suc) s (s i) xs
enumerate-ℕ : ∀ {α} {A : Set α} -> List A -> List (ℕ × A)
enumerate-ℕ = genumerate _ suc 0
enumerate-Fin : ∀ {α} {A : Set α} -> (xs : List A) -> List (Fin (length xs) × A)
enumerate-Fin = genumerate Fin suc zero