Implement open interpretation provider for previous message expressions and bounds placeholders so that LambdaApplication applies properly

[GoogleCodeExporter]

> *. LambdaApplication:
> - made configurable so that it can be determined whether or not
> the lambda application should be performed or not. Also, added
> to LBP's R_simplify and configured only to perform the rewrite
> when no 'previous message to . from .' expressions exist in
> the body.

Nice. In fact there is a module that provides that kind of configuration, 
OpenInterpretationModule. It tells whether an expression depends implicitly on 
another expression, as it is the case between "previous message to [p(X)] from 
Alpha" and "p(X)". I used it in a similar way in IntensionalSetEnumeration, 
which is the basis for the iteration of a summation and takes care of replacing 
an index by its successive values. Eventually we should use the same thing for 
LambdaApplication. I will create a JIRA item to take care of that.

Original issue reported on code.google.com by ctjoreilly@gmail.com on 11 Apr 2013 at 12:04

[GoogleCodeExporter]

Ciaran O'reilly added a comment - 08/Jan/13 10:44 AM - edited
Note with respect to Bounds placeholders as well in lambda applications:
{{{
>>
>>>    - R_simplify, the lambda application check has been extended to
>>>      ensure no bounds placeholders exist in addition to the existing
>>>      previous messages check.
>>
>> Ok. The more general way to deal with it would have been to define
>> placeholders to have "open interpretations" (per
>> OpenInterpretationModule) with regard to random variable values. This
>> informs the system that a placeholder's ultimate value depends on the
>> value of random variables, and prevents the substitution from taking
>> place.
>
> This is related to:
>
> https://jira511.esg.sri.com/browse/ALBP-206
>
> However, I'm not sure it ultimately depends on the value of the random 
variable being determined. 
You need the placeholder to be substituted before the random variable value is 
determined for what you
outline to work correctly. For the moment I'd like to leave as is and add a 
comment to this to cover 
later as well (i.e. same as previous messages), ok?

I am fine with leaving it as is, but would like to clarify that we are using 
two notions of 
"substitution" here. One is the main expresso one, which is the one used by 
lambda application. This 
is the one that could benefit from the "open interpretation" concept. The other 
notion of substitution
is the one used in iterate_extrema, which I agree would have to be done even 
before random variable 

>> This frees the lambda application check to know about
>> placeholders. But then this whole thing about placeholders is kind of
>> hack-ish anyway...
>
> I'm guessing you have something in mind with the new message representation 
that won't require 
the need for placeholders to be used in the bounds case?

No, I think placeholders should remain and ideally we would do this "open 
interpretation" thing 
with them. My point is that there is no need to try to get this done and neat 
now, because we are 
not neat in something much bigger, namely the message representation not being 
bracketed. 
values are defined. 
}}}

Original comment by ctjoreilly@gmail.com on 11 Apr 2013 at 12:05

[GoogleCodeExporter]

Ciaran O'reilly added a comment - 08/Jan/13 10:50 AM
Note: The current logic for delaying LambdaApplications is in:
{{{
com.sri.ai.lpi.lbp.core.Simplify

                new Pair<Class<?>, Rewriter>(LiftProductOfFactorToVariable.class,
                        new LambdaApplication(new PerformApplication() {
                            @Override
                            public boolean isApplicationToBePerformed(Expression lambdaExpression, RewritingProcess process) {
                                Expression lambdaBody = Lambda.getBody(lambdaExpression);
                                boolean result = !LPIUtil.containsPreviousMessageExpressions(lambdaBody) &&
                                                 !ConvexRewriterOnMessageBounds.containsPlaceholderExpression(lambdaBody);
                                return result;
                            }
                        }))
                );

}}}

Original comment by ctjoreilly@gmail.com on 11 Apr 2013 at 12:06