Attributed Variables in Prolog

How it started.

When considering existing approaches of extensions to syntactic unification, we observe: highly specialized implementations, where the unification algorithm cannot be manipulated by the user (e.g. [Col87,JaLa87,vH89]), approaches too general to be implemented efficiently and too general to allow the reuse of existing Prolog programs [Ko84], or extensions allowing definitions in a procedural language [CLiST89] only. Our approach focuses on a sufficient abstract yet efficient interface, which permits to write implementations of constraints in Prolog , neglecting the actual representation of the constrained variables. Metastructures are applicable, but not restricted to the following areas: ...

How it continued

This package implements attributed variables. It provides a means of associating with variables arbitrary attributes , i.e. named properties that can be used as storage locations as well as to extend the default unification algorithm when such variables are unified with other terms or with each other. This facility was primarily designed as a clean interface between Prolog and constraint solvers, but has a number of other uses as well. The basic idea is due to Christian Holzbaur and he was actively involved in the final design. For background material, see the dissertation [Holzbaur 90].

What we have now

  • We can attach information to variables.
  • This information can be taken into account when a variable is being unified .
  • This information can be displayed in answers on the Prolog toplevel .

Attributed variables in Scryer Prolog

Preliminaries.

  • Predicates for adding, changing and removing attributes.
  • Predicates to reason about the unification of variables that have attributes attached.
  • Predicates that let you display attributes on the toplevel in some form.

Adding and changing attributes

Unification of attributed variables.

  • For each relevant module M , M:verify_attributes/3 is called, collecting a list of returned Goals .
  • The variable binding is redone.
  • Any Goals are called.
  • Any blocked goals are called.
  • Upon unification of two variables with attributes from module  attrmod , fetch their a/1  attributes.
  • Compute the sum of the integers in the attributes, using integer arithmetic.
  • Attach the sum as the new attribute.
  • If Var has an associated domain  Dom1 , and Other is a variable that has an associated domain Dom2 , then we build the intersection Dom = Dom1 ∩ Dom2 . This ordered list contains all elements that are admissible for both variables that have been unified.
  • We only proceed if Dom is different ( dif/2 ) from the empty list   [] , and hence there is at least one remaining domain element that is admissible for the resulting unified variable.
  • If Dom has only a single remaining element, then that element must be equal to the unified variable (because there is no other choice).
  • Otherwise, assign the intersection Dom as an attribute to the unified variable.
  • If Other has no associated domain, then the unification is only admissible if Other is a member of the domain  Dom1.

Displaying attributes

Pitfalls and errands.

4 Basic choice III: no pre_unify The most profound difference between attributed variables in SICStus Prolog and ECLiPSe is the state of the variable at the moment the unifcation handler is called. As an example: assume the attributed variable X has one attribute A (with module user ) and X is unifed with the integer 666. In SICStus Prolog, verify_attributes is called with X still being unbound . In ECLiPSe, the unify handler is called with A as an argument - X has been bound to 666 already . The SICStus Prolog behavior follows [6] which claims that it is important to have the variables as if not yet bound . ECLiPSe people on the other hand (Joachim Schimpf) claim that this is not needed . We do not want to take a stand in this issue: we had implemented at some point the full SICStus Prolog behavior (but on dynamic attributes of course) and were not convinced that the extra implementation complexity was worth the gain. However, we were not impressed by the manuals of SICStus Prolog and ECLiPSe, which claim that binding the X during a pre_unify yields unexpected results : in our opinion (and experience), it just shows that full support for pre_unify is too cumbersome to implement and maintain in a full system like SICStus Prolog or ECLiPSe. So we switched to the ECLiPSe model, but without the compromise to support pre_unify for compatibility reasons: Occam's razor is a blessing :-)

Occam's razor

Minato task.

  • X is a branching variable
  • Then and Else are nodes.
  • As a start, consider the following unification: X = 0 . You reply for example with: That's easy, I simply take a look at the decision diagram, which now is: ( 0 -> true ; ( Y -> true ; false ) ) Since the first branching variable is now instantiated, it is clear which branch we must take, so we can replace the whole diagram with: ( Y -> true ; false ) From there, further unifications are easy.
  • Here is a slightly harder case: X = 1 . This means that the ZDD could be reduced to: true But wait, that's not all! As we explained, a variable that does not appear in a path to true must be equal to  0 . In this case, Y is such a variable, so we must set it to  0 . But how? Well, one way to do this is to keep track of all variables that have so far appeared in constraints, and to represent the ZDD for example as a pair of terms, such as: ( X -> true ; ( Y -> true ; false ) )- [X,Y] This means that in the above case, we would end up with: true-[1,Y] and from there it is easy to state that Y = 0 .
  • Here is a third case: [X,Y] = [1,1] . And you solve the Minato task by telling us how your interface predicates can be used to determine that this unification is not admissible due to the constraints the variables are involved in. For comparison, the unification must succeed if the ZDD is for example: ZDD = ( X -> Inner ; Inner ), Inner = ( Y -> true ; false ) This illustrates that you cannot look into other branches of the ZDD to recover any information about  Y .
  • How naturally can an interface be used to solve such tasks?
  • How likely are mistakes by application programmers who use it?
  • How hard do we want to make our lives for the sake of negligible additional performance?

Solution with SICStus Prolog

  • a leaf is represented as b(true) or b(false)
  • an inner node is represented as ( Var -> Then ; Else ) , where Then and Else are nodes.

Equivalence task

If a variable  X , occurring in the expression, is subsequently unified with some term  T , this is treated as a shorthand for the constraint | ?- sat(X=:=T).

Further reading and future work

404 Not found

ScrumDesk, Meaningful Agile Logo

MoSCoW prioritization of the product backlog

Moscow backlog prioritization.

Prioritization is probably the most discussed part of development processes. Product backlogs are often quite complex with hundreds of requirements. How to find user stories in your story map which you should start developing first?

Traditional approach

The approach of traditional processes is simple. You have high, medium, low priorities. Ok, for some organizations it is still not enough so they have priorities on the scale of 0 to 10.

But do such priorities help deliver the most important and most valuable thing at the same time?

In agile, we want to support the pull principle. We want to let our developers pull the next requirement, develop it, deliver it. Then continue to the next one. So, in Agile we need a line of requirements.  Agile processes and frameworks focus on the delivery of valuable stuff first. This is fine; however, there is a necessity to consider other perspectives as well.  There are two kinds of companies.

scrumdesk agile scrum companies type prioritization planning plan product owner

If you want to prioritize and be agile, you can’t be just one of the types. You have to be company following both of them and even more .

scrumdesk scrum product backlog prioritization owner moscow must should could won't

Customers’ perspective

In ScrumDesk we prefer to consider the customer’s perspective first. The idea is that a satisfied customer is a driver of further changes and success of the product itself . A satisfied customer is willing to improve the product not just by social marketing, by new ideas, but in our case even by the development of the product itself.

As the product owner, the first thing you have to understand is who your customer/user is. You need to understand and describe her space, her context, her jobs, the pains or gains she is looking for.

The best part is just coming. Based on a more than 10 years old survey done by Scot Ambler, 45% of functionalities are NEVER, NOT ONCE, used. Only 7% are used always. Plus 13% very often.

So, why develop something that customers will not use? You just spent the life of your colleagues! Common! The answer is NO! Now MoSCoW prioritization comes to help.

scrumdesk product backlog prioritization moscow must should could won't

Based on that you should be able to decide if a feature is:

  • Must – a heart is a “must”. Without it, there is no live organism. What is a must in your application?
  • Should – a hand is “should”. Without it is hard. But you can survive even without a hand. Well, in most cases.
  • Could – hair is “could”. It is fine to have them, you even look nicer, but you will definitely survive without them
  • Won’t – unnecessary waste. Btw, is there anything “won’t” in a body?

How to estimate MoSCoW values in 7 steps?

  • As a Product Owner, try to be in the skin of your customer. There might be multiple types of them, so choose one, or some group of them.
  • If you were him, will the feature be a must, should, could, or won’t?
  • Forget about the time of development, forget about effort. It is just about customer and feature.
  • What if this feature was not a must, but should? Would the customer realize that?
  • What if the feature was could and not should? Would the customer realize that?
  • Try to make it less “must”. Remember 7% features used always.
  • Compare requirements to each other. Repeat a couple of times.

Let’s say your backlog looks like this:

scrumdesk scrum product backlog user story map prioritization owner agile

After MoSCoW prioritization you should have a line of requirements ordered by MUST, SHOULD, COULD values. This might be done in ScrumDesk PLAN view

scrumdesk scrum product backlog user story map prioritization owner agile release plan

How to manage MoSCoW in ScrumDesk ?

To set the value to backlog item you need just click it (in any view, either STORY MAP , BACKLOG , PLAN or WORK ) to access details in the side view. Prioritization fields are displayed below the title of the backlog item. The first one is MoSCoW.

scrumdesk scrum product backlog user story map prioritization owner agile moscow must should could won't

Value can be visible on cards in STORY MAP.

scrumdesk scrum product backlog user story map prioritization owner agile Moscow on story index card

Once the value is entered, you can filter and group items based on it all ScrumDesk  views, i.e. in the product backlog.

scrumdesk scrum product backlog user story map prioritization owner agile MoSCoW

However, you are not done with prioritization in this step. What about business value? More to follow…

< Print physical cards  | Content | Agile prioritization based on Business value >

web analytics

  • Attribute manipulation predicates
  • Attributed variable hooks
  • Operations on terms with attributed variables
  • Special purpose predicates for attributes
  • Coroutining

8.1 Attributed variables

Attributed variables provide a technique for extending the Prolog unification algorithm Holzbaur, 1992 by hooking the binding of attributed variables. There is no consensus in the Prolog community on the exact definition and interface to attributed variables. The SWI-Prolog interface is identical to the one realised by Bart Demoen for hProlog Demoen, 2002 . This interface is simple and available on all Prolog systems that can run the Leuven CHR system (see chapter 9 and the Leuven CHR page ).

Binding an attributed variable schedules a goal to be executed at the first possible opportunity. In the current implementation the hooks are executed immediately after a successful unification of the clause-head or successful completion of a foreign language (built-in) predicate. Each attribute is associated to a module, and the hook ( attr_unify_hook/2 ) is executed in this module. The example below realises a very simple and incomplete finite domain reasoner:

Before explaining the code we give some example queries:

?- domain(X, [a,b]), X = c fail ?- domain(X, [a,b]), domain(X, [a,c]). X = a ?- domain(X, [a,b,c]), domain(X, [a,c]). domain(X, [a, c])

The predicate domain/2 fetches (first clause) or assigns (second clause) the variable a domain , a set of values the variable can be unified with. In the second clause, domain/2 first associates the domain with a fresh variable (Y) and then unifies X to this variable to deal with the possibility that X already has a domain. The predicate attr_unify_hook/2 (see below) is a hook called after a variable with a domain is assigned a value. In the simple case where the variable is bound to a concrete value, we simply check whether this value is in the domain. Otherwise we take the intersection of the domains and either fail if the intersection is empty (first example), assign the value if there is only one value in the intersection (second example), or assign the intersection as the new domain of the variable (third example). The nonterminal attribute_goals//1 is used to translate remaining attributes to user-readable goals that, when called, reinstate these attributes or attributes that correspond to equivalent constraints.

Implementing constraint solvers ( chapter 8 ) is the most common, but not the only use case for attributed variables: If you implement algorithms that require efficient destructive modifications, then using attributed variables is often a more convenient and somewhat more declarative alternative for setarg/3 and related predicates whose sharing semantics are harder to understand. In particular, attributed variables make it easy to express graph networks and graph-oriented algorithms, since each variable can store pointers to further variables in its attributes. In such cases, the use of attributed variables should be confined within a module that exposes its functionality via more declarative interface predicates.

8.1.1 Attribute manipulation predicates

8.1.2 attributed variable hooks.

Attribute names are linked to modules. This means that certain operations on attributed variables cause hooks to be called in the module whose name matches the attribute name.

  • They use only predicates that are themselves exported and documented in the modules they stem from.

The latter property ensures that users can reason about residual goals, and see for themselves whether a constraint library behaves correctly. It is this property that makes it possible to thoroughly test constraint solvers by contrasting obtained residual goals with expected answers.

This nonterminal is used by copy_term/3 , on which the Prolog top level relies to ensure the basic invariant of pure Prolog programs: The answer is declaratively equivalent to the query.

The copy_term/3 primitive uses attribute_goals//1 inside a findall/3 call. This implies that attribute_goals//1 can unify variables and modify attributes, for example, to tell other hooks that some attribute has already been taken care of. This nonterminal is also used by frozen/2 which does not create a copy. Ideally attribute_goals//1 should not modify anything to allow direct application in frozen/2 . In the current implementation frozen/2 backtracks over attribute_goals//1 to tolerate the current behavior. This work-around harms the performance of frozen/2 . New implementations of attribute_goals//1 should avoid relying on backtracking when feasible. Future versions of frozen/2 and copy_term/3 may require attribute_goals//1 not to modify any variables or attributes.

Note that instead of defaulty representations, a Prolog list is used to represent residual goals. This simplifies processing and reasoning about residual goals throughout all programs that need this functionality.

8.1.3 Operations on terms with attributed variables

This building block is used by the top level to report pending attributes in a portable and understandable fashion. This predicate is the preferred way to reason about and communicate terms with constraints.

The form copy_term(Term, Term, Gs) can be used to reason about the constraints in which Term is involved.

8.1.4 Special purpose predicates for attributes

Normal user code should deal with put_attr/3 , get_attr/3 and del_attr/2 . The routines in this section fetch or set the entire attribute list of a variable. Use of these predicates is anticipated to be restricted to printing and other special purpose operations.

  • History of cooperation
  • Areas of cooperation
  • Procurement policy
  • Useful links
  • Becoming a supplier
  • Procurement
  • Rosatom newsletter

© 2008–2024Valtiollinen Rosatom-ydinvoimakonserni

swi prolog assign variable

  • Rosatom Global presence
  • Rosatom in region
  • For suppliers
  • Preventing corruption
  • Press centre

Rosatom Starts Life Tests of Third-Generation VVER-440 Nuclear Fuel

  • 16 June, 2020 / 13:00

This site uses cookies. By continuing your navigation, you accept the use of cookies. For more information, or to manage or to change the cookies parameters on your computer, read our Cookies Policy. Learn more

  • Sources/building
  • Docker images

External

  • Command line
  • Prolog syntax
  • HTML generation
  • Publications
  • Rev 7 Extensions
  • Getting started
  • Development tools
  • RDF namespaces
  • GUI options
  • Linux packages
  • Report a bug
  • Submit a patch
  • Submit an add-on
  • External links
  • Contributing
  • Code of Conduct
  • Contributors
  • SWI-Prolog items
  • View changes
  • Introduction
  • Initialising and Managing a Prolog Project
  • Built-in Predicates
  • SWI-Prolog extensions
  • Tabled execution (SLG resolution)
  • Constraint Logic Programming
  • CHR: Constraint Handling Rules
  • Multithreaded applications
  • Coroutining using Prolog engines
  • Foreign Language Interface
  • Using SWI-Prolog in your browser (WASM)
  • Deploying applications
  • Packs: community add-ons
  • The SWI-Prolog library
  • Hackers corner
  • Compatibility with other Prolog dialects
  • Glossary of Terms
  • SWI-Prolog License Conditions and Tools
  • Bibliography

D Glossary of Terms

Expressed as “X is a parent if X is a father of someone''. See also variable and predicate .

In Prolog, the expression a+b is exactly the same as the canonical term +(a,b) .

Unlike assignment (which does not exist in Prolog), unification is not directed.

See also unify .

  • doc-needs-help

Picture of user Andy Green.

Some corrections

"A Prolog variable is a value that‘is not yet bound'."

That sound not correct (it would explain why var/1 is called var/1 and not unbound/1 though, but is in contradiction with all other usage of the word 'variable', in particular with the usage under "binding of a variable").

Better: A "variable" is a name (with clause scope) denoting a term or an empty cell. If it designates an empty cell, it is an unbound or uninstantiated variable, otherwise it is a bound variable, namely a variable bound to the term it denotes. The "binding state" of a variable may change from unbound to bound. Trivially:

which should really have been written

OTOH, there is a slight shift in the meaning of the word "variable" when used for a variable name in the head (where it is always unbound as it appears in unification) and in a goal (where its "bounded-ness/instantiated-ness status" changes from "fresh & unbound" to "still unbound" to "bound/partially bond" to "bound/ground").

In all these case, X is a "variable", but the meaning changes.

It is actually clearer to say that X is a variable name and denotes en empty cell ("X is an unbound variable") or a (proper? nonempty?) term. (apparently an empty cell is also a "term")

Some possible additions

Some adapted from

  • "Deduction Systems", Rolf Socher-Ambrosius, Patricia Johann, Springer 1997
  • "Memoing for Logic Programs", David S. Warrne, CACM Marc 1992 (Vol.35 No.3)
  • Deduction/Induction/Abduction from "Abductive reasoning in Prolog and CHR" (Henning Christiansen, 2005)
  • "typein module" as used on the page operators : the module into which code typed in at the toplevel (using the [user] prompt) is added (I suppose).

Det, Semidet and Nondet

See here: https://eu.swi-prolog.org/pldoc/man?section=preddesc

Computation

  • Comma-list (as used on the page for tabling): A list constructed with functor `,/2`, which is not a real list as it terminates in a list element: (1,2,3) = (1,(2,3)) . Generally used as a conjunction.
  • Character or Char is an atom of length 1. Prolog has no specific character type.
  • Predicate Activation or just Activation : Basically, the stack frame of the predicate call. The runtime context of a clause in which variables denote concrete values (terms or empty cells). Corresponds to a "Byrd Box".
  • Unbound variable vs. Unbound value : An unbound variable is a variable name that denotes an "empty cell" in memory. It is a variable name for which var/1 exactly succeeds at call time (but maybe not later, after a unification occurs. On the other hand, definitely earlier because you cannot "unbind" a variable except through backtracking; this is waht i means for Prolog to be "assign-once"). An unbound value is a position in a complex term that denotes an "empty cell" in memory but that does not have a name. For example: length(L,2) . L is an unbound variable at first that is then unified with a complex term (a list of length 2) with 2 unbound values, which, when printed, appear as 2 unbound variables (i.e. their arbitrarilly chosen names are printed rather than their nonexistent content): L = [_5038, _5044] .)
  • Predicate well-behavedness
  • Predicate steadfastness . A more general definition: In "The Craft of Prolog" Richard O’Keef writes on page 96 that "we call the property of refusing to give wrong answers even when the query has an unexpected form (typically supplying values for what we normally think of as inputs*) steadfastness". Note that the ISO standard says nothing about this concept, although built-in predicates are generally "steadfast".
  • Partial term / Partially ground term : That term that is an unbound variable or may contain unbound variables not 100%% sure whether an unbound variable actually counts as such; the mode indicator descriptions seem to imply no).
  • Floundering : When negation-as-failure pretzels itself and leads to wrong answers because the negated goal contains unbound variables (i.e. is nonground). Raymond Reiter writes in "Knowledge in Action" (MIT Press, 2001): "Eclipse Prolog provides two negation operators, one of which suspends itself on negative, non-ground atoms, hoping that their free variables will eventually become bound during the rest of the computation, at which point the operator resumes."
  • call(atom_concat,prefix,suffix,R) .
  • call(atom_concat(prefix),suffix,R) .
  • call(atom_concat(prefix,suffix),R) .
  • call(atom_concat(prefix,suffix,R)) .
  • Fresh variable - a Prolog variable name that has not been used "to the left" and denotes a newly allocated "empty cell" in memory. For example, _ is always fresh where it appears.
  • Iterative Deepening - a heuristic to expand search trees which can be used in particular to transform Prolog's depth-first search strategy into a depth-limited breadth-first search strategy. This expands shallow nodes first and avoids accidental infinite descent on depth-first search. See "Depth-First Iterative Deepening: An Optimal Admissible Tree Search" by Richard Korf, Artificial Intelligence 27 (1985), Elsevier. Also Wikipedia . See also call_with_depth_limit/3 and call_with_inference_limit/3
  • Guard - a test made at the beginning of a clause body for conditions that cannot be captured by simple head unification. Often followed by a cut to "commit" to the clause. Generally done using `,/2` but sometimes using ->/2 . Example:
  • Guarded Horn Clauses , Guarded Definite Clauses particular logic programming languages derived from Prolog meant to be run on (highly) parallel machines (in particular so-called "5th generation" hardware). This research branch seems to have been abandoned (for now). Languages like PARLOG and Parallel Prolog are ancestors. See also: The deevolution of concurrent logic programming languages .
  • CHR - Abbreviation for Constraint Handling Rules , an approach promoting forward-chaining rules working on a blackboard store. SWI-Prolog has an implementation running in the context of a single clause: CHR . See also: Wikipedia: Constraint Handling Rules
  • Clause indexing - how a Prolog implementation looks up a matching clause head. Indexing may or may not be done on several arguments. SWI-Prolog indexes on first argument only, so if you want high discrimination by cases, move the most discriminatory parameter to the first place.
  • Clean/Defaulty representation - a question of coding style. Clean representations can be efficiently distinguished by head unification alone. Defaulty (a pun on "faulty") representations force a coding style where a clause head matches, and the body distinguishes. This may be inefficient at runtime. See Triska's Triska's discussion at Clean vs. defaulty representations .
  • Cell A memory location. It is either empty or holds an atomic term or a compound term which referencing other cell containing the compound term name and the compound term arguments. A special case is the list cell with name `[|]` and two arguments (i.e. with arity 2). In LISP, this is called the "consbox", with the first argument the "car" and the second the "cdr". Once a cell has been filled, it becomes indistinguishable from other cells with the same content ( my_atom == my_atom ) or at the root of graphs of cells forming ground terms ( f(g(a,b),c) == f(g(a,b),c) ). This allows the underlying machinery to share parts of graphs representing terms. In a Prolog program, a cell, or rather, the root of graph of cells is denoted by a variable ( X = f(g(a,b),c) ). Thinking in terms of cells instead of terms is generally not needed unless empty cells and non-logical usage thereof enters the picture.
  • List cell a cell holding the compound term `[|]` (in SWI-Prolog, traditionally `.` in other Prologs) and two arguments. In a well-constructed list the, there is a list element on argument position 1 and there is a next listcell of the list backbone or [] on element position 2.
  • Empty cell a cell holding (as yet) nothing but which may be set to an atomic value of the root of a graph of cells as computation progresses. Setting an empty cell can be done only once (Prolog is "assign-once") but can be rolled back on backtracking. Empty cells are denoted by initially fresh variables in a Prolog clause. Non-atomic terms, which are roots of trees and sometimes graphs of cells, can have empty cells at their leaves nodes. Unlike ground terms, empty cells are distinguishable and have identity: X \== Y. : what these fresh variables denote, which are empty cells, are not the same, but X=a,Y=a,X==Y. . Empty cells are merged via unification: X \==Y, X=Y, X == Y : X and Y now designate the same empty cell. Thinking in terms of empty cells is not logical but computational and stateful in nature, and is done in the parts of the Prolog program which are doing state manipulation, for example those dealing with difference lists of open lists.
  • freeze/2 and family: freeze(X,write("Hello")),X=1. prints Hello .
  • dif/2 (ensure two variables are always different) and family: dif(X,Y),X=1,Y=2. succeeds but dif(X,Y),X=1,Y=1. fails
  • Attributed variables : A generalization which allows the programmer to set/get arbitrary attributes on an empty cell and perform arbitrary decisions on unifications.
  • Linting : The process of checking Prolog code for style errors and dubious constructions prior to compilation. This is done by library(check) and library(codewalk) . See also library(prolog_xref) See also the Wikipedia entry on the lint program
  • Pure Prolog : Unclear, depends on opinion. A Prolog that only allows Horn clauses, without control-flow constructs like !, ->, no negation-as-failure \+ (but presumably still allows \= as the FOL "not equal"), possibly no meta-predicates incl. "call", which may possibly terminate independently of clause ordering. A Prolof which is "nearer" an ideal fragment of First-Order Logic.
  • Proper Prolog : A proper Prolog interpreter is one that evaluates a negative literal not A, using negation-as-failure, and moreover, does so only when (at the time of evaluation) the atom A is ground. When A is not ground, the interpreter may suspend its evaluation, working on other literals until (with luck) A does become ground, or it may abort its computation. Either way, it never tries to fail on non-ground atoms. (Directly copied from Raymond Reiter: "Knowledge in Action", MIT Press, 2001 p. 107)

Classes of logic programs

  • Definite logic program or Positive logic program or Horn logic program : A logic program consisting of clauses of the form `a_0 :- a_1, .... , a_m (i.e. Prolog programs without negation)
  • Normal logic program or General logic program : A logic program consisting of clauses of the form `a_0 :- a_1, .... , a_m, \+ a_{m+1}, ... \+ a_n.`, where \+ stands for negation-as-failure. (i.e. Prolog program with negation)
  • Extended logic program : A logic program consisting of clauses of the form `l0 :- l_1, .... , l_m, \+ l_{m+1}, ... \+ l_n.`, where l0 ... ln denote literals formed by means of strong negation l = a or l = ¬a. ( Not supported in Prolog)
  • Positive disjunctive logic program : A logic program consisting of non-Horn clauses of the form `a_0 ⋁ ... ⋁ a_n :- b1_1, .... , b_m (i.e. disjunctions are allowed in the head, making formulation of "uncertain knowledge" feasible; not supported in Prolog)
  • Deduction , reasoning within the knowledge we already have, i.e. from those facts we know and those rules and regularities of the world that we are familiar with. E.g. reasoning from causes to effects: _"If you make a fire here, you will burn down the house."_ (Henning). To a first approximation, Prolog performs reverse deduction, aka. goal-directed search: _"To burn down the house, make a fire here"_, but in relatively basic and "programming" context. To apply this to actual planning and commonsense reasoning you need to have a more extensive logical infrastructure than Prolog provides out of the box. See for example Event Calculus .
  • Induction , finding general rules from the regularities that we have experienced in the facts that we know: these rules can be used later for prediction: _"Every time I made a fire in my living room, the house burnt down, aha, ... the next time I make a fire in my living room, the house will burn down, too."- (Henning) This is the purview of (unsupervised and symbol-based) machine learning. See Inductive Logic Programming for on introduction on how logic programming can be used in this domain.
  • Abduction , reasoning from observed results to the basic fact from which they follow, quite often it means from an observed effect to produce a qualified guess for a possible cause: _"The house burnt down, perhaps my cousin has made a fire in the living room again."_ The corresponding formalization and extension for logic programming is the subject of Abductive Logic Programming
  • Deductive database : Database implemented through a logic program that allows no function symbols and thus is based on a finite universe. Datalog is the paradigm here. (For a deductive database connected to a LISP-like language: datomic ). (How does this compare to a relational database with recursive operations / fixpoint operations? Should be the same...)
  • Extensional database (EDB) : The part of a logic program (or deductive database) that consist in facts.
  • Intensional database (IDB) : The part of a logic program (or deductive database) that consists in rules (implications and integrity constraints). In a deductive database, EDB+IDB form a compressed representation of all the ground atoms that can be deduced going bottom-up chaining implications "forward" from premiss to conclusion to conclusion until a fixpoint of the ground atoms has been reached. When doing a proof "top-down", one is verifying whether an atom is indeed a member of that fixpoint.
  • Herbrand Universe : The set of all ground terms constructed from constants and function symbols that appear in the program.
  • Herbrand Base : The set of all ground atoms ("atoms" in the logical sense, i.e. predicate calls, not in the Prolog sense of "distinguishable identifiers/strings") that can be constructed from predicate symbols that appear in the program and terms from the Herbrand Universe.
  • Proof witness or proof solution : a set of ground or partially ground terms that form a solution to a query with unbound variables: length([1,2],L) , gives L=2 ; the 2 is the proof witness (the proof is "constructive" and doesn't just say true or false). Sometimes Prolog emits a "template proof witness" instead: length(List,2) gives List=[_,_] , which is really a (most general) template for lists of length 2.
  • Free variable - this is sometimes used in the sense of a variable that is unbound (in the Prolog sense: it has no value). That's confusing though. In logic, the "free variable" in a formula is one which is not bound (in the logic sense) by a quantifier (or a lambda if those are allowed). A bound variable is said to be "in the scope of a quantifier". The same variable (variable name) can occur in a formula in places where it is bound and free, so we have to really talk about free and bound occurrences of variables rather than free and bound variables.
  • Theory - A set of true sentences (expressed in and part of some specified logic). Concretely, a Prolog program is a theory with facts and sentences pre-labeled as "true".
  • Model Theory : In mathematics, model theory is the study of the relationship between formal theories (a collection of sentences in a formal language expressing statements about a mathematical structure), and their models, taken as interpretations that satisfy the sentences of that theory.
  • Proof Theory : Proof theory is a major branch of mathematical logic that represents proofs as formal mathematical objects, facilitating their analysis by mathematical techniques. Proofs are typically presented as inductively-defined data structures such as plain lists, boxed lists, or trees, which are constructed according to the axioms and rules of inference of the logical system. As such, proof theory is syntactic in nature, in contrast to model theory, which is semantic in nature.
  • Model - A truth value assignment to atoms (i.e. facts) that makes all of the sentences of a theory true (and doesn't imply inconsistencies).
  • Valid : : If the sentence is true in all models.
  • Satisfiable : If there is at least one model in which the sentence is true.
  • Unsatisfiable : If there is no model in which the sentence is true.
  • Statement - "A sentence put to work" . From Wikipedia: Statement : (a) a meaningful declarative sentence that is true or false, or (b) the assertion that is made by a true or false declarative sentence. In some treatments "statement" is introduced in order to distinguish a sentence from its informational content. A statement is regarded as the information content of an information-bearing sentence. Thus, a sentence is related to the statement it bears like a numeral to the number it refers to. Statements are abstract logical entities, while sentences are grammatical entities.
  • Expression - From Wikipedia: Expression : In mathematics, an expression or mathematical expression is a finite combination of symbols that is well-formed according to rules that depend on the context.
  • Proposition - More or less the same as a Statement or a Sentence. See Wikipedia: Proposition . In propositional logic , we do not work at level of expressions involving relations and objects and equality and quantifiers but at the level of (opaque) propositional variables linked by logic operators; the propositional variables takes one a value from some finite set (generally a value of the finite set {true,false}; but one can generalize to non-logic settings, for example in belief networks the propositional variable can take on any of a set of values describing an outcome and logical connectives take on the meaning of set operations)
  • Theorem - A sentence (of some logic adjoined to some theory) that can be labeled true ("proven") by a proof procedure. Goals for which the Prolog prover succeeds (which the Prolog prover accepts) are theorems for the pair (Prolog logic,Prolog program). A theorem is of course accompanied by at least one proof. Note that most Theorems are of low interest: for example, in the theory of Peano Numbers, 1+2<4 . See also: Wikipedia: Theorem , which has a glossary of related terms (Corollary etc.). That page also cites Paul Hoffman as _"It has been estimated that over a quarter of a million theorems are proved every year."_ Well, with Prolog you can prove a million theorems in a minute!
  • Tautology - A sentence (of some logic adjoined to some theory) that is true in all models. For example, in classical propositional logic: `(A ⇒ B) ⇔ (¬A ∨ B)` See also: Wikipedia: Tautology .
  • Signature of a logic, Sigma = `<F,P>`, is a set of function symbols name/arity adjoined to a set of predicate symbols name/arity
  • Atom (logic) (not to be confused with the "atom" of Prolog), or "atomic formula" is a word p(t1,...,tn) , n>=1 where p is a predicate symbol from a set P and the ti are terms from `T(F,V)`, build from a set of function symbols F and variable symbols from set of variable symbols V . The atom can also be a word of the form s = t where s , t `T(F,V)`. The set of atoms may be written `A(F,P)` (note that 0-arity predicate symbols are in principle not allowed)
  • Literal either an atom (a "positive literal") or its negation (a "negative literal") appearing in a formula. In Prolog, there is some subtlety involved with the fact that the negation is "weak" in the sense that it expresses negation-as-failure (absence of positive knowledge) instead of "strong" (presence of negative knowledge, as expressed by the negation of negation in classical (or other) logic). Although many approaches have been proposed to extend Prolog with strong negation, none of those has seen general acceptance so far. Instead, strong negation can be found in a different approach to logic programming: Answer Set Programming . The symbols for negation can be ~ or ¬ or naf or \+ . It depends on the author but generally ¬ is the strong negation.
  • Formula of a logic is the set of words inductively built from "atomic formula" using logical connectives (not, and, or, implies, iff, maybe less, maybe more) and the two quantifiers (adjoined to a variable) "there is" and "for all" (and maybe others). The set of formula `L(F,P)` over signature Sigma = `<F,P>` is said to be a first-order language over the signature Sigma. (See also Wikipedia: Well-Formed Formula ). An "open formula" is one with free variables, i.e. variables not bound by quantifiers. What the meaning, if any, of such an open formula is is context-dependent.
  • Clause - a general normal form for expressing predicate calculus formulas. It is a disjunction of literals (P1 ∨ P2 ∨ ....) whose arguments are terms. The terms are usually introduced by eliminating existential quantifiers. (from CACM March 1992)
  • Horn Clause - a clause containing (at most) one positive literal: H ∨ ~B1 ∨ ... (if Prolog is interpreted in the context of classical logic, the ~ is the strong negation). The term Definite Clause is used to denote a clause with exactly one positive literal. Prolog programs can be viewed as a set of definite clauses in which the positive literal is the head of the rule and the negative literals constitute the body or tail of the rule. (from CACM March 1992). A Horn Clause without negative literals is called a fact H , otherwise a rule . Note that a clause without the positive literal can be interpreted as a logical constraint (not to be confused with constraint logic programming). These are not supported by Prolog (but are supported by ASP systems).
  • Horn Clause (alternative) (alternative, from a text by David Warren): A Horn clause in a first-order logic is a universally quantified implication in which conjunction of atomic formulas implies an atomic formula. The Horn clause in `∀X∀Y∀Z ( arc(X,Y) ∧ path(Y,Z) ⇒ path(X,Z) )` could be a part of a description of paths through a graph. (This definition has the advantage that it justifies calling A :- B,C,D a Horn clause in a logic that does not allow the equivalence A⇒B = ¬A∨B, which is intuitionistic (positive) logic, which is the logic that really applies to Prolog even though it is often said that we are dealing in classical logic).
  • Intuitionistic Logic An ensemble of logics (and more widely, a philosophical stance) which does not accept the premise of classical logic that every sentences be necessarily labeled exactly one of "true" or "false", but accepts that some statements may remain "not labeled" until a (human) decision has been taken about how to proceed. In effect, what Prolog does is label sentences true if it can -- and otherwise fail, leaving the question open. It thus actually works in a fragment of positive intuitionistic logic rather than classical logic. Which makes complete sense from a programming perspective. Note that in particular, the implication A⇒B is NOT equal to ¬A∨B in Intuitionistic Logic. Instead it is taken to be statement like "Given a proof of A, you are then allowed to state that you also have a proof of B". See also: Uniform Proofs as a Foundation of Logic Programming (Dale Miller et al. 1991) and the Introduction of Logic programming with strong negation and inexact predicates (Gerd Wagner, 1991) . More on the philosophy at the Stanford Encyclopedia of Philosophy: Intuitionsitic Logic and Constructive Mathematics . Also, the problem of the Continuum Hypotheses .

Proof machinery

  • Resolution (see Robinson 1965: "A Machine Oriented Logic Based on the Resolution Principle", which can be found on the Interwebs for free): A single inference step used to prove the validity of predicate calculus for­mulas expressed as clauses. In its simplest version: (P∨Q) ∧ (P∨R) ⊢ (Q∨R) which is called the resolvant. (from CACM March 1992). See also: Wikipedia entry
  • Linear Resolution
  • SL-Resolution (sometimes SL Refutation ) described in Linear resolution with selection function PDF) (Kowalski and Kuehner, 1971) stands for "Linear Resolution with Selection function" (probably backronymed) is an original automated theorem proving proof idea whereby Robinson resolution is applied to a single literal in each step: _Linear resolution with selection function is a restricted form of linear resolution. The main restriction is effected by a selection function which chooses from each clause a single literal to be resolved upon in that clause. This and other restrictions are adapted to linear resolution from Loveland's model elimination._ (adapted from Shanahan)
  • SLD-Resolution (sometimes SLD Refutation ) described in Predicate Logic as Programming Language (Kowalski 1974) it stands for "SL-Resolution for Definite clauses" and is SL-Resolution applied to Horn clauses. SLD-Resolution is still non-deterministic and needs to be further restricted to be implementable. Prolog is the result of applying a restricted form of SLD-Resolution to the definite clause subset of predicate calculus, as described by Colmerauer, Kanoui, Roussel, Pasero in "Un Système de Communication Homme-Machine", 1973 (Research Report, Université Aix-Marseille Luminy): The leftmost atom in a goal clause is always chosen to resolve against, definite clauses are tried top-to-bottom order and a depth-first search is employed, for efficiency reasosn, the unification algorithm omits the occurs check. In fact, SLD-resolution is not strictly speaking a form of SL resolution, since it is more liberal in the selection functions it allows. (text adapted from "Solving the Frame Problem" by Murray Shanahan, MIT Press, 1997).

"SLD resolution can be understood procedurally as executing a nondeterministic program with procedure calls" (David Warren),

  • SLDNF-Resolution (sometimes SLDNF Refutation ): SLD Resolution with "Negation as Failure" to implement a "weak negation" operator.
  • SLG-Resolution A proof strategy whereby intermediate results are cached ( tabled , this is called tabling and sometimes memoing ). This makes it possible to write programs without having to pay special attention to infinite descent during depth-first search if the clauses are badly ordered. Prolog behaves more like a bottom-up theorem prover. (This may have been called "OLD Resolution with Tabulation" OLD Resolution with Tabulation, Taisuke Sato, July 1986 alias "OLDT Resolution" in the 80s, not sure). See: tabling . Certainly a feature that all modern Prolog systems should have and that should be taught. Refutation completeness A property of the SLD proof method in that SLD is "refutation complete" for Horn clauses. This means that if a ground answer is a logical consequence of a program then there is an SLD refutation that generates/accepts that answer (or a more general one). There may, however be some proofs paths that are infinite in length. Since Prolog must search this tree for the answers, its depth-first search may get caught on an infinite path, before it gets to the answer.

The evolution of the Prolog proof approach

From the above, we have:

  • Resolution (Robinson 1965) (basic principle used in systems like "Markgraf Karl Refutation Procedure" of mid-70s .. mid 80s, with additional control heuristic to direct the search). Also in Hewitt's PLANNER language (not sure whether implemented, there are obviously efforts at retconning precedence & history here; in the end it doesn't matter ... next problem!).
  • ⇒ Linear Resolution (?)
  • ⇒ SL Resolution (Kowalski & Kuehner 1971). Kowalski is cited as: "I can recall trying to convince Hewitt that Planner was similar to SL-resolution."
  • ⇒ SLD Resolution (Kowalski 1974)
  • ⇒ PROLOG using (a modification of) SLD-Resolution (Colmerauer et al. 1973)
  • ⇒ PROLOG using SLDNF (many other branches exist)
  • ⇒ PROLOG using SLDNF and SLG

Completely different approaches at building proof systems exist: Those based on Sequent Calculus, bottom-up provers, Tableaux-based, Answer Set Programming (Stable Models) and probably others.

Furthermore

  • Stack Overflow: Fact, Rule, Procedure, Predicate
  • Glossary of Logic terms (PDF) by Marc Cohen

The parts of a list

  • A proper list or a **closed list* is a list that has the empty list [] as the terminating element of the list backbone ("list backbone" is not commonly used except by myself, but it's are pretty evocative, so I will use it here)

Example of a proper list: an empty list Empty and a list of length 3 List1 and of length 2 List2 .

The list Empty could also appear simply like this. There is no way to find out which of the above and the below is "really" the case from Prolog:

  • The backbone is formed by a series of list cells which are compound terms with name `[|]` and arity 2. In Prologs other than SWI-Prolog, the compound name is traditionally `.` -- but `.` is used for SWI-Prolog dicts now. A backbone can only be traversed from the "tip" to "fin". There is no way to fin a "prior list cell".
  • A variable List1 holding a list can be though of a referencing a "the first list cell" of the backbone. The predicate is_list/1 can be used to verify that the term reachable from List1 is indeed a proper list.
  • A variable List2 referencing a list cell further along the backbone sees a shorter list. Nevertheless, the data structure is shared between List1 and List2 and this fact is often exploited for (example, if an element reachable from both List1 and List2 is further instantiated, from X to 2 for example, then predicates holding either of List1 or List2 will see this change). See also: duplicate_term/2 and copy_term/2 .
  • An element of a list is any term (atomic or compound) that can be found at argument position 1 of a list cell.
  • The empty list is a distinguished list of length 0. In SWI-Prolog it is represented by a dedicated atomic term which is not an atom (other Prologs may have subtly differing representations)
  • The Head is a sequence of n>= 1 elements, most often just 1 element.
  • The Tail is a variable denoting the rest of the list (of length >=0) after the Head. The Tail can unifiy with [] .
  • [H|T]=[1,2,3]
  • [H1,H2|T]=[1,2,3]
  • [H1,H2,H3|T]=[1,2,3] ( T will not be [] - the list without the first three positions is the empty list)
  • [H1,H2,H3,H4|T]=[1,2,3] will fail.
  • The Tip of a list is the first list cell of the backbone (if it exists) or the empty list in case of an empty list (a bit synonymous with start of a list, beginning of a list, front of a list)
  • The Fin of a list is whatever is found on argument position 2 of the last list cell (if it exists). In a proper list, this is always the empty list.
  • Now we can talk about directions "tipwards" and "finwards"
  • A Prefix of a list is a sublist appearing at the start of a list, encompassing 0 <= n <= length list cells. It may be the empty prefix, which is [] . The empty list has an empty prefix.
  • A Suffix of a list is a sublist appearing at the end of a list any term (atomic or compound) that can be found at argument position 2 of a list cell (alternatively, or can appear as a Tail in destructuring). The last list cell (alternatively, a list of length 1) has an empty suffix. The empty list has no suffix (it is the suffix).
  • Prefix=[], Suffix=[], append(Prefix,Suffix,[]).
  • Prefix=[], Suffix=[1,2,3], append(Prefix,Suffix,[1,2,3]).
  • [H|T]=[1,2,3], Prefix=[H],Suffix=T, append(Prefix,Suffix,[1,2,3]).
  • [H1,H2|T]=[1,2,3], Prefix=[H1,H2],Suffix=T, append(Prefix,Suffix,[1,2,3]).
  • [H1,H2,H3|T]=[1,2,3], Prefix=[H1,H2,H3],Suffix=T, append(Prefix,Suffix,[1,2,3]).
  • prepend/add prefix/head : Newlist = [X|OldList] . If the list is seen as a stack, this is push . This is efficient.
  • append/add suffix/tail : append(OldList,Tail,NewList) . This is extremely expensive as it involves copying OldList . Practically never done. To borrow Perl terminology, this is shift (although Perl "shifts" at fin).
  • remove a head/prefix, remove at tip . OldList = [X|NewList] If the list is seen as a stack, this is pop . This is efficient.
  • remove a tail/suffix, removing at fin : append(NewList,Tail,OldList) . This is extremely expensive as it involves copying OldList into NewList . Practically never done. To borrow Perl terminology, this is unshift (although Perl "unshifts" at tip).

Special case: The open list*

An open list can still grow its backbone (it can be "further instantiated") because its Fin is not set: it is "empty cell". If the there is a variable naming the Fin, say Fin , then Fin is an unbound variable, var(Fin) returns true.

An open list is transformed into a closed list by unifying that Fin with [] .

A special case is the "empty open list", which is really just any unbound variable. (The future history of an unbound variable is always open, it could become anything, even the tip of a proper list).

Example of a nonempty open list:

An open list is simply created by: OpenList = [1,2,3|Fin]. . After Fin=[] it is then a proper list.

Difference Lists

A *difference list" (which is actually confusing terminology) is really just a "list difference": two variables which refer to two positions in a list: X=[a,b,c,d], X=[a,b|Y]. From there, you can infer the "list difference", which is the X list minus the Y list: [a,b,c] (and which in extremis can be generated with append(LDiff,Y,X). )

These two references can be packed into a term to pass them to other predicates: p(X-Y). p(X/Y). But they should not (why waste cycles?). Just use p(X,Y).

The above construction is useful when the underlying list is an "open list", where Y points to the empty cell "fin" (the write position) where new elements are appended by a producer, and X is trailing behind (the read position) where elements are consumed by a consumer. The "list difference" then is the current buffer, which is empty if X==Y, var(X), var(Y) and EOF is expressed by Y=[] .

Here is another representation of the above:

When based on an open list, when the empty cell at the "backbone fin" is called Fin and takes the role of Y above and the 'X' is called 'Tip':

Tip=[a,b,c,d|Fin]

We can obtain an element V at the tip: Tip=[V|NewTip] and use NewTip as new Tip in the next activation:

Analogous to imperative programming with pointers, Fin=[d|NewFin] grows the open list with d , and yields a fresh variable NewFin denoting the new fin, which is an empty cell.

This can continue for some time. Mayn algorithms do not consume at the tip but just append at the fin. In any case, when we are done: Fin=[] , which closes the list. Once that unification has been performed, a proper list can be found at Tip :

or if Tip and Fin were equal when the unification is performed, in which case the "list difference" is the empty list:

The "empty open difference list" is evidently trivially an empty cell (or two unbound variables denoting the same empty cell): Tip=Fin . It's a bit borderline. Is this really a "list"?

What do we call what a predicate call does?

It can fail or succeed of course (or throw an exception, rudely moving us back from logic-land back into programming-land), but if it succeeds:

  • length([a,b,c],3) verifies/checks the length of list [a,b,c]
  • length([a,b,c],3) verifies/checks whether list [a,b,c] is a member of the preimage of 3 (technically of the set {3}).
  • This is often called "going forward"
  • length([a,b,c],L) computes/deduces L from [a,b,c] or maps [a,b,c] to L
  • append([a,b],[c,d],X) . X contains no information about the "input"
  • append_reversible([a,b],[c,d],[X,PrefixLen]) . [X,PrefixLen] contains enough information to "get back" to the input!
  • Hallucinate information (this is a bad idea): length(L,3) yielding [a,b,c] ? NOPE!
  • Propose a most generic template containing unbound values that unifies with any member of the preimage: length(L,3) yielding [_,_,_] . Yes!
  • Generate the members of the pre-image if they can be enumerated: member(X,[a,b,c]) yields a , b , c in turn.
  • If the pre-image is higher-dimensional, this can become complex: append(L1,L2,[a,b,c]). yields L1 = [],L2 = [a, b, c] ; L1 = [a],L2 = [b, c] ; L1 = [a, b],L2 = [c] ; L1 = [a, b, c],L2 = []

IMAGES

  1. SWI-Prolog Editor

    swi prolog assign variable

  2. SWI-Prolog

    swi prolog assign variable

  3. SWI-Prolog Editor

    swi prolog assign variable

  4. PPT

    swi prolog assign variable

  5. SWI-Prolog Editor

    swi prolog assign variable

  6. Development Environments: Prolog Programming Setup · Franco Garcia

    swi prolog assign variable

VIDEO

  1. C++ : Why is "unused variable" warning not reported for all variables?

  2. Download dan Instal SWI Prolog

  3. SWI Prolog Settings

  4. Installing Swi-Prolog on Windows 11

  5. PROLOG Program to Calculate PI

  6. assign variable in c program||#cprogramming #coding #cprogrammingvideo #tutorial #shorts #trending

COMMENTS

  1. How does declaring variables in swi prolog work?

    Declaring variables is an artifact of early compiled languages. This is a very broad topic that belongs to a university-level lecture on compiler design, programming language design and so on. You "swap variables" when your variables are handles to registers in the processor or memory locations. Prolog is on a very different level, to the point ...

  2. Prolog- How to assign an expression to variable

    1 Answer Sorted by: 5 The predicate should describe a relation between potential arguments and expressions they could form, so why not call it args_expr/3. Here's an example for addition and multiplication. You can easily expand this approach for other expressions: args_expr (Arg1,Arg2,Arg1 + Arg2). args_expr (Arg1,Arg2,Arg1 * Arg2).

  3. SWI-Prolog -- Attributed variables

    % An attributed variable with attribute value Domain has been % assigned the value Y attr_unify_hook (Domain, Y) :- ( get_attr (Y, domain, Dom2) -> ord_intersection (Domain, Dom2, NewDomain), ( NewDomain == [] -> fail ; NewDomain = [Value] -> Y = Value ; put_attr (Y, domain, NewDomain) ) ; var (Y) -> put_attr ( Y, domain, Domain ) ; ...

  4. SWI-Prolog -- The SWI-Prolog syntax

    2.15.1 ISO Syntax Support This section lists various extensions w.r.t. the ISO Prolog syntax. 2.15.1.1 Processor Character Set The processor character set specifies the class of each character used for parsing Prolog source text. Character classification is fixed to Unicode. See also section 2.18 . 2.15.1.2 Nested comments

  5. SWI-Prolog -- Global variables

    Only one value (which can be an arbitrary complex Prolog term) can be associated to a variable at a time. Their value cannot be shared among threads. Each thread has its own namespace and values for global variables. Currently global variables are scoped globally. We may consider module scoping in future versions.

  6. Attributed Variables in Prolog

    This package implements attributed variables. It provides a means of. Predicates for adding, changing and removing attributes. Attributed Variables library (atts)a (n (A))a (n (B)) , where a (n (C)) and To accomplish this, we need a way to reason about attributes of variable. The predicate get_atts/2 is available for this purpose:

  7. SWI-Prolog -- labeling/2

    indomain/1 label/1 labeling/2 Packages Availability: :- use_module ( library (clpfd) ). labeling ( +Options, +Vars) Assign a value to each variable in Vars. Labeling means systematically trying out values for the finite domain variables Vars until all of them are ground. The domain of each variable in Vars must be finite.

  8. SWI-Prolog -- library(lists): List Manipulation

    Documentation Reference manual The SWI-Prolog library library (aggregate): Aggregation operators on backtrackable predicates library (ansi_term): Print decorated text to ANSI consoles library (apply): Apply predicates on a list library (assoc): Association lists library (broadcast): Broadcast and receive event notifications

  9. SWI-Prolog -- Global variables

    4.33 Global variables. Global variables are associations between names (atoms) and terms. They differ in various ways from storing information using assert/1 or recorda/3.. The value lives on the Prolog (global) stack.

  10. Assign-once Variables

    So let's write an simple Prolog program at check how are can do something interesting with only assign-once variables. Let's contemplate the problem of adding up the numbers in a list. Prolog lives a list-processing language, similar to Lisp. Its primary data structure is the tree (called a term), a high gemeinsames form the which is who list.

  11. MoSCoW prioritization of the product backlog

    To set the value to backlog item you need just click it (in any view, either STORY MAP, BACKLOG, PLAN or WORK) to access details in the side view. Prioritization fields are displayed below the title of the backlog item. The first one is MoSCoW. Value can be visible on cards in STORY MAP. Once the value is entered, you can filter and group items ...

  12. PDF A search for new variable stars using digitized Moscow collection plates

    Variable star search 6300 stars in this 1.2x1.2 deg. field. V1013 Oph (RRAB type) V1013 Oph (RRAB type) V1013 Oph (RRAB type) P = 0.619447 d. New EA binary P = 0.716296 d. A typical false alarm A blended star with corrupted photometry. ASAS J175719+0445.6 (L type) An isolated star

  13. SWI-Prolog -- Attributed variables

    There is no consensus in the Prolog community on the exact definition and interface to attributed variables. The SWI-Prolog interface is identical to the one realised by Bart Demoen for hProlog Demoen, 2002. This interface is simple and available on all Prolog systems that can run the Leuven CHR system (see chapter 9 and the Leuven CHR page ).

  14. SWI-Prolog -- Getting started quickly

    The file extension .pl is associated with the program swipl-win.exe. Opening a .pl file will cause swipl-win.exe to start, change directory to the directory in which the file to open resides, and load this file. The normal way to start the likes.pl file mentioned in section 2.1.1.1 is by simply double-clicking this file in the Windows explorer.

  15. Swiss set boundaries in Moscow

    Swiss engineers are using satellite technology to create a new land registry for the Russian capital, Moscow. The project, funded by the World Bank, is helping to resolve boundary disputes at a ...

  16. New variable stars on digitized Moscow collection plates. The field of

    In the course of a program to digitize the astronomical plates of the Sternberg Astronomical Institute's plate stacks, we are developing algorithms for searching for new variable stars and studying them using digitized photographic plates. We have discovered and studied 480 new variable stars in a 10° × 10° field of view centered on 66 Ophiuchi. The digitized plate negatives used are from ...

  17. SWI-Prolog -- Boolean expressions

    The SWI-Prolog library library (clpb): CLP (B): Constraint Logic Programming over Boolean Variables Introduction Boolean expressions Interface predicates Examples Obtaining BDDs Enabling monotonic CLP (B) Example: Pigeons Example: Boolean circuit Acknowledgments CLP (B) predicate index Packages A.8.2 Boolean expressions

  18. Rosatom Starts Life Tests of Third-Generation VVER-440 Nuclear Fuel

    Dukovany NPP with 2040 MWe of installed capacity has four power units powered by VVER-440 reactors which were commissioned one by one in 1985-1987. The plant generates about 13 billion kWh of electricity annually covering approximately 20% of power consumption in the Czech Republic. Together with Temelin NPP (two units with VVER-1000), ČEZ ...

  19. SWI-Prolog -- Glossary of Terms

    anonymous [variable] The variable _ is called the anonymous variable. Multiple occurrences of _ in a single term are not shared. arguments Arguments are terms that appear in a compound term. A1 and a2 are the first and second argument of the term myterm (A1, a2). arity Argument count (= number of arguments) of a compound term. assert