Re: [Potassco-users] How to get information 'from inside' clasp?

[Martin <mj...@cs...>]

On Fri, 2011-10-07 at 19:12 +0100, Mário Abrantes wrote:
> Em 07-10-2011 12:13, Martin escreveu:
> > On Thu, 2011-10-06 at 16:03 +0100, Mário Abrantes wrote:
> >> Em 06-10-2011 3:55, Martin escreveu:
> >>> On Wed, 2011-10-05 at 17:44 +0100, Mário Abrantes wrote:
> >>>> Hi.
> >>>>
> >>>> For a certain implementation, I'm interested in knowing the logical
> >>>> values of certain atoms, while clasp is calculating the models.
> >>> May I ask why?
> >> Thanks for asking, Martin.
> >> The point is that  for programs like
> >>
> >> a :- b
> >> b :- a
> >>
> >> a :- not w
> >> w :- not a
> >>
> >> I want to solve them by abducing the atoms of the negative literals. I
> >> don't want the solver to solve the negative loop without 'asking' for
> >> abductives, in this case 'w' or 'a'. For that purpose I must get rid of
> >> default negation, via a transform. With this transform, 'a' is in a
> >> model if 'a' is true, and 'an' is in a model if 'a' is false, there is
> >> no default negation.
> > So you want a different semantics?
> Yes. I'm implementing a new semantics, the Minimal Hypotheses Semantics, 
> developed at CENTRIA, Lisbon, http://cl.ly/1q032d0M1O2R2g2G0430.
> It generalizes the SM semantics, solving some problems that baffle 
> Answer Sets. No pain no gain, complexity of the new semantics in the 
> case of brave reasoning is Sigma^P_2.

OK.  In which case you might want to think carefully about the
architecture of the system you are building.  You could potentially add
some support during the search, in the style of SMT solvers / custom
propagators but I've heard mixed views about running anything more than
linear algorithms during search is a good idea.  It might be better to
look at claspD (or perhaps GnT) which is performing a similar task.

> >>   Perhaps I´ll resort to an imperative language to solve this matter.
> > The translation is probably best done via an imperative language but I
> > would advise against trying to solver the whole thing procedurally as
> > you will wind up having to re-invent / re-implement much of the
> > technology in clasp.
> It would be painful :). Only as a last resort...

Start with claspD, it should be possible to do something similar for
your semantics.

HTH

Cheers,
 - Martin