[m-users.] Inferring over dynamic data

[Stepp, Nigel D]

Yes, this is exactly the kind of thing I'm interested in. What I don't get, though, is how you can use backtracking and forward inference chaining, etc on the data structure as if it were a collection of facts. When I think about doing that, it seems as though I am reimplementing part of the core language.


If anyone has pointers to an example of this kind of method, I would be very appreciative.​


Is it the case that every predicate that would otherwise rely on the database of facts, should instead have a preamble that extracts and attempts unification with some part of the data structure?


Something like (but almost certainly not actually using memberchk):


p(Facts,A,B) :-

    memberchk(factA(A),Facts),

    memberchk(factB(B),Facts),

    ...


I feel like what I want is something like a monadic state a la Haskell where the database used for solving is provided that way.


--
Nigel Stepp, Ph.D. Information and System Sciences Lab HRL Laboratories, LLC.
3011 Malibu Canyon Road, Malibu, CA 90265 Office: +1 310-317-5267

________________________________
From: Richard O'Keefe <raoknz at gmail.com>
Sent: Monday, January 17, 2022 5:44 PM
To: Stepp, Nigel D
Cc: users at lists.mercurylang.org
Subject: Re: [m-users.] Inferring over dynamic data



This message was sent from outside of HRL. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.





A dynamic predicate in Prolog is, to a first approximation,
a set of terms.  Way back in the 80s, I did some experiments,
and found that several examples that I tried worked faster
if I represented such a set of terms as a data structure.
It depended on what exactly the program was doing, and how
much work I put into indexing the data structure.  But it
was the rule, not the exception, for a data structure to be
a better choice than a dynamic predicate, *in Prolog*.

I still remember with somewhat mixed feelings demonstrating
to a Quintus customer that his program could run 700 times
faster if he didn't use the dynamic data base.  Good feelings
because 700 times faster.  Bad feelings because we lost that
customer.  (:-(

On Tue, 18 Jan 2022 at 11:49, Stepp, Nigel D <ndstepp at hrl.com<mailto:ndstepp at hrl.com>> wrote:
Hello all,

I am very interested in switching a prolog codebase to mercury, but parts of the codebase follow a pattern like:

- receive a list of facts
- assert facts
- do inference using static predicates
- retract facts

I'm well aware that mercury does not support assert/retract, and I read a very old thread that was an interesting discussion (https://lists.mercurylang.org/archives/users/2006-January/003388.html<https://protect2.fireeye.com/v1/url?k=31323334-501d2dca-3131c93c-454455534531-ee10946f769ec827&q=1&e=8071032b-1c25-4ccf-936e-df8008a89317&u=https%3A%2F%2Flists.mercurylang.org%2Farchives%2Fusers%2F2006-January%2F003388.html>).

The issues in that thread were complicated by dynamic loading of modules, however. I am only interested in the list-of-facts part.

What is a good way (or I guess any way) of transforming a pattern like the above to something in mercury?

A tiny example is something like this:

:- dynamic factA/1.
:- dynamic factB/1.

p(A,B) :- factA(A), factB(B).

callP(Facts, ABs) :-
    assertFacts(Facts),
    findall(X, p(X,X), Xs),
    retractFacts(Facts).

Where assertFacts/1 and retractFacts/1 do the obvious-sounding things. Facts might be something like [factA(x),factB(y),factA(y)], with answer Xs=[y].

--
Nigel Stepp, Ph.D. Information and System Sciences Lab HRL Laboratories, LLC.
3011 Malibu Canyon Road, Malibu, CA 90265 Office: +1 310-317-5267

CONFIDENTIALITY NOTICE: The information transmitted in this email, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential, proprietary and/or privileged material exempt from disclosure under applicable law. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this message in error, please contact the sender immediately and destroy any copies of this information in their entirety.
_______________________________________________
users mailing list
users at lists.mercurylang.org<mailto:users at lists.mercurylang.org>
https://lists.mercurylang.org/listinfo/users<https://protect2.fireeye.com/v1/url?k=31323334-501d2dca-3131c93c-454455534531-90cbb4a841f9c436&q=1&e=8071032b-1c25-4ccf-936e-df8008a89317&u=https%3A%2F%2Flists.mercurylang.org%2Flistinfo%2Fusers>
CONFIDENTIALITY NOTICE: The information transmitted in this email, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential, proprietary and/or privileged material exempt from disclosure under applicable law. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this message in error, please contact the sender immediately and destroy any copies of this information in their entirety.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20220118/1039c6e7/attachment-0001.html>