Hi,
No. If a variable which restricts A gets unlocked, the objects which
where removed from the temporary domain of A because of B needs to
be readded.
However I don't know how it is currently done, because the storage
of these removed objects was changed when you implemented the new
change API (now the objects are stored in a DomainChange container,
but I don't know whether this is the only change or not)
As for the second point: Yes, calling resetVariables in eval() is
fine. The prior line with findGraph() does a complete matching of
its graph and leaves the domain slots in a dirty state (either with
all slots locked and a valid match or all slots unlocked with empty
domains because no solution was found).
The eval() function is called recursively for each graph in an
application condition tree. So for your example a match for the lhs
would include a valid (non)-match for the NAC. However each call to
the eval() function of the NAC is done with a different match in the
lhs and the NAC domain slots must therefore be clean.
Cheers,
Enrico
On 11.06.2012 09:43, Christian Krause wrote:
Hi Enrico,
ok. Does that mean that the temporary domain for a variable A
should be reset whenever a variable B that restricts the domain of
A gets unlocked?
I noticed also that resetVariables() is called in
ApplicationCondition.eval(). So that means whenever we check
whether a found match for a NAC is valid, we reset the variables
and delete all temporary domains? Why are the domain slots cleared
at this point and should the temporary domains really be reset
here?
Cheers,
Christian
On 06/11/2012 07:44 AM, Enrico Biermann wrote:
Hi,
Assume a lhs with B->A.
If a variable is not initialized its domain is initialized by
all possible values for its type, e.g. a graph has 5 nodes of
type A, so the domain is set to 5. In the above example when
matching B, the domain of a A has to be restricted too (to all
outgoing edges from the fixed node B in the graph to A nodes).
This information is stored in the temporary domain. If the
temporary domain of A is already set when the domain is
initialized. The status of the temporary domain is used instead
of the type constraint to set the domain.
This has other consequences, too. For example if 2 different
constraints to A restrict the temporary domain to empty, you can
immediatly start to backtrack because you will never be able to
initialize the domain of A.
Cheers,
Enrico
On 10.06.2012 21:01, Christian Krause wrote:
Hi,
I guess then we have to figure out when exactly the
temporaryDomain should be cleared and when not (or how to fix
it otherwise). Enrico: if I understand it correctly, the
temporaryDomain is used to restrict the domain further when
some of the variables have been matched already (?).
Initially, I thought the temporaryDomain is just used for
performance reasons, but that seems not to be the case. Can
you tell us a bit about its purpose?
cheers,
Christian
On 06/10/2012 02:18 PM, Stefan Jurack wrote:
The reference model is correct! It has been published along
the ttc2011 workshop and other approaches led to the same
solution too.
Stefan
Am 09.06.2012 15:11, schrieb Christian Krause:
Either the reference model is incorrect, or the bugfix
introduced another bug.
Cheers,
Christian
On 06/09/2012 02:56 PM, Christian Krause wrote:
Hi,
I looked into the Java2StateMachine example. It seems
like one Transition with action="" and trigger="FIN"
is not generated and some of the transitions are not
correctly wired up. Are we sure the reference model is
correct?
Cheers,
Christian
On 06/09/2012 11:35 AM, Enrico Biermann wrote:
Hi,
I found the bug. The temporary domain of a domain slot
was not reset after a failed match attampt.
So the scenario was the following:
1) LHS matched
2) NAC did not match, but the temporary domain of the
forbidden node still contained an element
3) LHS matched again
4) When checking whether a specific edge would still
be possible, a reference constraint failed because the
old temporary domain did not contain possible target
values for the reference.
I attached a patch. However if you apply it, one of
the tests (testJava2StateMachine) will fail. Still, I
think that not resetting the temporary domain is a bug
and possibly the test is in error in this case.
Cheers,
Enrico
On 09.06.2012 11:06, Enrico Biermann wrote:
Hi,
I debugged the example.
The error occurs when trying to match a "ver" edge.
Based on the fact that the target domain slot is not
initialized I guess that it is the edge from the top
right node to the bottom right forbidden node (in
the diagram file).
The reason that the NAC does not match is because
the domain of the forbidden node is empty. I don't
know yet why but I will see if I can find out.
Cheers,
Enrico
On 08.06.2012 14:21, Christian Krause wrote:
I created a minimal example of the error. Copy the
two files into the 'combpattern' package and run
it. It should not find a match. The graph has this
structure:
o---o
| |
o---o
| |
o---o
On 06/08/2012 02:05 PM, Christian Krause wrote:
Hi Enrico,
I still don't know where the problem is. I know
exactly when and where it happens (step #7) but
I don't know why. No match for the NAC is found.
The graph is correct at this point and the rule
is also fine as far as I can tell. The debugging
is really difficult. I did not really understand
what you meant by making a rule for each
constraint type. Can you maybe give me some more
hints how to debug this?
Cheers,
Christian
On 06/03/2012 11:06 AM, Enrico Biermann wrote:
Hi,
true, the optimization is not the problem,
however it probably uncovered a bug in the
constraints. you could make a rule for each
constraint type present in the application
condition of addNewColumn and then switching
the order of variables (a nice side benefit is
that these rules would also make great unit
tests).
At least one variable order of one rule should
fail to match.
Regards,
Enrico
On 03.06.2012 10:53, Christian Krause wrote:
Hi,
I couldn't find a bug in the example. The
optimization is not the problem. I changed
the order of the nodes in the NAC and now I
get the error with and without the
optimization.
From the log I can see that the NAC was not
correctly checked. There does exist an
object and two edge, so the rule should not
be applicable to this match. The interpreter
prints waring now that edges are deleted due
to a side effect. I still don't know why the
match finder has a problem.
Cheers
Christian
On 06/03/2012 10:38 AM, Enrico Biermann
wrote:
Hi,
The order of variables should be
irrelevant (for correct results).
If it is not, then it points to either a
missing constraint or an incorrect
handling of either initialized or
uninitialized domain slots for an existing
constraint.
The order of nodes for the application
condition of addNewColumn was changed from
1, 2, 3, 4, 5 (order of creation) to 3, 1,
4, 5, 2. So a constraint of 3, 4 or 5
should be responsible, but someone with
knowledge of the example should continue
with the analysis.
Regards,
Enrico
On 02.06.2012 18:07, Christian Krause
wrote:
Hi,
if you want to see why the optimization
is important: check out the latest
version of the examples and run the
STSBenchmark with and without the
optimization (order of magnitude faster
with optimization).
Enrico: does the MatchFinder assume any
particular order of the variables in the
value lists returned by
ruleInfo.getVariableInfo().getGraph2variables()
? All I was doing is to sort the lists.
Cheers,
Christian
On 06/02/2012 11:06 AM, Christian Krause
wrote:
Hi,
I added the examples to the SVN. My
last optimization causes the
comp-example to fail. I commented out
the optimization in line 342 of
EngineImpl therefore. So for now it
works, but we should try to fix it so
that the optimization can be used. It
seems like the NAC of addNewColumn is
not properly checked when the
optimization is used (nodes are added
in every rule application for the same
match).
I turned on the logging. So if you
want to try it out, do this:
1) run CombBenchmarkManyMatches
(works)
2) comment line 343 and uncomment
344-350 in EngineImpl and execute it
again (will not stop).
Cheers,
Christian
On 06/02/2012 10:06 AM, Dmitry
Zakharov wrote:
Hi Christian,
I am giving you the short summery of
all test cases. With red I highlight
those where hanshin is slower.
1) STS: Henshin is
faster
2) LTS:
Henshin
StoryDiagram
N=20 R=10000 50541
ms 76562 ms
N=500 R=1 120765 ms
21505 ms
3)
ALAP: Henshin and SD
have time same time
Nodes HENSHIN
StoryDiagram
1000 468 ms
571 ms
5000 6973 ms
6751 ms
10000 29319 ms 30936
ms
4) Program Understanding
: Henshin is faster
5) Comb Many-Matches
Henshin
Story Diagram
Grid 50, pattern size 10
(2009 matches) 48725
1098 ms
Grid 50, pattern size 50
(49 matches) 46747
748 ms
6) Comb No-Match
Henshin
Story Diagram
Grid 200, pattern 10
38551
ms 1478 ms
Grid 200, pattern 50
54934
ms 3109 ms
regards, dmitry
on 02.06.2012 9:19, Christian Krause
wrote:
Hi Dmitry,
I have one more request: could you briefly summarize where Henshin was
slower than SD and also give us a hint how much slower it was? This
would be very helpful for the profiling and optimization.
Cheers,
Christian
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev
|