[m-users.] Performance of solutions module

[Charlie McGee]

>Actually, I would advise against doing this. The code of solutions/2 has
to do
>something that cannot be done in pure Mercury: communicating information
>between different branches of a disjunction. It therefore has to use
impure code,
>even though the interface it is implementing has a pure semantics. This
works,
>but I wouldn't recommend the code to nonexperts.

>TL/DR: if you have no simple way to construct your list directly, then use
>the Mercury library's solutions/2, or one of the other predicates in the
solutions
>module; do NOT try to roll your own.

Thank you for the clarification on this. I am still learning. I'm starting
to get a decent grasp of how the language works in a single solution
context, but I'm still learning how the compiler handles nondet code.  One
of my biggest points of confusion/frustration is how cc_multi and cc_nondet
work exactly, the semantics of the comitted choice modes.  Do they work in
terms of a greedy 'first result is good enough if called in a single
solution context'?  I need to work on my understanding on how det code
works with nondet code.

On Fri, Nov 2, 2018 at 3:16 PM Zoltan Somogyi <zoltan.somogyi at runbox.com>
wrote:

>
>
> On Fri, 2 Nov 2018 15:04:15 -0400, Charlie McGee <c4cypher at gmail.com>
> wrote:
>
> > >If you can construct a list of solutions directly, that will usually be
> > faster
> > >than using solutions/2, since the latter has nontrivial overhead.
> Whether
> > >it will be *measurably* faster depends on what fraction of the program's
> > >overall runtime this task takes, and on whether your direct method
> > >for construction of solutions requires a post-pass to sort the
> solutions,
> > >or to eliminate duplicates (two tasks that solutions/2 does for you,
> > >and which form part of its overheads).
> >
> > Building on Zoltan Somogyi's suggestion to construct your own list
> instead
> > of relying on solutions/2, if you want to get an idea of how to do that,
> > you can look on how the solutions library implements its calls by looking
> > through solutions.m
> > <
> https://github.com/Mercury-Language/mercury/blob/master/library/solutions.m
> >
> > in the library folder of the Mercury source code (The Mercury Lang github
> > repository is very useful for this).
>
> Actually, I would advise against doing this. The code of solutions/2 has
> to do
> something that cannot be done in pure Mercury: communicating information
> between different branches of a disjunction. It therefore has to use
> impure code,
> even though the interface it is implementing has a pure semantics. This
> works,
> but I wouldn't recommend the code to nonexperts.
>
> TL/DR: if you have no simple way to construct your list directly, then use
> the Mercury library's solutions/2, or one of the other predicates in the
> solutions
> module; do NOT try to roll your own.
>
> Zoltan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20181105/1a9776bc/attachment.html>