{{{
Eventually we would want to represent all messages in brackets. So we change
things from:
message to [Factor1] from [p]
->
prod_F in N([p]) - Factor1 message to [p] from F
->
prod_F in { [Factor2], [Factor3] } message to [p] from F
->
message to [p] from [Factor2] * message to [p] from [Factor3]
->
if p then 0.8 else 0.2 * if p then 0.4 else 0.6
->
if p then 0.32 else 0.12
to:
message to [Factor1] from [p]
->
prod_F in N([p]) - Factor1 message to [p] from F
->
prod_F in { [Factor2], [Factor3] } message to [p] from F
->
message to [p] from [Factor2] * message to [p] from [Factor3]
->
[ if p then 0.8 else 0.2] * [ if p then 0.4 else 0.6]
->
[ if p then 0.32 else 0.12 ]
meaning we would need to implement a * operator for messages.
When it's messages from factors to rvs, we need to replace the lambda form with
something like:
[if p then 0.3 else 0.7](p)
and define a rewriter for applications of a factor to a value:
[if p then 0.3 else 0.7](true)
->
if true then 0.3 else 0.7
}}}
Ciaran O'reilly added a comment - 02/Nov/12 2:18 PM
{{{
When this is done the logic in SimplifyMessagesConvexHull and
ConvexRewriterOnMessageBounds will have to updated as well to take into account
the now global bracketed representation of messages (currently this logic
assumes its only used within 'convex hull' applications).
}}}
Ciaran O'reilly added a comment - 05/Nov/12 1:31 PM - edited
Additional Implementation Notes from email exchange:
{{{
> > meaning we would need to implement a * operator for messages.
>
> in addition we'd need a ^ operator for messages as well?
Yes, that's right.
...
> > [if p then 0.3 else 0.7](true)
> > ->
> > if true then 0.3 else 0.7
>
> my expectation is that applications of a factor to a value expressions will
not be present in
'convex hull's on message bounds?
That's right, this will deal with "whole" messages only.
}}}
Ciaran O'reilly added a comment - 11/Dec/12 9:31 AM
Note from Rodrigo:
{{{
Some further thoughts on this:
Bracketing messages is not trivial because bracketed expressions are not
"open", that is, they are not evaluated and manipulated like a, say, lambda
expression is. For example, [ if true then 1 else 0 ] is not simplified to [ 1
], whereas lambda p(X) : if true then 1 else 0 is simplified to lambda p(X) :
1. At this point in the code (December 2012), we do rely on messages being
simplified (for example, to get rid of unnecessary previous message expressions
in the loopy BP code).
Opening bracketed expressions so they are simplified like lambda expressions is
a natural idea, but not without consequences. When we perform subtractions of
sets of factors (a calculation necessary for BP), we currently rely on the
factor keeping the exact same expression inside at all times, and this would be
broken. If factors could be simplified, we would have to introduce a
parameterized id to the factor representation to keep track of its identity.
}}}
Original issue reported on code.google.com by ctjoreilly@gmail.com on 10 Apr 2013 at 11:51
Original issue reported on code.google.com by
ctjoreilly@gmail.com
on 10 Apr 2013 at 11:51