'fact' and 'goal' are identical?

[GoogleCodeExporter]

Consider the attached toy problem.  At time 0, it has 2 facts, 2 goals, and 2 
rejectable tokens.  The solver merges all 6 tokens together.

My understanding is that facts aren't supposed to be merged (since there are 
two facts in this initial state at the same time (and it's a timeline), the 
solver should fail).

Looking at the goal, the 'isFact' information is propagated all over the place. 
 I may have missed something, but it appears nothing is ever done with that 
information.

Original issue reported on code.google.com by tristanb...@gmail.com on 17 Jun 2011 at 5:58

Attachments:

• Test.tgz

[GoogleCodeExporter]

Possible code change, that I thought Javier should confirm before it gets put 
in.  In Token::commonInit, do the same thing we do regarding rejectable:

{{
    if (fact)
      stateBaseDomain.remove(MERGED);
}}

Original comment by tristanb...@gmail.com on 17 Jun 2011 at 6:09

[GoogleCodeExporter]

hmm, it looks like I didn't complete the implementation of facts as I intended.

the proposed fix is a good quick approximation, but probably not what we want 
in the end.
my gut reaction is that facts should be mergeable with other facts, I'll have 
to sit down and remember what I intended to do here in detail. I'll make an 
effort to deal with this within the next few days.

Original comment by javier.barreiro@gmail.com on 17 Jun 2011 at 6:32

[GoogleCodeExporter]

Is there a good use case for wanting them to merge with other facts?  It's a 
lot simpler to understand if the difference between fact and goal is simply 
whether or not 'MERGED' is in the base domain, so I'd lean towards doing that.

Also, I can imagine wanting to use facts to declare a bunch of tokens that I 
want to keep distinct.  This would only work if they won't be merged with each 
other.

Original comment by tristanb...@gmail.com on 17 Jun 2011 at 6:37

[GoogleCodeExporter]

another issue with facts is temporal scope : 
does it make sense to state facts in the future? 
in the real world facts should probably be stated in the present or the past 
only.
what about events that will happen with high certainty?, like a medical 
procedure that has been scheduled for a worker. Or the occurrence of an 
eclipse, or tide cycles, any events that can be predicted with high certainty 
by applying the laws of physics?

EUROPA doesn't have a concept of the present anyway, so temporal scope for 
facts will probably have to be left as a modeling decision, but it's a point 
that should be made explicit.

Original comment by javier.barreiro@gmail.com on 17 Jun 2011 at 6:49

[GoogleCodeExporter]

regarding comment 3 : I think the intuitive semantics for facts/goals is to be 
mergeable. 

for instance, if you say "fact(lightOn from t=0 to t=10)" and "fact(lightOn 
from t=3 to t=5)" you'll get cleaner plans and more efficient search if you 
allow them to merge into a single fact: "lightOn from t=0 to t=10".

as with goals, the user can always explicitly remove the option of merging if 
that's the behavior desired, however, it's much harder for me to see why people 
would want to do that for facts, any examples? 

Original comment by javier.barreiro@gmail.com on 17 Jun 2011 at 7:09

[GoogleCodeExporter]

I can imagine it for non-timeline classes.  For example, supose you have a 
School with scheduled 'class' predicates.  You could set up the initial 
schedule as a bunch of facts, and wouldn't want them to merge, even if they 
overlap.

What's a use case for wanting facts to merge with other facts, but not with 
goals?

Something to consider is whether we even need facts.  Obviously nobody has 
needed it up until now, and as you describe, there are other ways to reduce the 
state domains.

Original comment by tristanb...@gmail.com on 17 Jun 2011 at 8:23

[GoogleCodeExporter]

Original comment by javier.barreiro@gmail.com on 17 Aug 2011 at 7:48

• Added labels: Milestone-EUROPA-2.6

[GoogleCodeExporter]

regarding comment 6: ok, the class schedule is a good example where you may 
want to avoid merging for facts, my original comment still applies, where it 
would be better to have the user explicitly remove the option to merge if 
that's the behavior they want, but active/merge are still open in general.

the case for having goals merge with facts but not the other way around is the 
main reason in my mind to have a separate fact keyword: a fact is something 
that is already given and doesn't need support, so it makes sense for a goal to 
be supported by a fact (if my goal is to turn on the light but it's in fact 
already on then I don't need to do anything), but not the other way around, 
having a "fact" disappear into a goal would be semantically confusing and so it 
would get in the way of using the information that something is fact in 
inference or search.

the reason why users could do without a "fact" keyword is similar to why they 
could do without "action/condition/effect", you can express the problems in 
terms of variables/tokens/objects but you get cleaner modeling if you have 
those other concepts (granted they shouldn't be obviously redundant), and more 
importantly, building more intelligent behavior is pretty hard without them. 
For instance, having action/condition/effect we can write more efficient 
planners, having facts vs goals should allow us to deal better with 
real-word/execution updates. 
We could translate everything to a CSP, use just variables and do away with 
objects and tokens, but that would make things much more difficult. In my mind 
fact vs. goal is useful less dramatically, but in the same spirit.

I've looked into fixing this a couple of times in the past but it'll take more 
than a few minutes, all that needs to be implemented is to ensure that facts 
can only be merged with other facts and I think we'll have a consistent 
implementation.

Original comment by javier.barreiro@gmail.com on 4 Feb 2012 at 8:19

[GoogleCodeExporter]

Original comment by javier.barreiro@gmail.com on 30 May 2012 at 5:26

• Added labels: Milestone-EUROPA-2.7
• Removed labels: Milestone-EUROPA-2.6

[GoogleCodeExporter]

I've added a checkError in 6753 to make sure that facts are only merged onto 
other facts.  How the user should be made aware of having tried something silly 
isn't well thought-out in Europa yet.

Original comment by miata...@gmail.com on 22 Sep 2014 at 9:53

• Changed state: WontFix