[m-users.] Inferring over dynamic data

[Stepp, Nigel D]

(Pardon my work-mandated mail reader and its top-posting)

Ah yes, you caught my partial edit from ABs to Xs :)

So the assertion (heh) is that for any kind of computation that would use a dynamic database, there is a solution that can rely on a data structure. I have read that before, and in the example here, I see how that makes sense, but right, it depends on the kind of data.

My actual facts are a dozen or so predicates that describe the state of a simulated environment, and the static predicates encode rules about behavior between actors in that environment.

What I'm hearing is that I should replace logical inference with more explicit computation. Is that fair to say?

And thank you very much for indulging my beginner questions! As I mentioned, I'd very much like to move to mercury; I am really missing type safety in my current code.

--
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: Zoltan Somogyi <zoltan.somogyi at runbox.com>
Sent: Monday, January 17, 2022 5:19 PM
To: Stepp, Nigel D; users
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.





2022-01-18 09:44 GMT+11:00 "Stepp, Nigel D" <ndstepp at hrl.com>:
> What is a good way (or I guess any way) of transforming a pattern like the above to something in mercury?

That depends on what kind of data you want to assert.
The Mercury standard library has a whole bunch of modules
that each define a data structure, together with the usual operations
on that data structure: lists, sets, bags, maps, multi_maps, graphs, etc.

> 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).

The most precise translation of this Prolog code into Mercury
would be three error messages: one each about ABs and Xs being singletons,
the third about the output argument of callP being left undefined :-)

> 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].

The actual replacement would be something like:

set.list_to_set([x, y], SetA),
set.list_to_set([y], SetB),
set.intersect(SetA, SetB, SetAB)
set.to_sorted_list(SetAB, Result)

yielding Result = [y],

or, if it duplicates are allowed, the equivalent of the above
using bags.

Zoltan.
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.