Background: We inject a goal of an anti-fact such as (goal (|fact (mk.val h position 5))). Later, a fact is injected which satisfies the goal such as (fact (mk.val h postition 10)) . The goal monitor calls register_goal_outcome to inject a success object which indicates that the goal was (unexpectedly) achieved, and this is intercepted by GTPX which tries to make a model to explain the unexpected success. The success object is supposed to have everything that GTPX needs to make the model (but it doesn't - see below).
In the same frame but slightly later, there is already a model which predicts the goal-satisfying fact such as (fact (mk.val h postition 10)) . When the actual fact is injected, AERA injects a success object like (success f_prediction evidence prediction_mk_val) where f_prediction is the model's prediction, success is the satisfying fact, and prediction_mk_val is the reduction marker when the model made the prediction. This has lots of information which we want use in GTPX to build its model (such as the exact command which lead to the prediction). In addition, when the auto focus controller receives a prediction success, it calls GTPX::ack_pred_success for each goal in the list of goals that are being monitored for GTPX. This is convenient because ack_pred_success receives the prediction success with all the information it needs to build a model.
The problem is that when the goal monitor initially calls register_goal_outcome, it invalidates the goal object, and the goal is immediately removed from the list of goals that are being monitored for GTPX. This means that ack_pred_success is never called with the prediction success object with the information we want to use.
Therefore, this pull request makes two changes. Firstly, in the goal monitor, if the goal is an anti-fact then it doesn't call register_goal_outcome. (This way the goal is not invalidated and GTPX::ack_pred_success will be called.) Secondly, we update
GTPX::ack_pred_success to check if the goal is an anti-fact and use the reduction marker from the prediction success object to build the "GTPX" model. Once the model is injected, ack_pred_success calls register_goal_outcome.
Background: We inject a goal of an anti-fact such as
(goal (|fact (mk.val h position 5))). Later, a fact is injected which satisfies the goal such as(fact (mk.val h postition 10)). The goal monitor callsregister_goal_outcometo inject asuccessobject which indicates that the goal was (unexpectedly) achieved, and this is intercepted by GTPX which tries to make a model to explain the unexpected success. The success object is supposed to have everything that GTPX needs to make the model (but it doesn't - see below).In the same frame but slightly later, there is already a model which predicts the goal-satisfying fact such as
(fact (mk.val h postition 10)). When the actual fact is injected, AERA injects a success object like(success f_prediction evidence prediction_mk_val)wheref_predictionis the model's prediction,successis the satisfying fact, andprediction_mk_valis the reduction marker when the model made the prediction. This has lots of information which we want use in GTPX to build its model (such as the exact command which lead to the prediction). In addition, when the auto focus controller receives a prediction success, it callsGTPX::ack_pred_successfor each goal in the list of goals that are being monitored for GTPX. This is convenient becauseack_pred_successreceives the prediction success with all the information it needs to build a model.The problem is that when the goal monitor initially calls
register_goal_outcome, it invalidates the goal object, and the goal is immediately removed from the list of goals that are being monitored for GTPX. This means thatack_pred_successis never called with the prediction success object with the information we want to use.Therefore, this pull request makes two changes. Firstly, in the goal monitor, if the goal is an anti-fact then it doesn't call
register_goal_outcome. (This way the goal is not invalidated andGTPX::ack_pred_successwill be called.) Secondly, we updateGTPX::ack_pred_successto check if the goal is an anti-fact and use the reduction marker from the prediction success object to build the "GTPX" model. Once the model is injected,ack_pred_successcallsregister_goal_outcome.