March 2003 \pagerangeLABEL:firstpage–C
Planning for an Efficient Implementation of
Hypothetical BousiProlog
Abstract
This paper explores the integration of hypothetical reasoning into an efficient implementation of the fuzzy logic language BousiProlog. To this end, we first analyse what would be expected from a logic inference system, equipped with what is called embedded implication, to model solving goals with respect to assumptions. We start with a propositional system and incrementally build more complex systems and implementations to satisfy the requirements imposed by a system like BousiProlog. Finally, we propose an inference system, operational semantics, and the translation function to generate efficient Prolog programs from BousiProlog programs. This paper is under consideration for acceptance in TPLP.
doi:
S1471068401001193keywords:
Fuzzy Logic Programming, Fuzzy Prolog, BousiProlog, Hypothetical Reasoning, System Implementation1 Introduction
Hypothetical reasoning allows deductions to be made in terms of assumed data. Applications include planning and scheduling [Wilson and Nuzzolo (2008)], logistics [Calantone et al. (2017)], behaviour [Bosse and Gerritsen (2009)], healthcare [Minutolo et al. (2016)], law [Bench-Capon and Prakken (2010)] and everything related to decision making in the scenarios envisioned. This so-called ‘what-if’ analysis [Rizzi (2009)] plays an important role in saving resources, time and money. For example, designing the pipe network of a gas company includes an assessment of the appropriateness of conversion stations and pipes in terms of gas production, sourcing and expected client demand.
In addition, real-world applications must typically handle not-yet-known data, foreseeing scenarios for which it is necessary to handle vague information. Fuzzy logic is suitable for such imprecise and subjective knowledge, and has been successfully applied to such different fields as process control (e.g., UAV flight control [Moreno and Vázquez (2014)], Japan Sendai Subway with its ATC/ATO security system, domestic appliances such as Samsung dishwashers…), deductive databases (FSQL [Galindo (2005)], a fuzzy version of SQL), and fuzzy expert systems (such as [Kunhimangalam et al. (2013)] in the healthcare domain).
Combining features from both hypothetical reasoning and fuzzy logic thus seems a reasonable field to study. This paper deals with such a combination for the inclusion of hypothetical reasoning (with features derived from intuitionistic logics) in the BousiProlog (BPL) fuzzy logic system [Rubio-Manzano and Julián-Iranzo (2014), Julián-Iranzo and Rubio-Manzano (2017)]. In particular, we focus on embedded implications, as in [Bonner (1994)]. Assumptions can be reused throughout proofs in this kind of logic, in contrast to substructural logics [Lopez and Pimentel (1999)]. Basically, the following inference rule, which uses so-called embedded implication ‘’ [Bonner (1994)], captures the fact that hypothesis (a rule) is used (as many times as needed) to derive the proof for goal in the context of program :
This inference rule means that if the inference expression above the line can be inferred, then the one below the line can be inferred too. However, this inference rule, linked to the deduction theorem of classical logic, only models a small part of the characteristics and power of hypothetical reasoning.
This paper explores a path to an efficient implementation of hypothetical reasoning in Bousi Prolog. As developed for SWI-Prolog [Wielemaker et al. (2012)], this Prolog system is considered here for implementations. Firstly, Sections 2 to 3 incrementally develop a hypothetical logic inference system. Specifically, Sections 3.2 and 3.3 introduce the requirements that BousiProlog imposes on hypothetical reasoning that need to be tackled and how they can be addressed in the hypothetical logic inference system. Section 4 recalls the formalisation of BousiProlog and adapts it to efficiently include hypothetical reasoning in this language and system. Finally, Section 5 gives the conclusions and sets out further work to be addressed. Three appendices contain a performance analysis, formal proofs and a discussion on related work.
2 Implementing a hypothetical propositional logic inference system
As a first step, we study how to introduce hypothetical reasoning in a propositional logic framework where a program comprises rules of the form , where is a propositional letter, called the head of the rule; and are propositional letters or embedded implications which form the body. A rule is written as . An embedded implication is an expression of the form where is a rule (possibly with embedded implications in its body) and is a propositional letter. Embedded implications cannot appear as the head of a rule. Note also that embedded implications can be nested. That is, the expression is a well-formed expression of this language. In the following, we shall write nested embedded implications as , omitting the parentheses.
2.1 Hypothetical propositional SLD resolution
A basic hypothetical propositional logic transition system is first defined, to determine the operational semantics of the language.
Let be a program. Let be a set of tuples (goal, program), each representing a state of a computation. Let be the transition relation as now defined in Definition 2.1. A successful inference sequence for a given state is a sequence ending in the state , where represents the empty clause.
Definition 2.1
Hypothetical Propositional SLD (HPSLD) resolution is defined as a transition system ,
and whose transition relation
is the smallest relation satisfying:
Rule 1:
if :
Rule 2: if , with , is a successful inference sequence:
The following simple program, adapted from [Bonner (1994)], illustrates this definition.
Example 1
Given the program and the goal , the successful derivation is possible thanks to the hypothetical query associated derivation: where the initial program is expanded with the hypothesis .
This definition of hypothetical propositional resolution can be neatly implemented in Prolog with a meta-interpreter keeping track of the current program, which can be augmented as needed by the embedded implication. Proposals of other logic systems [Bonner (1994), Lopez and Pimentel (1999)] also suggest this kind of implementation (passing the program as an argument). The solving of an embedded implication can be implemented in a meta-interpreter with the clause: (cf. Appendix A). But passing the program as an argument in Prolog requires that its data structure be built in the heap, a costly operation. Another alternative is to use the dynamic database to assert the program rules. In contrast to other Prolog implementations, SWI-Prolog does not differentiate between compiling and asserting, producing a similar code for both operations which, in particular, retains multi-argument and deep indexing. In this way, accessing data in dynamic memory is typically faster than in the heap, even using techniques such as Key-Value associations implemented as a balanced binary tree (AVL tree).
A first approach to dealing with the embedded implication is to consult the program as a normal Prolog program with a definition for the embedded implication with the operator : Thus, it is possible to answer goal for program {}: solving amounts to asserting and subsequently solving goal . When has been proved, the assumption is retracted. However, this approach is not correct because alternatives can be lost. Consider the program {, , }. Clearly, there should be two answers for goal but, after solving for the first answer, the hypothesis is retracted, so that further answers are lost.
Simply removing the retraction does not fix the issue because the hypothesis would then be beyond the scope of the implication. For example, in the program {}, the goal would succeed when it should fail because the second call to is outside the scope of the embedded implication. Instead, a plausible approach is to attach each hypothesis to the program context it belongs to, and allow its selection only in that context, which is the technique explained in the next section.
2.2 Program contexts to implement embedded implications
Rule 2 in Definition 2.1 constructs a proof for the consequent in the context of , where is the current program and is the antecedent of the embedded implication (hypothesis). Thus, each assumption builds a new program which can be understood as a program context for the proof of a consequent.
Definition 2.2
Given a program and an embedded implication query , the hypothetical context (or simply a context) of a proof for is the program .
Because embedded implication queries can be nested, , also hypothetical contexts can be chained , where . Hypothetical contexts are partially ordered by the set inclusion relation . For pragmatic reasons, contexts can be identified by a sequence of unique symbols, one for each new context in the inference sequence. For the chain of contexts , the sequence of symbols , , identifies the context , where stands for the initial user program (for which the empty sequence is assumed as its context identifier).
More formally, given a (possibly total ordered) set of indexes , a context can be identified by a univocal sequence of indexes , , called a context identifier, and alternatively denoted by . For a context , with context identifier , and an embedded implication query , a new context is built, where the context identifier is the concatenation of a fresh index to the sequence . The initial user program is denoted by , where is the empty sequence.
The set of context identifiers is a prefix-ordered set, where the prefix relation on is defined as follows: for two context identifiers and , if and only if is a prefix of ; that is, there exists a sequence of indexes such that . The prefix relation is reflexive (), anti-symmetric (), transitive () and downward total () [Cuijpers (2013)]. The first three properties classify a prefix order as a partial order. Only the downward totality is special, meaning that, although the future evolution of a computation may be branching, from a given point of execution, the past is always totally ordered. In our framework, where the set of sequences has a minimum element (the empty sequence ), the evolution of a computation can be abstracted by a tree structure, where the branches are sequences representing a context identifier and each prefix in the sequence, a previous context identifier. By construction, for all context identifiers and , if then .
As contexts are sets of rules, each rule can be identified as belonging to a context by the identifier of its program context. Thus, a context identifier can be associated with a rule.
Definition 2.3 (Scope of a rule)
Given a rule with context identifier , its scope is any context such that .
In the framework of hypothetical reasoning, a rule only can be selected for solving if it is within the scope of the current context. Alternatively, we often say that , with context identifier , is included in (or belongs to) the context , because when . Thus, from a context it is possible to access all rules whose context identifier is a prefix of .
2.3 Translating hypothetical propositional programs into Prolog
Hypothetical propositional SLD resolution can be efficiently implemented by translating hypothetical propositional programs into Prolog in a such a way as to mimic this operational semantics. This translation is based on, first, providing a context identifier for each rule (either a user-program rule or the hypothesis in an embedded implication); and, second, transmitting the current context for which the rule is selected during inferencing. Each hypothesis receives a new index symbol (an integer for simplicity) which is added to the current context identifier sequence to form the identifier of the new context. This sequence can be implemented as a reversed integer list.
In contrast to the basic implementations in Section 2, user programs and hypotheses must be translated by adding the new arguments for the rule and current context identifiers:
Definition 2.4 (Propositional rule and goal translation)
The rule translation of for a rule context identifier and a current context identifier , is defined as where checks context inclusion (i.e., whether ) and the goal translation , for the current context identifier , is either:
-
•
for a built-in call; or
-
•
for a user-predicate call, where is a new free variable representing any context in the scope of the current context ; or
-
•
for an embedded implication , where: is the rule translation of for a rule context identifier (where is a fresh index) and a new current context identifier , and is the goal translation of for a current context identifier .
Definition 2.4 deserves some comment. Firstly, variables (e.g., or ) denote context identifiers, which may be unknown at translation time. In general, (or ) denotes the context to which a rule (or ) belongs, while (or ) denotes the current context in which the rule will be selected for solving or the goal will be solved.
Since an embedded implication generates a new context , the corresponding hypothetical rule will be annotated with , which will be the current context in which the goal G will be solved. It is not possible to set the actual index in the sequence for the embedded implication until solving-time (also, depending on the goal, not all contexts will be needed). Actually solving an embedded implication will bind the elements in the sequence representing the context. As always holds, it can be omitted in the translation. The following example illustrates Definition 2.4 for a simple program rule:
Example 2
Assume the source program rule . For a source rule , the rule context identifier . Applying Definition 2.4 to translate for , leads to: , where is the translation of the embedding implication .
In order to translate , consider that is really seen as the rule (shorthand for , where is a built-in symbol). Then, recursively applying Definition 2.4, the translation of for the rule context identifier (where is a fresh variable denoting an unknown index which will be resolved at run-time) is . The translation of is simply , where is a fresh variable.
The translation of is: where the call to has been omitted because, as previously mentioned, it always succeeds.
Our actual implementation produces the following translated Prolog rule for , where calls are omitted:
p([], A) :- (q([B|A], C) :- chk([B|A], C)) => q(_, [B|A])
where is straightforwardly implemented as:
chk(S1, S2) :- append(_, S1, S2)
.
Solving the embedded implication can be implemented as follows:
Definition 2.5 (Solving the propositional implication clause)
Solving the propositional implication clause for SLD resolution is defined as:
.
where the predicate /1 returns a unique integer each time it is called,
and /2 simply provides access in its second argument to the context of .
Considering as the transition relation for propositional SLD resolution of a program , where is a set of states formed by tuples (goal, substitution, program), the following can be stated:
Proposition 2.6
For a program and goal , there exists iff , where is the propositional translation of each rule in , and is the propositional goal translation of .
See the proof of Proposition 3.6 in the predicate logic case, of which this is a particular case.
3 Implementing a hypothetical predicate logic inference system
In this section we discuss how to extend hypothetical reasoning from the framework of propositional logic to the framework of predicate logic as a prior step to the introduction of hypothetical reasoning into the fuzzy logic programming language BousiProlog.
As in the propositional case, the programs of our hypothetical logic language are sets of rules of the form , but composed of atomic formulas instead of only propositional letters. Rules are assumed to be universally quantified and the occurrence of extra variables in the body of a rule can be understood as existentially quantified. When translating embedded implications, the question of how to deal with their variables is an important one.
3.1 Hypothetical SLD resolution
Definition 2.1 can be extended to the non-propositional case by dealing with substitutions, which then become part of the notion of computation state. Let be a set of tuples (goal, substitution, program), each representing a state of a computation. Let be the transition relation as defined in Definition 3.1 below. A successful inference sequence for a given state is a sequence ending in the state .
Definition 3.1 (HSLD resolution)
Hypothetical SLD (HSLD) resolution is defined as a transition system ,
whose transition relation
is the smallest relation satisfying:
Rule 1:
if and :
Rule 2:
if is
a successful inference sequence with :
As in the propositional case, HSLD can be implemented as a meta-interpreter, and Definition 2.4 can easily be extended to the predicate logic case by using predicates instead of propositions:
Definition 3.2 (Rule and goal translation for predicate logic)
The rule translation of for a rule context identifier and a current context identifier , is defined as the rule where checks context inclusion (i.e., whether ) and the goal translation of for the current context identifier is either:
-
•
for a built-in call; or
-
•
for a user-predicate call, where is a new free variable representing any context within the scope of the current context ; or
-
•
for an embedded implication , where: is the rule translation of for a rule context identifier (where is a fresh index) and a new current context identifier , and is the goal translation of for a current context identifier .
The following example illustrates Definition 3.2 for a simple program that will be used in several places hereafter:
Example 3
Given the source program , note that all rules are translated for the rule context identifier . Specifically, applying Definition 3.2 to translate for , gives: , where is the goal translation of and is the translation of the embedding implication .
Because is a user-defined predicate, Definition 3.2 makes . On the other hand, since , on recursively applying Definition 3.2, the translation of for the rule context identifier (where is a fresh variable denoting an unknown index which will be resolved at run-time) is . The translation of for rule context identifier is simply , where is a fresh variable. Finally, the translation of is:
where the call to has been omitted because, as previously mentioned, it always succeeds.
It is easy to determine that the translation of is and the translation of is .
Our implementation produces the following translated Prolog program for the source program :
p(A,[],B) :- g(A,_,B), ((q(A,[C|B],D):-chk([C|B],D)) => r(_,[C|B])). g(1,[],_). r([],A) :- q(2,_,A).
Despite the two solutions above for solving the embedded implication by means of a meta-interpreter and program translation, our goal is to add this kind of implication to BousiProlog, which requires complex rule transformations.
This raises two problems: First, in contrast to the solution in Definition 3.2, a more involved translation is required before asserting hypotheses. This first issue suggests avoiding program compilations at run-time by translating hypotheses at compile-time, but this leads to the second problem: When asserting a rule, all variables become universally quantified by default, but this is no longer true in the context of an embedded implication. Thus, it will be necessary to take account of substitutions in assumptions. Taking the logic system shown in Section 2.3 as a starting point, the following sections will cover these two issues.
3.2 Hypothesis precompilation
One possible approach to addressing the first problem is to translate and assert clauses at compile-time, so that a program does not need any translation at run-time. Although this involves all hypotheses in the program being translated and asserted, it is highly likely that the memory thus speculatively used will return a pay-off in terms of run-time gains.
Since it is not known how many times a given embedded implication will be selected for solving, some sort of registration is needed at run-time. First, the hypothesis can be translated and asserted at run-time and, whenever the embedded implication is selected for solving at run-time, the corresponding hypothesis is registered for the current context. Each registration will correspond to one alternative of the hypothesis and can be represented by an entry in a new dynamic predicate /2: one argument for the rule reference and another for the context in which it was registered.
Therefore, registering a rule for a new context needs a univocal reference to the rule. A new argument must thus be added to any predicate containing its reference, which can be achieved with a predicate similar to (Definition 2.5). Definition 2.4 must be modified to add this argument to head clauses and to translate the embedded implication with the reference to the translated hypothesis. In addition to the call to the /2 predicate, each body rule must include a call to /2 to retrieve, by backtracking, as many alternatives of the hypothesis as were registered in the course of the solving process.
In turn, solving the embedded implication needs to perform this registration of the hypothesis for the current context augmented with this hypothesis. Then, the embedded implication is added, with two new arguments: the new element in the context identifier sequence and the current context , meaning it is no longer a binary operator:
The following examples informally illustrate the proposed translation (which will be formalised in Definition 3.5) and the behaviour of the translated program. From here on, context identifiers will be represented as reversed lists of unique indexes.
Example 4
The program {} in Section 2 would be translated as:
.
In contrast to the method proposed in Section 2.3, the hypothesis of the embedded implication is compiled into a new rule. Three new arguments are added to the head of the rules: a unique rule index, the rule context identifier, and the current context identifier in which the rule will be used at run-time.
Solving the rule defining will call the operator , which will generate a unique identifier and will register the rule defining (the hypothesis) for the current context before submitting the goal .
Solving by SLD resolution requires the program to be added as a third argument to the state tuple in the transition relation , since it can be augmented by /1.
Example 5
For the program {}, the goal succeeds with two solutions. If the first (resp. second) context receives the identifier 0 (resp. 1), the program is translated as:
where the facts: and are added while solving the embedded implications. Thus, the consequent can be solved twice at context because both hypotheses match the goal at their respective contexts and .
An advantage of this approach with respect to that given in Section 2.3 is that assumptions via recursion require only one translated rule in the memory, rather than needing as many translated rules as assumptions. The following program illustrates this:
There is only one translated rule for (the same as in the previous example) and as many entries in /2 as in the goal .
3.3 Handling substitutions in assumptions
An assertion with free variables is a problem in this approach because it is translated at compile-time and the actual substitution is not known before solving-time.
Compared to the approach in Section 2.3 (and extended to the predicate logic case in Definition 3.2), where each assumption is asserted at run-time, now an assumption is asserted at compile-time without any trace of its actual substitution, which can lead to losing bindings for the shared variables between the hypothesis and its rule. The following program illustrates this issue:
Example 6
Moreover, variable sharing is also a problem. Let us consider the following example:
Example 7
In the program the goal succeeds when it should not.
Substitutions must therefore be passed when solving an embedded implication by using its hypothesis: Each rule will contain an extra argument containing the list of shared variables. In addition, the list of shared variables will be added to the rule registration in the context of the embedded implication so that, at solving-time, the translated implication can map the current substitution to these variables. Finally, each rule body in the translation will include a call to the predicate extended with an argument containing these shared variables, making it possible to transmit variable bindings at run-time. This is formalised in the next subsection.
3.4 Putting it all together
Satisfying the requirements set out above, we define rule registration as follows:
Definition 3.3 (Rule registration)
Rule registration is defined as: .
Then, the implementation of embedded implication solving, as introduced for the propositional case in Definition 2.5, is adapted as follows:
Definition 3.4 (Solving implication clause)
The solving implication clause for SLD resolution is defined as:
.
Considering what must be added to the translation (precompiling with registering, and variable sharing), rule and goal translation are defined as follows:
Definition 3.5 (Rule and goal translation)
Given a program , the rule translation of in , for the rule context identifier and an empty list of variables, is the set of rules consisting of the rule:
-
•
where is a fresh rule identifier, a variable that will be bound to a current context identifier, and is the goal translation of the possibly conjunctive goal .
-
•
and each rule resulting from each embedded implication in (as defined below).
The goal translation of a goal, , for a current context identifier , is either:
-
•
if is a built-in call; or
-
•
if is a user predicate call, where , and are new free variables representing any list of shared variables, any index and any context within the scope of the current context respectively; or
-
•
if is a conjunctive goal call, where and are respectively the goal translation of and ; or
-
•
if is an embedded implication (i.e, is a rule and is an atom or an embedded implication), where is a fresh rule identifier, is a list of shared variables between the assumptions in and the rest of the rule , is a new free variable representing any index, is the current context identifier:
-
–
is the goal translation of for a current context identifier , and
-
–
is the rule translation of , for the rule context identifier , a current context identifier , and a list of shared variables , between the assumptions in and the rest of the rule :
where is a fresh rule identifier, /3 is the predicate that stores each rule registration identified by for its current context identifier (cf. Definition 3.4), checks whether , and is the goal translation of . As mentioned above, is added to the translated program.
-
–
Example 8
Consider once again the program in Example 3. Following Definition 3.5, the translation of the rule , for the rule context identifier and no shared variables, is
because is the translation of the goal for a current context identifier and is the goal translation of for , where rule identifier has been set to the fresh value , the list of variables shared between the assumptions in and the rest of the rule is , and is the goal translation of for the current context identifier .
Finally, rule , of the single embedded implication, is translated for the rule context identifier , and is added as a new rule (identified by ):
From Definition 3.5, it is easy to obtain the translation of the remaining rules.
Our actual implementation produces the following translated Prolog program for the source program :
p(A,[],1,[],B) :- g(A, _, _, _, B), (=>(0,[A], r(_, _, _, [C|B]),C, B)). g(1,[],2,[],_). r([],3,[],A) :- q(2, _, _, _, A). q(A,[A],0,[_|_],C) :- reg(0, [A], B), chk(B, C).
It is noteworthy that the last translation fixes the problem mentioned in Example 6.
Considering as the transition relation for SLD resolution of a program , where the space state is a set of tuples (goal, substitution, program), the following can be stated:
Proposition 3.6
For a program and a goal , there exists iff , where , is the translation of each rule in , is the goal translation of , and is augmented with all the /3 assertions from embedded implication solving.
Appendix A contains a performance analysis and Appendix B the proof of this proposition.
4 Applying hypothetical reasoning to BousiProlog
BousiProlog [Rubio-Manzano and Julián-Iranzo (2014), Julián-Iranzo and Rubio-Manzano (2017)] is an extension of Prolog and similarity-based logic programming [Fontana and Formato (1999), Fontana and Formato (2002), Loia et al. (2001), Sessa (2002)]. We have also developed FuzzyDES [Julián-Iranzo and Sáenz-Pérez (2017), Julián-Iranzo and Sáenz-Pérez (2018)] as an extension of a Datalog-based deductive database, embedding notions inherited from BPL. We then proposed an extension of FuzzyDES to include hypothetical reasoning [Julián-Iranzo and Sáenz-Pérez (2020)], which includes an operational semantics that can be adapted to the hypothetical extension of BPL (HBPL for short), as shown below.
4.1 Formal background
It is first convenient to review some concepts before extending BPL to include hypothetical reasoning.
BPL, among other features, incorporates a unification algorithm based on proximity relations. A proximity relation is a binary fuzzy relation on a universe satisfying, for any , the reflexive () and symmetric ()) properties. If in addition it has the -transitive property (), where the operator is an arbitrary t-norm, it is called a similarity relation. A proximity relation allows two symbols in a program to be weakly related. Given a binary fuzzy relation and a value , the -cut . By abuse of language, the value is also called -cut (or cut value), which can be understood as a user-defined threshold intended to prune answers for a minimum degree of confidence.
A weak unification of terms builds upon the notion of weak unifier of level for two expressions and with respect to (or -unifier): a substitution such that , which is the unification degree of and with respect to and . There are several weak unification algorithms [Julián-Iranzo and Sáenz-Pérez (2021)] based on this notion and on the proximity-based unification relation , which defines a transition system (based on [Martelli and Montanari (1982)]). This relation, applied to a set of unification problems can yield either a successful or a failed sequence of transition steps. In the first case, both a successful substitution and a unification degree are obtained (detailed in, e.g., [Julián-Iranzo and Sáenz-Pérez (2021)]). The weak most general unifier (wmgu) between two expressions, denoted by , is defined as a -unifier of and such that there is no other -unifier which is more general than . That is, there exists a substitution such that, for any variable in , . Although, unlike in the classical case, the wmgu is not unique, the weak unification algorithm computes a representative wmgu with approximation degree greater than or equal to any other wmgu.
4.2 Adapting WSLD resolution for hypothetical reasoning
To combine WSLD and hypothetical reasoning, it is necessary to augment the notion of computation state by adding to it the context of the computation (i.e., the current program).
Let be a set of tuples (goal, program, substitution, approximation degree), each representing a state of a computation. Let be the transition relation as defined below in Definition 4.1. A successful inference sequence for a given state is a sequence ending in the state for some substitution and approximation degree , where represents an empty clause.
Definition 4.1 (HWSLD resolution)
Hypothetical Weak SLD (HWSLD) resolution is defined as a transition system ,
whose transition relation
is the smallest relation satisfying:
Rule 1:
if ,
,
, is as defined in ,
and :
Rule 2:
if
is a successful inference sequence:
,
where is an atomic formula, and are conjunctions of atomic formulas, , and
indicates that is a standardised apart rule.
4.3 Expanded rules: translating hypothetical programs
A fuzzy logic program is translated into a logic program by linearising heads, making the weak unification explicit, and explicitly computing the approximation degree. Essentially, given a graded rule , for each with , the following clause is generated:
where is the weak unification operator, are terms, are variables, is the grade of the rule (which may represent the user confidence level in the rule), and abbreviates the goal . Note that, by reflexivity, is always in .
An operational semantics can be defined for expanded programs by means of a transition system with a set of states (goal, program, substitution, degree), adding a new inference rule to the tackling of assumptions:
Definition 4.2 (Operational semantics for expanded programs)
The
operational semantics for expanded programs
is a transition system
and whose transition relation
is the smallest relation satisfying:
Rule 1: if , and :
Rule 2: if , , is as defined in ,
and :
Rule 3: if :
Rule 4:
if ,
with , is a successful inference sequence:
In this system, transition steps are applied to underlined fragments.
Proposition 4.3
Given a program , with a proximity relation , and its expanded program , there exists a derivation iff there exists a derivation which computes the same state.
The proof of this proposition follows a similar structure to the one for Proposition 3.6.
4.4 Implementing the expansion of programs
The generic implementation of expanded rules, including embedded implications, is done by applying the approach presented in Section 3.4 to the translation of expanded rules in BousiProlog. Thus, instead of working with a program , the following definition refers to program contexts with identifiers and lists of shared variables .
Definition 4.4 (Translation of expanded rules and goals)
Let be a BPL program, a proximity relation on the syntactic domain generated by , the fixed t-norm associated with , and a cut value. Let be a graded rule in . The rule translation of for a rule context identifier , a current context identifier and an empty list of shared variables is a set of expanded rules consisting of:
-
•
for each , generate the rule:
-
•
and each rule with rule context identifier resulting from each embedded implication in (as defined next),
where is a fresh rule identifier, checks whether (i.e., whether the rule can be applied because is over the -cut), /1 computes the unification degrees of the pairs formed by the arguments passed to the variables and the terms , /2 compounds the intermediate degrees to obtain the final degree , and is the goal translation of for a current context identifier .
The goal translation of for is either:
-
•
for a built-in call; or
-
•
for a user-predicate call , where , , and are respectively new free variables representing any list of shared variables, any index, and any context within the scope of , and is an approximation degree; or
-
•
for an embedded implication , where is a fresh rule identifier, is a list of shared variables between the assumptions in and the rest of the rule , is a new free variable representing any index, and is the current context identifier:
-
–
is the goal translation of , with degree , for the current context identifier .
-
–
Also the rule translation of for the rule context identifier , a current context identifier and the list of shared variables, is generated:
Let , then the translation of is a set of expanded rules such that for each , the rule H’ is generated as:
where /3 is the predicate that stores each rule registration identified by for its current context identifier (cf. Definition 3.3), checks whether , and is the goal translation of for a current context identifier .
-
–
Example 9
Given the BousiProlog program , a proximity relation , with an entry , and , following Definition 4.4, the translation of for the rule context identifier and no shared variables, generates the following set of rules:
-
•
For the entry ,
because is the translation of the goal for a current context identifier and is the goal translation of for , where rule identifier has been selected to the fresh value , the list of shared variables between the assumptions in and the rest of the rule is , and is the goal translation of for the current context identifier .
-
•
For the entry , in a similar way,
-
•
Finally, the rule of the single embedded implication is translated for the rule context identifier and is added as a new rule (identified by ):
From Definition 4.4, it is easy to obtain the translation of the remaining rules:
-
•
For and the single case in which ,
-
•
For and the case ,
For this generic definition, several optimisations are amenable, such as tail-recursion preservation, and deep indexing by linearising only the required head arguments.
5 Conclusions and Future Work
This paper has explored the inclusion of hypothetical reasoning in the fuzzy logic language and system BousiProlog. We have proposed an operational semantics for hypothetical fuzzy logic programs, and an efficient implementation skeleton, which has been assessed in terms of a performance analysis (cf. Appendix A) of the proposed technique based on program contexts and precompilation of assumptions. This analysis confirms the performance benefits in most cases, but it depends on the host Prolog system: indeed, SICStus Prolog performs better and typically makes the compiled approach behave better than the meta-interpreted one. In addition, soundness and completeness of the translation are backed by formal results.
However, incorporation of the approach presented in this paper into the actual system BPL remains to be done, and thanks to the performance analysis presented in the appendix, we are confident that the final implementation will benefit from such an approach. Another extension would be to embody negative assumptions, for which an appropriate declarative semantics must be developed before thinking about an operational one. One may also think of inheriting both positive and negative assumptions of proximity equations, but this is a much more delicate matter performance-wise, because changing relation changes the compilation of the program. An incremental compilation could perhaps be devised, which would seem to be an appropriate way of tackling this question.
References
- Bench-Capon and Prakken (2010) Bench-Capon, T. J. M. and Prakken, H. 2010. Using argument schemes for hypothetical reasoning in law. Artif. Intell. Law 18, 2, 153–174.
- Bonner (1988) Bonner, A. J. 1988. A logic for hypothetical reasoning. In Proceedings of the 7th National Conference on Artificial Intelligence, St. Paul, MN, USA, August 21-26, 1988. AAAI Press / The MIT Press, 480–484.
- Bonner (1990) Bonner, A. J. 1990. Hypothetical datalog: Complexity and expressibility. Theor. Comput. Sci. 76, 1, 3–51.
- Bonner (1994) Bonner, A. J. 1994. Hypothetical reasoning with intuitionistic logic. Non-Standard Queries and Answers, Studies on Logic and Computation, 187–219.
- Bonner (1997) Bonner, A. J. 1997. A logical semantics for hypothetical rulebases with deletion. J. Log. Program. 32, 2, 119–170.
- Bosse and Gerritsen (2009) Bosse, T. and Gerritsen, C. 2009. A model for criminal decision making based on hypothetical reasoning about the future. In IEA/AIE 2009, Taiwan, June 24-27. LNCS, vol. 5579. Springer, 24–35.
- Bourdeau (2014) Bourdeau, M. 2014. La théorie positive des hypothéses (in french). In In Proc of the Conf. on Hypothetical Reasoning. University of Tübingen, 23–29.
- Bourdeau (2020) Bourdeau, M. 2020. Auguste Comte. In The Stanford Encyclopedia of Philosophy, E. N. Zalta, Ed. Metaphysics Research Lab, Stanford University.
- Calantone et al. (2017) Calantone, R., Whipple, J. M., Wang, J. F., Sardashti, H., and Miller, J. W. 2017. A primer on moderated mediation analysis: Exploring logistics involvement in new product development. Journal of Business Logistics 38, 3, 151–169.
- Cuijpers (2013) Cuijpers, P. J. L. 2013. Prefix orders as a general model of dynamics. In 9th International Workshop on Developments in Computational Models (DCM 2013). Universidad de Buenos Aires, 25–29.
- Douven (2021) Douven, I. 2021. Abduction. In The Stanford Encyclopedia of Philosophy, E. N. Zalta, Ed. Metaphysics Research Lab, Stanford University.
- Fontana and Formato (1999) Fontana, F. A. and Formato, F. 1999. Likelog: A logic programming language for flexible data retrieval. In Proceedings of the 1999 ACM Symposium on Applied Computing (SAC’99). 260–267.
- Fontana and Formato (2002) Fontana, F. A. and Formato, F. 2002. A similarity-based resolution rule. Int. J. Intell. Syst. 17, 9, 853–872.
- Gabbay (1985) Gabbay, D. M. 1985. N-PROLOG: An extension of PROLOG with hypothetical implication II - logical foundations, and negation as failure. J. Log. Program. 2, 4, 251–283.
- Gabbay and Reyle (1984) Gabbay, D. M. and Reyle, U. 1984. N-PROLOG: An extension of PROLOG with hypothetical implications I. J. Log. Program. 1, 4, 319–355.
- Galindo (2005) Galindo, J. 2005. New characteristics in FSQL, a fuzzy SQL for fuzzy databases. WSEAS Transactions on Information Science and Applications 2, 2, 161–169.
- Julián-Iranzo and Rubio-Manzano (2017) Julián-Iranzo, P. and Rubio-Manzano, C. 2017. A sound and complete semantics for a similarity-based logic programming language. Fuzzy Sets and Systems, 1–26.
- Julián-Iranzo and Sáenz-Pérez (2017) Julián-Iranzo, P. and Sáenz-Pérez, F. 2017. FuzzyDES or how DES met BousiProlog. In International Conference on Fuzzy Systems (FUZZ-IEEE), Naples, Italy, July 9-12. 1–6.
- Julián-Iranzo and Sáenz-Pérez (2018) Julián-Iranzo, P. and Sáenz-Pérez, F. 2018. A Fuzzy Datalog Deductive Database System. IEEE Transactions on Fuzzy Systems 26, 5, 2634–2648.
- Julián-Iranzo and Sáenz-Pérez (2020) Julián-Iranzo, P. and Sáenz-Pérez, F. 2020. A System implementing Fuzzy Hypothetical Datalog. In International Conference on Fuzzy Systems (FUZZ-IEEE), UK, July 19-24. 1–8.
- Julián-Iranzo and Sáenz-Pérez (2021) Julián-Iranzo, P. and Sáenz-Pérez, F. 2021. Proximity-based Unification: an Efficient Implementation Method. IEEE Transactions on Fuzzy Systems 29, 5, 1238–1251.
- Kunhimangalam et al. (2013) Kunhimangalam, R., Ovallath, S., and Joseph, P. K. 2013. A novel fuzzy expert system for the identification of severity of carpal tunnel syndrome. BioMed Research International 2013.
- Loia et al. (2001) Loia, V., Senatore, S., and Sessa, M. I. 2001. Similarity-based SLD resolution and its implementation in an extended Prolog system. In International Conference on Fuzzy Systems (FUZZ-IEEE). 650–653.
- Lopez and Pimentel (1999) Lopez, P. and Pimentel, E. 1999. Hypothetical reasoning with substructural logics. In Proc. of Joint Conference on Declarative Programming. L’Aquila (Italia). 485–496.
- Martelli and Montanari (1982) Martelli, A. and Montanari, U. 1982. An Efficient Unification Algorithm. ACM Transactions on Programming Languages and Systems 4, 258–282.
- McCarty (1988a) McCarty, L. T. 1988a. Clausal intuitionistic logic I - fixed-point semantics. J. Log. Program. 5, 1, 1–31.
- McCarty (1988b) McCarty, L. T. 1988b. Clausal intuitionistic logic II - tableau proof procedures. J. Log. Program. 5, 2, 93–132.
- Miller et al. (1991) Miller, D., Nadathur, G., Pfenning, F., and Scedrov, A. 1991. Uniform proofs as a foundation for logic programming. Ann. Pure Appl. Log. 51, 1-2, 125–157.
- Minutolo et al. (2016) Minutolo, A., Esposito, M., and Pietro, G. D. 2016. A hypothetical reasoning system for mobile health and wellness applications. In MobiHealth 2016. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, vol. 192. Springer, 278–286.
- Moreno and Vázquez (2014) Moreno, G. and Vázquez, A. 2014. A survey on community detection methods in social networks. Journal of Software Engineering and Applications 7, 273–298.
- Rizzi (2009) Rizzi, S. 2009. What-If Analysis. Springer US, Boston, MA, 3525–3529.
- Rubio-Manzano and Julián-Iranzo (2014) Rubio-Manzano, C. and Julián-Iranzo, P. 2014. Fuzzy Linguistic Prolog and its Applications. Journal of Intelligent and Fuzzy Systems 26, 1503–1516.
- Sessa (2002) Sessa, M. I. 2002. Approximate reasoning by similarity-based SLD resolution. Theoretical Computer Science 275, 1-2, 389–426.
- Wielemaker et al. (2012) Wielemaker, J., Schrijvers, T., Triska, M., and Lager, T. 2012. SWI-Prolog. Theory and Practice of Logic Programming 12, 1-2, 67–96.
- Wilson and Nuzzolo (2008) Wilson, N. H. M. and Nuzzolo, A. 2008. Schedule-Based Modeling of Transportation Networks: Theory and applications Portada.
Appendix A Performance comparison: meta-interpreted vs. interpreted
This section analyses the performance of the different solving alternatives explained above: the meta-interpreter and the compiler-based solver interpreter. They are also compared, when applicable, to the native implementation and the solving in SWI-Prolog of the program under test. Two alternatives are first described for the meta-interpreter, and then the performance analysis is given, comparing them to the compiled approach in Section 3. The Prolog interpreter for non-hypothetical programs is also included in the comparison as a reference for the overhead caused by the compiled approach.
A.1 Hypothetical Meta-interpreters
Figure 1 illustrates the hypothetical propositional meta-interpreter, which has been enlarged to deal with disjunctive rules and built-in calls, where a fact is a rule with a body. The predicate /1 checks whether its argument represents a call to a built-in predicate (different from , and ).
The meta-interpreter for hypothetical propositional logic programs depicted in Figure 1 is not applicable to predicate logic programs. For example, the goal for the program {} should succeed, but it does not because solving creates the substitution {}, which is not compatible with the second call . Nonetheless, it can be easily adapted to the non-propositional case by modifying the last clause to:
However, copying the entire program each time the unification of a rule or fact with the goal is sought, is hugely resource consuming. A more convenient approach is to look for a matching clause and copy only this clause, as follows:
where stands for: is a member of that is unifiable with .
This can be slightly enhanced by using an ordered list for the program predicates (though preserving rule user ordering in each predicate), therefore reducing the serial access time complexity by a factor of 2, on average. Also, adding cuts for selecting the appropriate meta-interpreter clause will prune choice points in advance, and will also save some tests. Thus, an actual implementation in Prolog could be:
solve((Goal1, Goal2), Program) :- !, solve(Goal1, Program), solve(Goal2, Program). solve((Goal1; Goal2), Program) :- !, (solve(Goal1, Program) ; solve(Goal2, Program)). solve((Hyp => Goal), Program) :- !, insert_rule(Hyp, Program, NProgram), solve(Goal, NProgram). solve(Goal, _Program) :- builtin(Goal), !, Goal. solve(Goal, Program) :- unif_member((Goal :- _Body), Program, (UGoal :- UBody)), copy_term((UGoal :- UBody), (CGoal :- CBody)), CGoal=Goal, solve(CBody, Program).
Note that, in particular, the last clause will not be selected uselessly, as opposed to the skeleton shown in Figure 1. The predicate insert_rule/3 inserts a rule in the place corresponding to its ordering.
As suggested by an anonymous referee, there are more alternatives that may be considered. In particular, this meta-interpreter can be further enhanced by passing only assumed rules to solve/2, instead of the whole program. Then, the static user program can be accessed by the built-in predicate clause/2. Moreover, the assumed rules can be better represented by a tree, whose nodes are predicates (key of the tree), with their rules in a list, thereby improving access when many predicates are assumed. To implement this approach, the last clause of the former meta-interpreter is replaced by:
% Lookup in the consulted (static) program: solve(Goal, Program) :- clause(Goal, Body), solve(Body, Program). % Lookup in the augmented program: solve(Goal, Program) :- functor(Goal, Functor, Arity), atomic_concat(Functor, Arity, Key), get_assoc(Key, Program, Rules), unif_member((Goal :- _Body), Rules, (UGoal :- UBody)), copy_term((UGoal :- UBody), (CGoal :- CBody)), CGoal=Goal, solve(CBody, Program).
Association lists are implemented with AVL trees, with worst-case (and expected) time operations, where denotes the number of elements in the association list [Wielemaker et al. (2012)]. This meta-interpreter uses get_assoc/3 in solve/2 to retrieve nodes in the tree and put_assoc/4 in insert_rule/3 (cf. its implementation in meta2.pl at the URL mentioned in the next subsection).
A.2 Performance Analysis
All experiments were run on an Intel Xeon CPU E3-1505M v5 with 4 physical cores at 2.8 GHz, 16GiB RAM, with the Windows 10 64-bit operating system. Benchmarks are run on the last stable version of SWI-Prolog 64-bit 8.2.4-1 at the time of writing this. Times in the Tables are given in seconds and are the result of averaging 10 runs (and discarding the first), and individual times were measured with the built-in predicate statistics/2. We have collected the time for the total run-time measurement (key cputime for SWI-Prolog), which returns the (user) CPU time, and the run-time (key runtime) which returns the total run-time, eliding the time for memory management (garbage collection) and system calls. Tables include the column CPUtime (for the total run-time), and Diftime (for the total run-time minus the run-time, primarily to reflect the cost of garbage collection). Garbage collection and stack trimming are carried out before each trial is run; then the time measurement can start. On completion of the trial, these operations are performed again before taking the elapsed time, in order to account for housekeeping tasks due to running the tests. Also, inferences is another measurement from the statistics predicate, which indicates the number of passes via the call and redo ports in order to execute a goal. All benchmarks and systems can be downloaded from http://www.fdi.ucm.es/profesor/fernan/iclp2021/Experiments.zip.
Several classical benchmark programs have been selected (they can be found at the SWI-Prolog site), where some have been adapted to remove cuts. These programs are intended, firstly, to make clear the price to be paid for including hypothetical reasoning in the system; and, secondly, to compare meta-interpreted alternatives with respect to the compiled alternative. In any case, it should be recalled that a compiled approach is preferred for the implementation of a system such as BPL, because assuming a rule implies a recompilation. Furthermore, most of those programs have been adapted to build hypothetical versions by assuming either facts or a rule for the data generator. These versions add a preceding h before the classical test name. With respect to the factorial test program, facttr is the tail recursive version, and all benchmark sizes can be consulted at the URL above. As a stress test, several parametric hypothetical programs are included, to test embedded implications: The first (labelled as hypo1 in the following Tables): {} with a goal for ; the second (hypo2): {} with a goal and requesting all solutions; and the third (hypo3): {} with a goal for assumptions, also requesting all solutions. The first program is intended to test the system by assuming a large batch of different predicates iteratively. The second recursively assumes facts of the same predicate and is intended to analyse the performance in the presence of backtracking by requesting all solutions. The third is similar to the second but iteratively adding those facts with nested assumptions.
Table A 1 collects the running measurements for classical tests and Table A 2 for hypothetical tests. Rows in the Table include the following labels: Meta1 for the first meta-interpreter as shown in this appendix, Meta2 for the second, improved, instance, Comp for the compiled approach as described in Definition 3.5, and Prolog for the native execution of (classical, non-hypothetical) tests in the Prolog system.
For classical tests (Table A 1) Meta2 performs better than Meta1 with significant speed-ups, and there is even a notable speed-up in the case of path, where recursively traversing the list of the program, including many arcs in the graph, takes a lot of effort that is avoided with Meta2, because the program is consulted. Looking now at the compiled alternatives Comp and Prolog, they perform better than the meta-interpreted versions. Comparing Comp to Prolog, they behave similarly in most cases other than in nrev and queens, where Prolog is faster (4.62 and 1.44, respectively).
For hypothetical versions of classical tests (Table A 2, roughly similar conclusions can be drawn. Performance of Comp is almost always better than Meta2, and the latter is better than Meta1. Only in hpath is Meta2 faster by a small amount. Results can be different for other non-classical stress tests such as hypo1, for which Meta2 performs better. In this case, note that AVL trees play an important role in fast accessing of each rule (in hypo1 there is one assumed rule for each predicate, with a total of 2000). In turn, Comp takes more time, both in total time and memory management, even when the number of inferences is roughly a fifth compared to Meta1, but the time taken by memory management is noticeable compared to the other two alternatives. This system Comp performs better for hypo2 with a similar inference ratio with respect to Meta2. With respect to the last test hypo3, Meta2 is the slowest, while there is a small difference between Comp and the fastest, Meta1.
ata_switest_data_swi_classic.tex
Program | System | CPUtime | Diftime | Inferences |
---|---|---|---|---|
_data_swi |
ata_switest_data_swi_hypo.tex
Program | System | CPUtime | Diftime | Inferences |
---|---|---|---|---|
_data_swi |
Appendix B Proof for Proposition 3.6
We divide the proof of Proposition 3.6 into two parts, starting with the proof of the statement “if there exists a derivation then there exists a derivation ”. This direction constitutes a kind of completeness result where we prove that derivations in the original program using the HSLD resolution rule can be reproduced by the SLD operational mechanism in the transformed program. In the second part, we prove the converse of the first statement, that is “there exists a derivation if there exists a derivation ”, which guarantees that the present implementation does not compute answers which are not computed by the HSLD semantics, leading to a sort of soundness result.
B.1 Proof of Part I
Lemma B.1
Let be a program and a goal, if there exists the step ≡⟨(←A∧Q_1), θ, Π ⟩ ⇒_HSLD ⟨(←Q_2σ), θσ, Π ⟩ then there exists the following derivation in the translated program : ⟨(←A’∧Q’_1), θ, Π’ ⟩ ⇒_SLD + ⟨(←Q’_2(σ∪δ)),θσ∪δ,Π’∪Π_reg ⟩, where , are the goal translations of , respectively, and is the set of all the /3 assertions due to embedded implication solving. The domain of the substitution shares variables with neither nor , and .
Proof B.1.
We proceed by induction on the context identifier associated with the program context.
-
1.
Base case(): In this case query must be an atom, that is, and there must be a rule for which (where , with , are unification problems) and step is (⟨←p(¯s_n)∧Q_1, θ, Π ⟩ ⇒_HSLD ⟨←(B∧Q_1)σ, θσ, Π ⟩)
According to Definition 3.5, the rule translation of is and the goal translation of is where , , , and are fresh variables. It is then easy to verify that:
where , and its domain does not share variables with . Hence, the following step is possible in the translated program : ⟨←p(¯s_n, L, I, C, ϵ)∧Q’_1, θ, Π’ ⟩ ⇒_SLD ⟨←(B’∧Q’_1)(σ∪δ), θ(σ∪δ), Π’ ⟩ and .
-
2.
Inductive case (): The query , that is, an embedded implication (chain), and the step ≡⟨(←(H ⇒G)∧Q_1), θ, Π ⟩ ⇒_HSLD ⟨(←Q_1σ), θσ, Π ⟩ Therefore, Rule 2 of Definition 3.1 was applied and the derivation D_1≡(⟨(←G), id, Π_1 ⟩ ⇒_HSLD * ⟨□, σ,Π_1 ⟩) must exist, where is a new program with context identifier . Then, by the Inductive hypothesis, the following derivation in the translated program : D’_1≡(⟨(←G’), id, Π’ ⟩ ⇒_SLD * ⟨□, σ∪δ,Π’∪Π_reg ⟩) must exist, where is the goal translation of , is the set of rule registrations and is a substitution for which its domain shares variables with neither the original (not translated) goal nor the substitution .
On the other hand, note that the translation of the goal is plus the rule translation of .
Now, using Definition 3.4 for solving embedded implication clauses and Definition 3.3 of rule registration, and the derivation , it is possible to build the following derivation :
where the domain of shares variables with neither nor , and .
Proposition B.2.
For a program and a goal , if there exists a derivation then there exists a derivation , where is the translation of each rule in , is the goal translation of , is the set of rule registrations, that is, all the /3 assertions due to embedded implication solving, and .
Proof B.3.
By induction on the length of the derivation and Lemma B.1.
As mentioned above, Proposition B.2 constitutes a kind of completeness result. In the following we concentrate on the other direction, which leads to a sort of soundness result.
B.2 Proof of Part II
Proposition B.4.
Let be the translation of a program and the goal translation of a goal , if there exists a derivation , where is the set of rule registrations, that is, all the /3 assertions due to embedded implication solving, then there exists a derivation . The domains of the substitutions and share variables with neither nor , and .
Proof B.5.
The proof proceeds by induction on the length of the derivation . Without loss of generality, thanks to the independence of the computation rule in the SLD operational mechanism, several steps in the derivation can be conveniently ordered. So, it is possible to group fragments of the derivation in the translated program , which correspond with the steps in the derivation , in the program .
-
1.
Base case(): In this case the query (translation of , since an initially launched goal is solved in the initial context and its list of shared variables is empty) and there must be a rule , with rule index (translation of the fact ), for which
where must be solvable, , and its domain shares variables with neither nor . Therefore, the following one-step derivation is possible in the program : .
-
2.
Inductive case (): In the analysis of the inductive case we consider two possibilities, depending on whether the first step is performed with a sub-goal, which is an instance of the atom , or not. This kind of sub-goal comes from embedded implications that appear in the body of some rule, or are submitted directly in the initial query proposed to the system.
-
(a)
First, consider that (translation of ) and the first step is performed with a rule , with index rule (translation of ),111 Note that in the translated program , we can find rules of the form coming from the translation of the embedded implications in the body of the rules in (see Definition 3.5). However, this type of rule does not contribute to the first step of a derivation. whose head unifies with the selected sub-goal:
where must be solvable, and its domain shares variables neither with nor with . Hence, derivation proceeds thus:
Now, because is solvable, there exists the step in : ⟨←p(¯s_n)∧Q_1, θ, Π ⟩⇒_HSLD ⟨←(B’∧Q’_1)σ_1, θσ_1, Π ⟩ on the other hand, by the inductive hypothesis, there exists a derivation in such that: ⟨←(B∧Q_1)σ_1, θσ_1, Π ⟩⇒_HSLD * ⟨□,θσ_1σ_2,Π ⟩ and the derivation in can be constructed.
-
(b)
In this case, the first step is performed on a solving implication clause, that is which is the translation of . For simplicity, we will assume that and the goal translation . Then the shape of the derivation is:
with two clear parts. The first part corresponds to the HSLD step performed on using Rule 2 of Definition 3.1. It groups the associated derivations submitted by the occurrence of embedded implications and their successive program contexts. Then there must exist the HSLD step in the program . As for the second part, by the inductive hypothesis, there must exist the HSLD derivation Combining both, the former step and the last derivation, we obtain the derivation .
-
(a)
Corollary B.6.
Let be the translation of a program and the goal translation of a goal , if there exists a derivation , where is the set of rule registrations, that is, all the /3 assertions due to embedded implication solving, then there exists a derivation , and .
Appendix C Related Work
The term ”hypothetical reasoning” appears in many important contexts in the philosophical and scientific literature. Auguste Comte, founder of Positivism, is one of the first thinkers to highlight the importance of hypotheses in science [Bourdeau (2020)]. Although Comte does not establish laws for hypothetical reasoning, he begins the path, influencing (according to Michel Bourdeau [Bourdeau (2014)]) other thinkers such as Peirce and its abductive reasoning. According to that American philosopher, human thought has three modes of reasoning: deductive, inductive and abductive. ”Abduction is the first step of scientific reasoning”, because, as he says, ”abduction is the process of forming explanatory hypotheses. It is the only logical operation that introduces a new idea” [Douven (2021)].
However, our work is centered in a more specific area with a long tradition in the field of Logic Programming, in which the purpose is prospective: to propose hypotheses in order to evaluate its consequences. Mainly, our work is influenced by those of Gabbay [Gabbay and Reyle (1984), Gabbay (1985)] and Bonner [Bonner (1988), Bonner (1990), Bonner (1994), Bonner (1997)] and, to a lesser extent, by those of L.T. McCarty [McCarty (1988a), McCarty (1988b)].
Gabbay first deals with hypothetical implications in logic programming. In [Gabbay and Reyle (1984)], they focused only on addition operations because deletion is problematic; thus they let it for another paper. Addition is essentially monotonic and deletion is not. We use a similar technique to the one followed by Gabbay for implementing hypothetical implications, by asserting the antecedent to the program database, trying to derive the consequent and finally retracting the antecedent. [Gabbay (1985)] investigates the logical properties of N-PROLOG and the way it relates to classical logic and the classical quantifiers. He also introduced negation as failure into N-PROLOG. He saw that success in the N-PROLOG computation of a goal from the database means logically that in intuitionistic logic. It is credited that was Gabbay the first one to realize the important connection between hypothetical reasoning and intuitionistic logic [Bonner (1994)].
In [McCarty (1988a)], he presents a clausal language that extends Horn-clause logic by adding negations and embedded implications (i.e., hypothetical implications –he was the one who first used this designation–) to the right-hand side of a rule, and interpreting these new rules intuitionistically in a set of partial models. Lately, in [McCarty (1988b)], he shown that clausal intuitionistic logic has a tableau proof procedure that generalizes Horn-clause refutation proofs and it is proved sound and complete.
As it has been said, Bonner has extensive experience in this field, starting from a language with embedded implications (close to ours) and exploring its applications and formal properties, including results on complexity [Bonner (1988), Bonner (1990), Bonner (1994)]. In his latest work on this topic [Bonner (1997)], he broke with his initial works and he developed a logic programming language with a dedicated syntax in which users can create hypotheses and draw inferences from them. He provides two specific operations with a modal-like notation: hypothetical insertion of facts into a database ( meaning that “Q would be true if A were added to the database”), that has a well-established logic (intuitionistic logic) and hypothetical deletion ( meaning that “Q would be true if A were deleted from the database”). In this paper, he develop a logical semantics for hypothetical insertions and deletions (including a proof theory, model theory, and fixpoint theory). He analyses the expressibility of the language and he shows that classical logic cannot express some simple hypothetical queries. However, we believe that the language introduced, with specific insertion and deletion operations, may have limitations compared to the one we have proposed in this work (e.g., only atoms can be inserted or deleted). Finally, he augmented the logic with negation-as-failure so that nonmonotonic queries can be expressed, a subject that we let as future work.
Finally, another piece of related work is -Prolog, which uses a syntax based on the so-called “hereditary Harrop formulas.” Thanks to this type of formulas, -Prolog subsumes a set of increasingly complex sublanguages, ranging from Horn clauses and higher-order Horn clauses to hereditary Harrop formulas. This type of formula, for example, allows rules with bodies that contain (hypothetical) implications whose hypotheses are in turn rules.
The use of higher-order Horn clauses and a non-deterministic goal-directed search-based operational semantics (which is complete with respect to an intuitionistic sequent calculus) [Miller et al. (1991)] allows -Prolog the ability to perform hypothetical reasoning. In practical and informal terms, the -Prolog operational mechanism performs operations similar to those performed by Comp to solve a hypothetical implication (): Assert to the rules of the program (creating a new context) and launch the goal ; if is successful, then () is also successful. It is nothing other than the rule ”AUGMENT” ( only if .), one of the operational rules that models the computation-as-goal-directed-search of -Prolog.
Therefore, both mechanisms are comparable, except that -Prolog fits into a more general and ambitious framework, while Comp simply tries to extend the language of Horn clauses and the resolution principle with additional features, among which the hypothetical reasoning is found, as a platform for a fuzzy logic programming system.
What specific expressive capabilities for hypothetical reasoning -Prolog incorporates depends on the implementation. For example, we know in the words of D. Miller himself222stackoverflow.com/questions/65176668/?prolog-rejecting-hypothetical-reasoning-queries about Teyjus, an implementation of -Prolog, that ”Teyjus does not permit implications to be used in top-level goals. This is a characteristic that may change in the future when the compilation model is extended also to these goals but, for now, it means that some of the examples presented, eg, in Section 3.2, cannot be run directly using this system.” Instead, the future implementation of Comp is planned to be able to allow this by compiling the goal in the context of the loaded program before submitting it.
Moreover, -Prolog does not work with ”negative assumptions”, a matter that we have let marked as future work, and that we will undertake by following some ideas already proposed for the implementation of a Fuzzy Datalog system [Julian-Iranzo and Saenz-Perez, 2018].
Despite all the above and the possible relations between the foundations of our proposal and -Prolog, as we have just commented in this section, our work has its roots in the previous work carried out by Gabbay and Bonner. On the other hand, the main contribution of this article is the development of efficient high-level implementation techniques for implementing a fuzzy logic programming system (HBPL) with the possibility of hypothetical reasoning based on BPL [Rubio-Manzano and Julián-Iranzo (2014), Julián-Iranzo and Rubio-Manzano (2017)]. In such a system, assumptions imply compilations which with our proposal are possible to perform at compile-time.