Pass messages (i.e. bracketed) and not message values in LBP implementation

[GoogleCodeExporter]

{{{
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