Brancher for tracing

26 views
Skip to first unread message

Philippe Morignot

unread,
Jul 21, 2026, 1:35:41 PMJul 21
to gec...@googlegroups.com
Hi,

I am writing to you for the following question: I have defined several branchers that execute some source code on a model, following section 8.14 of MPG “Executing code between branchers”. Two of these branchers (lines 2 and 6 below) are for tracing the behavior of the search engine only: printing text and variables on std::cout. And what surprises me is that commenting out these two tracing branchers leads to a slightly different search tree than not commenting them out …

The statistics at the end of a run show that there are more propagations (1682 vs. 1319) and less nodes (26 vs. 37) without tracing branchers than with them.

Would someone have an explanation for this? Here is an excerpt of the source code: (with tracing branchers of lines 2 and 6 commented out)

 

1   for (int i = 0 ; i < is_performed.size() ; i++) {

2         //branch(*this, lambda_print_begin);      // print text and variables on std::cout

3         branch(*this, is_performed[i], Gecode::BOOL_VAL_MAX());

4         branch(*this, lambda_assign_vars1);

5         assign(*this, object_id[i], Gecode::INT_ASSIGN(lambda_select_object));

6         //branch(*this, lambda_print_end);      // print text and variables on std::cout

7  }

 

Philippe

Mikael Zayenz Lagerkvist

unread,
Jul 21, 2026, 6:38:33 PMJul 21
to gec...@googlegroups.com
Hi,

The tracing propagators create unary branches in the search tree, so
it is reasonable that there will be more nodes. If you use Gist, they
should be visible in the search tree.

As for propagations, I am not sure what might be the reason. One
reason might be because adding unary branchers does change the depth,
and thus changes where copies are left, which probably has an impact.

Cheers,
Mikael
> --
> You received this message because you are subscribed to the Google Groups "Gecode" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gecode+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/gecode/714035349.1472937.1784655335958%40mail.yahoo.com.



--
Mikael Zayenz Lagerkvist

Philippe Morignot

unread,
Jul 23, 2026, 1:05:54 PMJul 23
to gec...@googlegroups.com
Hi,

Thank you for your answer!

Is there a way other than Gist to trace the behavior of a search engine without changing the search tree?

Cheers, Philippe

Philippe Morignot

unread,
Sep 11, 2026, 10:46:37 AM (14 days ago) Sep 11
to Mikael Zayenz Lagerkvist, gec...@googlegroups.com
Dear Mikael,

Thank you very much for your answer. I am now trying to reformulate my question so that it is more answerable:

We would like to trace the execution of Gecode, this would help us debug our model. Seeing which choice points are considered by the search engine, and when, and on which decision variables, etc. I know that Gist is Gecode's feature for doing exactly that. But rigth now we do not have the graphical package Qt in our software installation, so we cannot install Gist while installing Gecode...

Tracing branchers (see my post of July 21 on Gecode's mailing list) could also be an answer to our need, but, as stated earlier, the shape of the search tree is slightly changed because tracing branchers create unary branches in the search tree  (thank you again for your answer of July 22).

So I was wondering if there exists in the Gecode software a third way to trace the execution of the search engine, if possible without modifying the search tree? How do people usually trace the execution of search engines? Are we forced to install Qt in order to use Gist for this purpose, or does there exist a way to do this which we missed? ... ? I would appreciate any comment along this direction.

I hope that my question is now more answerable. 

Cheers. Philippe


Le vendredi 28 août 2026 à 16:19:45 UTC+2, Mikael Zayenz Lagerkvist <zay...@gmail.com> a écrit :


Hi.

I'm unsure what you are asking for, also why no one answered your previous mail.

You have tracing branchers if that is needed. You have gist for seeing
the search tree. You have the statistics for summary statistics.

If you want answers, consider actually writing out a question that can
be answered.

/Mikael

On Tue, Aug 25, 2026 at 10:50 AM Philippe Morignot <pmor...@gmail.com> wrote:
>
> Dear Mickael,
>
> I am directly writing to you because I have a question about Gecode which was not answered on the Gecode mailing list (see below).
> Here it is:
>
> I would like to trace the behavior of Gecode. The MPG says that the way to do that is to use the graphical package GIST.
> And here my question: Is GIST the only way to trace Gecode's behavior, or does there exist other ways to trace its behavior, like using the std::cout construct somewhere in the source code?
>
> I would appreciate any help on this point.
>
> Best regards, Philippe
> ----- Message transféré -----
> De : Philippe Morignot <pmor...@gmail.com>
> Envoyé le : jeudi 23 juillet 2026 à 19:05:47 UTC+2
> Objet : Re: [gecode] Brancher for tracing
--
Mikael Zayenz Lagerkvist

Mikael Zayenz Lagerkvist

unread,
Sep 15, 2026, 12:31:53 AM (10 days ago) Sep 15
to Philippe Morignot, gec...@googlegroups.com
Hi,

I'm still a bit unsure what you are aiming for here. As said, tracing
and Gist are our two main generic observability features. Tracing does
change some statistics about the search tree, but it doesn't really
change the behavior of the search.

You could always add some logging inside the search engine whenever it
asks for a new decision from a brancher, which seems to be what you
want. I don't think I would feel that that would give me any
actionable information.

Cheers,
Mikael
--
Mikael Zayenz Lagerkvist
Reply all
Reply to author
Forward
0 new messages