possibilities of visualizing the solution process of ... · the best of the author’s knowledge,...

POSSIBILITIES OF VISUALIZING THE SOLUTION PROCESS OF CONSTRAINT LOGIC SYSTEMS BY THE EXAMPLE OF SWI-PROLOG’S CLP(FD) LIBRARY

Fabian Stiehle

A Bachelor’s thesis in the field of Computer Science for the Degree

of Bachelor of Science in Angewandte Informatik

Konstanz University of Applied Sciences

July 2018

Declaration of Authorship ii

Declaration of Authorship

Ehrenwörtliche Erklärung

Hiermit erkläre ich, Fabian Stiehle, geboren am 16.02.94 in Ehingen,

(1) dass ich meine Bachelor arbeit mit dem Titel:

"POSSIBILITIES OF VISUALIZING THE SOLUTION PRO-

CESS OF CONSTRAINT LOGIC SYSTEMS BY THE EXAMPLE OF

SWI-PROLOG'S CLP(FD) LIBRARY“

in der Fakultät unter Anleitung von Professor Oliver Eck selbständig

und ohne fremde Hilfe angefertigt habe und keine anderen als die ange-

führten Hilfen benutzt habe;

(2) dass ich die Übernahme wörtlicher Zitate, von Tabellen, Zeichnungen,

Bildern und Programmen aus der Literatur oder anderen Quellen (In-

ternet) sowie die Verwendung der Gedanken anderer Autoren an den

entsprechenden Stellen innerhalb der Arbeit gekennzeichnet habe.

(3) dass die eingereichten Abgabe-Exemplare in Papierform und im PDF-

Format vollständig übereinstimmen.

Ich bin mir bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird.

Konstanz, 17. Juli 2018 Fabian Stiehle

Abstract iii

Abstract

Constraint logic programming is a useful and elegant way to solve complex

problems. Through its declarative nature, problems can often be solved in a

few lines of code. However, the implementation and flow of a program are of-

ten hard to comprehend—even with proper documentation. This thesis ex-

plores the possibilities of visualizing the solution process of constraint logic-

based systems by the example of SWI-Prolog’s CLP(FD) library. It explores to

what extent a dynamic, GUI-based visualization can help comprehend con-

straint logic programs. To achieve that, the thesis focuses on the development

of a GUI that is capable of visualizing the solving process of the SWI CLP(FD)

system. As a result, the thesis presents, to the best of the author’s knowledge,

the first application capable of visualizing SWI CLP(FD) programs and show-

cases how this application can be used in an educational context.

Contents iv

Contents

Declaration of Authorship ......................................................................... ii

Abstract .................................................................................................... iii

Contents ................................................................................................... iv

Figures ..................................................................................................... vi

Abbreviations ......................................................................................... viii

1 Introduction .................................................................................... 1

2 Literature review ............................................................................. 4

2.1 Prolog and SWI Prolog ............................................................................. 4

2.2 Constraint logic programming ................................................................. 4

2.3 SWI-Prolog’s CLP(FD) library .................................................................. 5

2.4 Existing visualization tools and other related work ............................... 12 2.4.1 Search tree visualization ....................................................................... 14 2.4.2 Combining propagation information and search tree visualization ....... 17 2.4.3 Visualizing variables and constraints .................................................... 19 2.4.4 CLPGUI .................................................................................................. 21

3 Requirements ................................................................................ 25

4 Architecture & Implementation .................................................... 28

4.1 Owl Tracer ............................................................................................. 29

4.2 Owl Inspector ........................................................................................ 35 4.2.1 Technologies ......................................................................................... 35 4.2.2 Architecture & Implementation ............................................................ 37 4.2.3 3D View ................................................................................................. 38 4.2.4 Search tree............................................................................................. 41

4.3 Data exchange ....................................................................................... 42

4.4 Additional Work .................................................................................... 43

5 Results .......................................................................................... 45

5.1 Exploration of constraints and their resulting effect ............................. 45

5.2 Exploration of labeling strategies .......................................................... 49

5.3 Possible other applications .................................................................... 52 5.3.1 Exploration of failures ........................................................................... 52 5.3.2 Performance debugging and general debugging .................................... 53

Contents v

6 Discussion ..................................................................................... 54

7 Conclusion .................................................................................... 57

Acknowledgments ................................................................................... 58

References ............................................................................................... 59

Figures vi

Figures

Figure 1: A sample CLP program in SWI’s syntax ............................................... 8 Figure 2: Posting the query to the Prolog interpreter ......................................... 8 Figure 3: CLP execution ...................................................................................... 9 Figure 4: The map coloring problem by the example of the territories of

Australia ............................................................................................... 10 Figure 5: Implementation of the map coloring problem ................................... 10 Figure 6: Solution to the map coloring problem ............................................... 10 Figure 7: Abstraction of the search tree ............................................................ 16 Figure 8: The APT tool ...................................................................................... 17 Figure 9: OPL Studio’s search tree with the choice stack displayed on the lower

left ........................................................................................................ 18 Figure 10: The christmas tree view ................................................................... 18 Figure 11: Domain values over time as implemented in the VIFID tool. The top

row shows the final value. Red marks the already reduced values ......... 20 Figure 12: The proposed 3D view ...................................................................... 21 Figure 13: 3D view as implemented in CLPGUI ................................................. 23 Figure 14: CLPGUI’s 3D search tree .................................................................. 23 Figure 15: Example usage of the tracer predicate ............................................. 30 Figure 16: Example of the tracer predicate with separate name assignments ... 30 Figure 17: The execution flow of the trace predicates ....................................... 34 Figure 18: The Owl Tracer module in the context of the entire system ............. 34 Figure 19: The annotated map coloring problem .............................................. 35 Figure 20: Query of the annotated map coloring problem................................. 35 Figure 21: The GUI’s React components ........................................................... 37 Figure 22: The GUI’s general layout with the Panel components highlighted in

yellow ................................................................................................... 38 Figure 23: The axes of the 3D view ................................................................... 39 Figure 24: The time wind panel selecting timestamps from 2 to 11 .................. 39 Figure 25: Panel to toggle variables .................................................................. 39 Figure 26: 3D view visualizing the map coloring problem ................................. 40 Figure 27: The overall architecture of the GUI, the tracer, and their

communication ..................................................................................... 42 Figure 28: A little annotated CLP program ....................................................... 43 Figure 29: The from the program in Figure 28 generated trace file ................... 44 Figure 30: Example CLP program to showcase all_different/1 and

all_distinct/1 ................................................................................ 46

Figure 31: Propagation of all_diff/1 ........................................................... 47

Figure 32: Propagation of all_dist/1 ........................................................... 47

Figure 33: Sudoku problem with all_distinct/1 ........................................ 48

Figures vii

Figure 34: Sudoku problem with all_different/1, failing to find a solution .............................................................................................................. 49

Figure 35: Propagation of the 𝑆𝐸𝑁𝐷 + 𝑀𝑂𝑅𝐸 = 𝑀𝑂𝑁𝐸𝑌 problem with the default labeling strategy........................................................................ 50

Figure 36: Propagation of the 𝑆𝐸𝑁𝐷 + 𝑀𝑂𝑅𝐸 = 𝑀𝑂𝑁𝐸𝑌 problem with the max value selection strategy ......................................................................... 50

Figure 37: The search tree view of the 𝑆𝐸𝑁𝐷 + 𝑀𝑂𝑅𝐸 = 𝑀𝑂𝑁𝐸𝑌 problem using the default labeling option. The time wind feature was used to focus on the labeling process exclusively. ............................................. 51

Figure 38: Figure 38: The search tree view of the 𝑆𝐸𝑁𝐷 + 𝑀𝑂𝑅𝐸 = 𝑀𝑂𝑁𝐸𝑌 problem using the min down labeling option. The time wind feature was used to focus on the labeling process exclusively. ................................. 52

Abbreviations viii

Abbreviations

CLP Constraint logic programming

CLP(FD) CLP over the domain of finite integers

CSP Constraint satisfaction problem

1 Introduction 1

1 Introduction

Constraint logic programming (CLP) has come a long way since its original in-

troduction in 1987.1 The CLP paradigm has managed to successfully combine

logic programming with constraint programming2 and is applied in a wide range

of fields, such as bioinformatics, planning, scheduling problems, and data-

bases.3

Alain Colmerauer, the original creator of Prolog,4 introduced the first CLP lan-

guage with Prolog III,5 after laying the theoretical foundation for the CLP para-

digm with Prolog II.6

Since then, almost any Prolog version and dialect has shipped with its own CLP

library or extension. Today, SWI-Prolog is the most popular Prolog dialect and

one of the few that are still in active development. It comes with its own set of

built-in CLP libraries which have been originally introduced by Markus Triska.

Triska’s CLP libraries are in many ways an evolution of previous existing librar-

ies, especially in regard to their correctness.7

While CLP systems can be described in general, they usually are restricted and

defined over certain domains. The most widely utilized is the domain over finite

domains. CLP over finite domains, for short CLP(FD), is able to reason over a

finite range of integers.8 This thesis concerns itself with CLP(FD) exclusively.

Through their expressive constraints and powerful constraint solvers, CLP sys-

tems in general often allow to solve complex problems in a very declarative and

1 Jaffar and Lassez 1987. 2 Apt 2003. 3 Wallace 1996; Backofen and Gilbert 2006; Gavanelli and Rossi 2010 4 Colmerauer and Roussel 1996. 5 Colmerauer 1990. 6 Jaffar and Lassez 1987. 7 Triska 2013. 8 Gavanelli and Rossi 2010.

1 Introduction 2

elegant way—often resulting in surprisingly compact programs.9 This declara-

tive nature, however, comes with its own set of problems. Combined with the

non-transparent nature of the process of domain propagation, domain reduc-

tion and the at times counterintuitive behavior of Prolog’s backtracking search,

CLP programs can be hard to comprehend and therefore hard to debug, under-

stand, extend and improve.10

To address this issue, many graphical visualization tools for CLP systems have

been developed and successfully applied. CLP programs need specialized visu-

alization techniques, since traditional program visualizations are not sufficient

to comprehend and faithfully display the execution of a CLP system.11

While many different tools for a range of CLP languages do exist, there is, to

the best of the author’s knowledge, no tool to visualize SWI-Prolog’s CLP(FD)

system. The thesis sets out to fill this gap.

The aim of this work is to develop a modern graphical user interface that is ca-

pable of visualizing the process of SWI-Prolog’s CLP(FD) system, its domain

propagation, reduction, and labeling algorithm. It attempts to provide, by the

means of different visualizations, all the information necessary to better com-

prehend a given CLP program. The thesis especially focuses its efforts on devel-

oping the GUI for an educational application. It attempts this by providing in-

tuitive visualizations from which both the concepts of the CLP system in gen-

eral and the implementation of a given CLP program can be taught and under-

stood.

The thesis is structured as follows: Chapters 2.1 and 2.2 give a short history of

Prolog and CLP. Chapter 2.3 discusses SWI-Prolog’s CLP(FD) system in great

detail. Chapter 2.4 gives an overview of related literature and visualization

tools, describing different approaches to visualize CLP systems. Then, Chapter

3 lays out the general requirements for the application. Chapter 4 elaborates on

the architecture as well as the implementation of the application. Chapter 5

proceeds to evaluate the developed system by exploring first results of using

9 Ibid. 10 Carro and Hermenegildo 2000a; Carro and Hermenegildo 2000b; Aggoun et al. 1997. 11 Carro and Hermenegildo 2000a; Carro and Hermenegildo 2000b; Bracchi, Gefflot, and Paulin

2001; Fages, Soliman, and Coolen 2004.

1 Introduction 3

the GUI to visualize SWI-Prolog CLP(FD) programs. Based on these results,

Chapter 5 discusses how the requirements laid out were fulfilled and explores

first findings obtained by using the implemented GUI practically. It also points

to advantages and disadvantages of the chosen implementation and, building

on that, discusses possible future improvements and extensions. Lastly, Chap-

ter 6 gives a short conclusion.

2 Literature review 4

2 Literature review

2.1 Prolog and SWI Prolog

Invented in 1970 by the French computer scientist Alain Colmerauer, Prolog is

considered to be the first language and harbinger of the logic programming par-

adigm.12

This is all the more fascinating considering that Prolog is still the most popular

and widely used programming language of that category.13 Prolog’s most popu-

lar dialect is SWI-Prolog.14 It is released under the Simplified BSD License and

its source code can be openly accessed at GitHub. SWI-Prolog is available cross-

platform and provides feature-rich libraries one would expect from a modern

programming language. It is hence well suited to implement Prolog applica-

tions on modern computing environments.15

2.2 Constraint logic programming

It is no coincidence that the original inventor of Prolog, Alain Colmerauer, can

also be considered the forethinker and developer of the first CLP language.16 A

CLP language is a fusion of a logic programming language with concepts from

the constraint programming paradigm.17 Constraint programming describes the

programming paradigm of finding a solution by imposing a set of constraints

over variables. Finding a solution for a constraint satisfaction problem (CSP) is

defined as assigning values to all involved variables so that all imposed con-

straints are satisfied.18

12 Colmerauer and Roussel 1996; Cohen 2004. 13 TIOBE Index | TIOBE - The Software Quality Company 2018. 14 Wielemaker et al. 2012. 15 Wielemaker 2017. 16 Cohen 2004. 17 Gavanelli and Rossi 2010. 18 Apt 2003.


Colmerauer first paved the way for the CLP paradigm with Prolog II’s term

equation features and subsequently introduced the first CLP language with

Prolog III.19

However, the key observation, that led to the CLP paradigm, was made by Jaffar

and Lassez shortly after the introduction of Prolog II.20 They observed that

Prolog II’s ability to handle term equations were essentially just another form

of applying constraints to variables (since constraints can be seen as relations).

Furthermore, they showed that the constraint solving process can be seen as a

generalization of Prolog’s unification process.

Logic programming and constraint programming also share similarities on a

conceptual level. Both share a very declarative syntax. A CSP is, as stated by

Triska, described as precise as possible, while the actual solution to the problem

is left to the system. 21

A CLP language is always described in relation to its domain. CLP(X) describes

a CLP system over the domain of X. While there is a range of possible CLP do-

main types, most CSPs can be expressed and solved by CLP over the domain of

finite integers, for short CLP(FD). CLP(FD) has the advantage that commonly

known arithmetic relations can be used to constrain domains. CLP(FD) has be-

come the most popular instance of constraint logic programming.22 This thesis

concerns itself with CLP(FD) exclusively.

2.3 SWI-Prolog’s CLP(FD) library

Since Prolog III, almost all Prolog dialects have shipped with their own built-in

CLP library. In SWI-Prolog, the CLP(FD) system was developed by Markus

Triska.23 His CLP(FD) library can be seen, in many ways, as an evolution of pre-

vious existing CLP libraries, especially in regards of its correctness.

19 Colmerauer 1990; Jaffar and Lassez 1987. 20 Jaffar and Lassez 1987. 21 Triska 2013. 22 Gavanelli and Rossi 2010. 23 Triska 2013.


In this and following chapters, SWI-Prolog’s CLP(FD) system is often refer-

enced as the CLP system.

In contrast to all other CLP libraries at the time, Triska’s CLP(FD) library came

with a range of novel features to increase the correctness of the system, the

most notable features being:24

• the first system to reason over infinitely large integers

• the first system which guarantees termination of the constraint propa-

gation process (which is discussed momentarily)

Since Triska’s system is able to reason over arbitrarily large integers, one might

ask why it is still an instance of CLP(FD), the answer gives Triska himself:

“One can hardly speak of finite domain constraint solvers any more

when domains can clearly be infinite as well. Still, given that there are

always technological limits for the representation of any particular in-

teger in a CLP(FD)system, calling them CLP(Z) seems at least equally

deceiving.”25

The subsequent paragraphs give a short introduction to SWI-Prolog’s CLP(FD)

library and CLP in general. They discuss the execution flow of a CLP program

and its terminology. First, based on Stuart and Peter, a formal description of a

constraint satisfaction problem is given.26 This description is then underlined

by a practical example.

According to Stuart and Peter, a CSP can be defined as a set of variables 𝑉 which

are constrained by a set of constraints 𝐶:

𝑉 = {𝑣0, 𝑣2, … , 𝑣4}

𝐶 = 6𝑐0, 𝑐8, … , 𝑐9:

For each variable, a domain 𝑑2 is defined. Each domain 𝑑2 is a set that contains

all possible values 𝑣2can assume. In the case of SWI-Prolog’s CLP(FD), 𝑑2 can

be defined as follows:

𝑑2 = {−∞,… , +∞}

24 Ibid. 25 Ibid., 42. 26 Stuart and Peter 2003.


Each domain 𝑑2 can be restricted by one or multiple constraints. A constraint

𝑐8, according to Stuart and Peter, can be seen as a relation between a subset of

variables in 𝑉.

For example, let 𝑉 = {𝑣0, 𝑣>, 𝑣?} and let their corresponding domains {𝑑0, 𝑑>, 𝑑?}

all have the domain [0,3). Also, the following constraints shall be defined:

𝑐0 ∶= 𝑣0 < 𝑣>

𝑐> ∶= 𝑣> < 𝑣?

Just by evaluating the constraints, the CLP system could easily compute the re-

sult set 𝑆 = {0,1,2} which can be translated to 𝑣0 = 0, 𝑣> = 1, 𝑣? = 2.

Figure 1 shows how this CSP can be solved in SWI-Prolog’s syntax.

In this scenario, the CLP system was able to find a concrete solution with con-

straint propagation and reduction only. A constraint propagator is a function

that performs a reduction on a domain by filtering out all values that violate

any constraints imposed on the domain’s corresponding variable.27

In the given example, the constraint propagator of #</2 was able to reduce all

the domains of 𝑉 to a single value. Therefore, yielding a valid solution.

Since constraints can be seen as relations between variables, the alteration of

one variable’s domain likely affects other constraints in which the variable is

involved in as well.28 Consider, for example, the above given constraint 𝑐0: it

constraints both 𝑣0 and 𝑣>. Now, when 𝑐> is applied to 𝑣> as well, constraining

it further and altering its domain, the change needs to be propagated to 𝑐0, so

that 𝑐0 may reason over the change. This propagation process is called domain

propagation.29

Thus, the reduction of any domain through a constraint may in turn trigger an-

other constraint propagator acting on another domain which can lead to further

domain reductions. In complex programs, one domain reduction can lead to a

whole range of further propagators being executed.30

27 Triska 2013. 28 Stuart and Peter 2003; Gavanelli and Rossi 2010. 29 Triska 2013. 30 Ibid.


Figure 1: A sample CLP program in SWI’s syntax

Figure 2: Posting the query to the Prolog interpreter

Since most CLP programs are far more complex than the given example, con-

straint propagation alone seldom leads to a valid solution. Some form of search

needs to be involved. This search is usually performed by systematically trying

out different values from each variable’s domain until a set of values is found

that satisfies all constraints, consequently yielding a solution. This process is

called labeling.31

A variable can be instantiated or labeled to any value of its corresponding do-

main. In Prolog, a variable that assumed a concrete value is called a ground var-

iable.32

As soon as a variable is ground to a value of its domain, the domain of the var-

iable is obviously affected as well. The domain now formally consists of one

value, the value to which the variable was ground. This triggers domain propa-

gation and domain reductions. Thus, to find a valid solution, the labeling and

domain propagation processes are interleaved. Should an instantiation of a var-

iable to a value not yield a valid solution, backtracking on the variable is in-

voked, and the variable becomes unground again. The search is then continued

31 Ibid. 32 Wielemaker 2017, 104.

:- use_module(library(clpfd)).

little_clp_programm(V) :-

V = [V1, V2, V3],

V ins 0..2,

V1 #< V2,

V2 #< V3.

?- little_clp_programm(S).

S = [0, 1, 2].


from the latest choice point.33 Figure 3 illustrates this process in a simplified

depiction.

Figure 3: CLP execution

The well-known map coloring problem is an example of a CSP that can’t be

solved by applying constraints alone.34 Figure 5 shows an implementation in the

SWI syntax. Figure 4 shows the corresponding map. A valid solution to this

problem is a set of variables which depict the involved regions, assigned to col-

ors under the constraint that all neighboring regions must be assigned different

colors.35

33 Triska 2013, 11; Gavanelli and Rossi 2010, 67–69. 34 Stuart and Peter 2003, 138. 35 Ibid.

Set up domains &constraints

Domain propagation

initial propagation

Domain reduction

Label variable withits remainingdomain value

domain length = 1

Valid solution

All variableslabeled & consistent

Labeling

Potentially invokebacktracking

initial propagationinitial propagation

domain length = 1domain length = 1






Figure 4: The map coloring problem by the example of the territories of Australia36

Figure 5: Implementation of the map coloring problem

Figure 6: Solution to the map coloring problem

36 Ibid.


regions(Rs):-

Rs = [WA,NT,Q,NSW,V,SA,_],

% 0 = red

% 1 = green

% 2 = blue

Rs ins 0..2,

WA #\= NT, WA #\= SA,

SA #\= NT, SA #\= Q, SA #\= NSW, SA #\= V,

NT #\= Q,

Q #\= NSW,

NSW #\= V.

?- regions(R), labeling([], R).

R = [0, 1, 0, 1, 0, 2, 0]


Figures 5 and 6 show that the program is separated into two distinct parts:

1. the regions/1 predicate with the definition of all variables and their

constraints

2. the search part, seen in Figure 6, utilizing the labeling predicate, posted

as a query to the system

This is good practice, and usually how a CLP program is structured.37

The labeling process gives opportunity to apply a range of different strategies.

During the process, a choice must be made in which order the variables are in-

stantiated, as well as the order in which values from the variable’s correspond-

ing domain are tried out. The efficiency of these strategies may differ signifi-

cantly from program to program, which is why no general recommendation can

be given.38

SWI-Prolog’s CLP(FD) library offers a range of predefined strategies.39 The de-

fault variable instantiation strategy is to label the values in the order they ap-

pear in the given list. The default value selection strategy is trying the domain’s

values in ascending order.

In Chapter 5, the thesis gives a comparison of some labeling strategies utilizing

the through this thesis developed visualization tool.

In short, the execution of the CLP system can be roughly laid out as follows:

1. the evaluation of all posted constraints

2. the initial domain propagation leading to domain reductions and possi-

bly further domain propagations

3. the labeling process systematically trying out values

4. further domain propagation and reduction

5. eventually, the obtainment of a valid result or the report of a failure

37 Wielemaker 2017, 420–421. 38 Triska 2013, 13–14. 39 Wielemaker et al. 2014, 396–397.


2.4 Existing visualization tools and other related work

This chapter provides a review of a range of literature discussing and presenting

different visualization paradigms and how some of them are implemented in

existing visualization tools.

The tools mentioned in this chapter being:

• APT Tool

• VIFID/TRIFID Tool

• ILOG OPL Studio

• CLPGUI

The following reviewed literature depicts, to the best of the author’s knowledge,

the most recent contributions to this field of research. It must be noted though,

that all of the programs reviewed in the subsequent paragraphs are no longer

under active development, and for most no executable version and neither the

source code can be acquired. Also, none of these tools are compatible with SWI-

Prolog. However, much insight is still to be gained by examining previous ap-

proaches and results made in the field. The focus of the subsequent paragraphs

is on acquiring an overview of the applied visualization paradigms in the field;

since the tools, especially their visualizations, have aged badly, the focus is not

so much on their technical implementation.

Before reviewing any tool, however, it is essential to lay out some of the funda-

mentals. Carro and Hermenegildo discuss the problems of applying traditional

visualization techniques to CLP programs.40 They note that program visualiza-

tion usually focuses on the representation of the program flow or on the evolu-

tion of the program’s variables over time. In imperative and functional pro-

gramming, this process is relatively straightforward. However, classical repre-

sentations of variables, such as flowcharts or block diagrams, can’t be readily

applied to CLP systems. CLP variables are often complex structures which rep-

resent their domain and the constraints imposed on them.41 Carro and

Hermenegildo further add that the labeling process is a vital part of every CLP

40 Carro and Hermenegildo 2000b. 41 Ibid.


system and is relying on many internal mechanics (domain propagation, do-

main reduction, labeling). So a proper, specialized visualization of this process

is mandatory to understand, debug and improve the CLP program. A sole value

or control-based depiction is not sufficient to comprehend a CLP system to its

full extent.42

Carro and Hermenegildo also provide an interesting overview of different ap-

plications of CLP visualization tools, they categorize as follows:43

• Debugging: Visualization can be a complimentary aide alongside asser-

tions or text-based debugging

• Tuning and optimizing or performance debugging: Visualization may

help to point out performance problems and bottlenecks

• Teaching: Visualization may help to generally better understand CLP

systems and programs

However, these use cases don’t have to be looked at in isolation, as Carro and

Hermenegildo state, they can coexist and even complement each other.

Fages et al. and Bracchi et al. provide a categorization from a technical point of

view. Technically, they argue, visualization tools can be categorized as fol-

lows:44

• Dynamic visualization tools: The visualization is connected to the CLP

system in real time, and both sides can exchange information and direc-

tives with each other.

• Post-mortem visualization tools: Tools applied after the execution of the

program. The data to visualize is obtained during the execution and

saved for further processing.

• Dynamic visualization and control tools: In addition to a dynamic visu-

alization, these tools also enable to alter or control the execution of the

CLP program through the GUI.

42 Ibid.; Aggoun et al. 1997. 43 Carro and Hermenegildo 2000b. 44 Bracchi, Gefflot, and Paulin 2001; Fages, Soliman, and Coolen 2004.


Lastly, Carro and Hermenegildo argue that three visualization objectives exist:45

• visualization of the execution or control flow

• visualization of variable values over time

• visualization of constraints over variables

According to Carro and Hermenegildo, these three visualization paradigms of-

ten exist alongside. And in fact, all visualization techniques discussed in the

subsequent chapters implement and, in some form, combine these different

paradigms to provide a better visualization result.

2.4.1 Search tree visualization

Any Prolog execution can be visualized in the form of a classic search tree.46

Building on that, Carro and Hermenegildo discuss ways in which the execution

flow of a CLP program can be visualized in the form of an augmented search

tree.47

According to them, the execution of a CLP program can be observed from the

following contexts:

• the programmed search, meaning the actual execution of the predicates

as programmed by the user

• the solver operations, meaning the internal operations performed,

mostly during the labeling process

The visualization of the programmed search, so they argue, can be depicted by

a search tree whose nodes represent predicate calls in the form of successes,

redos, and failures.

They then propose to use the search tree of the programmed search as a frame-

work on which further visualizations can be attached to. For example, clicking

on a node may provide additional information about the internal state of the

labeling process at this point.

45 Carro and Hermenegildo 2000b. 46 Wielemaker et al. 2014, 24. 47 Carro and Hermenegildo 2000b.


To represent the internal solver operations in more detail, they propose a

search tree which depicts each internal operation of the solver as a node. Each

of these internal steps, just like any other predicate call, result in either failure

or success. In the failure case, another branch of the search tree is chosen by

backtracking one or more of the internal operations.

They conclude, however, that this depiction is highly dependent on the availa-

ble information. Accessing detailed information about the internal process of

the system may provide challenging.

Carro and Hermenegildo also propose a time-based or event-based depiction of

the tree.48 The search tree discussed so far lacks any representation of time or

resource consumption. They propose to incorporate resource-related infor-

mation into the view. For example, making the distance between nodes relate

to the time elapsed between both states. Other tools take similar approaches

with time-oriented views.49

A big challenge, which is not exclusive to the visualization of the control flow,

is managing the amount of data that might need to be displayed in the visuali-

zation. This is a recurring problem that other literature, discussed in the subse-

quent chapters, addresses as well. Throughout the thesis, this problem is ad-

dressed as information overload.

Carro and Hermenegildo define a general solution to the problem;50 they argue

that any visualization has to devise some form of abstraction. An abstraction

should only show essential parts of the available information at first glance (ac-

cording to the aims of the visualization) without cluttering the screen. For the

proposed search tree, they discuss an abstraction as implemented in the VISTA

tool: Parts of the search tree, usually near the leaves, where the tree is very

dense, are automatically collapsed. The tool allows then to expand the col-

lapsed search tree by clicking on the node. Figure 7 showcases this.

Another solution they propose is a global view that can be manipulated by a so-

called fish-eye transformation, allowing the user to magnify certain parts of the

48 Ibid. 49 Carro et al. 1993. 50 Carro and Hermenegildo 2000b.


execution while hiding others, providing both a global view and the possibility

to inspect certain parts in more detail.

Figure 7: Abstraction of the search tree51

About the usage of search trees to visualize CLP systems, they conclude that

tree representations are especially useful in education, correctness and perfor-

mance debugging. In some cases, the shape of the search tree might be enough

to track down performance bottlenecks. However, they find that such tree rep-

resentations lack a representation of time which reduces their usefulness for

performance debugging considerably. The tree representation must, therefore,

reflect time or resource consumption in some way to become more useful for

the use case.

Based on the description given by Carro and Hermenegildo, the APT tool can be

summarized as follows: 52 APT rewrites the provided source code through a

meta-interpreter written in Prolog. The tool then gathers information to an in-

ternal trace file at run-time. This execution can be replayed at will, and a user

may move forward and backward in time utilizing the already collected infor-

mation. The queries to the program are entered in the GUI. APT’s main visual-

ization is a tree depiction as shown in Figure 8. If the tree becomes too clut-

tered, scrollbars are shown to navigate.

51 Ibid. 52 Ibid.


Figure 8: The APT tool53

2.4.2 Combining propagation information and search tree visualization

Bracchi et al. describe a method to combine information from domain propaga-

tion with the classical search tree representation.54

They argue that it is important for each node of the tree to be understood in the

context of the current program state. They proceed to discuss the choice stack,

as it is implemented in OPL Studio.

The choice stack represents the choices made so far leading up to a given node,

any choice in the stack is displayed in the form of: variable=value. OPL Stu-

dio presents the corresponding choice stack once clicked on a node.55 This view

corresponds perfectly with the notion of the search tree serving as a general

framework on which other displays can be attached to, as discussed in the pre-

vious chapter.

53 Ibid., 17. 54 Bracchi, Gefflot, and Paulin 2001. 55 Ibid.


Figure 9: OPL Studio’s search tree with the choice stack displayed on the lower left56

Figure 10: The christmas tree view57

To build on that idea, Bracchi et al. present the christmas tree view, which dis-

plays a search tree enriched with statistics on the efficiency of the domain

56 Ibid., 3. 57 Ibid., 10.


reduction. In this view, they explain, the size of a search node is proportional

to the number of propagation calls triggered at each node. This number is usu-

ally also highly correlated to the computational time spent at each node. With

this display, the efficiency of the domain reduction at each node can be in-

spected. The larger the node, the more propagation steps are necessary as soon

as the current explored variables, represented by the node, are labeled. In case

of a failure, one can detect if the failure occurred early (small node) or late (large

node).58

2.4.3 Visualizing variables and constraints

Carro and Hermenegildo discuss methods to visualize variables and their con-

straints.59 Their work is based on “the perceived needs of a [CLP] programmer

trying to analyse the behaviour and characteristics of an execution.”60

To be able to evaluate the history of a program entirely, they argue, it is man-

datory to lay out information either animated or in a succession of pictures.

They point to the advantage of the latter: it enables easier and more direct com-

parisons of program states.

They discuss a method to depict the domain of a variable and all the possible

values it can assume by depicting each possible value as a dot or square. Over

time, each variable can be marked to reflect specific events in the program flow.

For example, a value could be colorized as soon as an applied constraint reduces

the value from the domain. To represent the history of such a domain, the dis-

play can be stacked (to represent time along the y-axis).61 This stacked visuali-

zation technique is implemented in the VIFID visualizer.62 Figure 11 shows the

implementation of the view in the VIFID tool.

58 Bracchi, Gefflot, and Paulin 2001. 59 Carro and Hermenegildo 2000a. 60 Ibid., 1. 61 Carro and Hermenegildo 2000a. 62 Carro et al. 1998.


Figure 11: Domain values over time as implemented in the VIFID tool. The top row

shows the final value. Red marks the already reduced values63

Carro and Hermenegildo point out that this visualization has its difficulties

with large domains or large amounts of variables.64 The latter problem, they ar-

gue, can be solved by triggering the display only for a subset of variables. In the

case of an annotated program (annotations mean user placed predicates that

collect data at the given program position), they note, the problem is under user

control.

The size of the domains is more difficult to address. Carro and Hermenegildo

propose a range of technical solutions such as scrollbars and providing means

for zooming in and out. An alternative to that, so they state, is depicting the

domain interval by a reduced number of points, hence, compressing the do-

main. Each point would then depict an interval of possible values only. They

further develop that idea by proposing to depict a domain only by its size.

Through this approach, a domain can be represented by a single number. An-

other alternative they present is discarding already reduced values of the do-

main, therefore compacting the domain depiction with each domain reduction.

Besides bringing up issues regarding the size of variables and domains, Carro

and Hermenegildo also criticize the counterintuitiveness of this 2D depiction.65

By combining these learnings with their proposed solution of abstracting the

domain to a single value, only depicting its size, they propose a novel 3D

63 Ibid., 4. 64 Carro and Hermenegildo 2000a. 65 Ibid.


presentation. The z-axis depicting time, the y-axis depicting the size of the do-

main and the x-axis the variable name.

They implement a prototypical tool, TRIFID, on top of the VIFID environment,

which utilizes annotations to generate the 3D depiction.66 The proposed 3D vis-

ualization is also successfully implemented in CLPGUI, which is discussed mo-

mentarily. 67

Figure 12: The proposed 3D view68

2.4.4 CLPGUI

Fages et al. present a generic graphical user interface to visualize constraint

logic programs.69

CLPGUI offers a GUI from which the execution of a CLP program can be con-

trolled. Annotations in the source program dynamically add buttons which are

capable of posting constraints or executing goals associated with them. This

allows for a very dynamic exploration of different procedures without touching

the source code.70

The trace of the CLP program is obtained by annotation predicates which are

inserted into the source code. Fages et al. discuss some of the advantages of this

approach:71

• flexibility regarding the granularity of the information to trace

66 Ibid. 67 Fages, Soliman, and Coolen 2004. 68 Carro and Hermenegildo 2000a, 39. 69 Fages, Soliman, and Coolen 2004. 70 Ibid. 71 Ibid.


• easiness and familiarity with their usage (it is like calling any other pred-

icate)

• portability of the GUI, since obtaining the trace is completely isolated to

the implementation of the predicates

However, they also state their limitations:

• inconvenience in annotating large programs

• difficulty in tracing the labeling process, since the labeling process is a

succession of many internal calls to other predicates which can’t be an-

notated directly

In CLPGUI, the GUI and the Prolog interpreter are connected by a client-server

architecture, which exchanges information in both directions over a socket con-

nection. This dynamic connection to the Prolog interpreter allows CLPGUI to

recompute any state of the program. This can be done by clicking on a node of

the search tree, which provides for a very dynamic exploration of the CLP pro-

gram. A user can recompute to any state, post different directives from there,

and explore a different solution process entirely. 72

CLPGUI uses the of Carro and Hermenegildo proposed and in Chapter 2.4.3 dis-

cussed 3D view to display the evolution of the domain variables.73 Figure 13

showcases the implementation of the 3D view in CLPGUI.

Regarding the 3D view, Fages et al. conclude:

“The 3D dynamic view of finite domain variables evolution is very use-

ful for teaching constraint programming. The effect of constraints is

immediately seen and many strategies can be tried step by step. The

possibility for a student to see the domain reductions as they are hap-

pening is really helpful for understanding the underlying machinery of

constraint programming. On larger sets of variables, the 3D view of

domains can still be useful to get a view of the pruning power of dif-

ferent constraint models, and of the efficiency of different search heu-

ristics, by comparing the general shape of domain reductions.”74

72 Ibid. 73 Carro and Hermenegildo 2000a. 74 Fages, Soliman, and Coolen 2004, 250.


Figure 13: 3D view as implemented in CLPGUI75

Figure 14: CLPGUI’s 3D search tree76

75 Ibid. 76 Ibid., 252.


For the visualization of the search tree, Fages et al. introduce a 3D search tree

interpretation which they found to be very useful for displaying large search

trees.77 The main advantage of this representation, they argue, is its compact-

ness. The 3D tree can be inspected by rotating and zooming. Figure 14 gives an

example.

77 Fages, Soliman, and Coolen 2004.

3 Requirements 25

3 Requirements

Building on the literature discussed, this chapter outlines a first concept and

defines non-functional requirements for the graphical user interface. From

that, requirements for the tracer, the system that obtains the program infor-

mation from the CLP system, are defined.

The focus on developing the GUI for educational applications profoundly in-

formed the requirements of the GUI and, with that, the requirements for the

tracer.

The GUI in general, to be most useful for educational usage, is expected to sat-

isfy the following non-functional requirements:

• provide visualizations to help understand the process of a CLP system in

general

• provide visualizations to help understand how a solution for a particular

CSP problem was obtained

• provide intuitive means to interact with all of its visualizations

To make the GUI most useful in a classroom or laboratory situation, a further

requirement was formalized: The GUI must work cross-platform

From the reviewed literature in Chapter 2.4, general requirements for all the

GUI’s visualizations were formalized. Visualizations need to:

• handle information overload by means of abstraction

• give the viewer a notion of elapsed time between data points

• display enough information to obtain a notion of the programs current

state at any time

• display, in some way, domain propagation, domain reduction, and the

labeling process

Since the requirements of the GUI are interdependent with the requirements of

the tracer, it was essential to commit early on to a visualization paradigm. The

3D view discussed in Chapters 2.4.3 and 2.4.4, depicting variable domains over

time, was chosen to be the main visualization of the GUI. As described in Chap-

ter 2.4.4, Fages et al. conclude that this 3D view is especially useful for teaching

3 Requirements 26

constraint programming.78 The effect of constraints and domain propagation

and reductions is effectively displayed. The view also provides a notion of time

and can handle large domains. To further augment the view, additional require-

ments were formalized:

• The view must display more detailed information once a data point is

hovered over by the user.

• The view must be able to display variables selectively; means must be

provided to let the user selectively investigate variables while hiding

others.

• The view must be able to display data points between different time

stamps selectively; means must be provided to let the user skip forward

and backward between time stamps of the collected trace.

To better showcase the control flow as well as the decisions made during the

labeling process, the decision was made to implement, in addition to the 3D

view, a complimentary tree-based visualization as described in Chapter 2.4.1

and 2.4.2.

To keep the search tree visuals as simple as possible, a classic 2D presentation

was chosen. The in Chapters 2.4.1 and 2.4.2 reviewed literature informed the

requirements of the view. The view must:

• display more detailed information once a data point is hovered over by

the user

• be able to showcase all choices made (choice stack) leading up to a node

• be able to display data points between different time stamps selectively

by providing means to let the user skip forward and backward between

timestamps of the trace

The general requirements of the GUI and its views, as well as the in Chapter 2.4

reviewed literature, informed the requirements of the tracer.

The tracer needs to:

• obtain information about the programs execution order

78 Fages, Soliman, and Coolen 2004.

3 Requirements 27

• be able to trace a user program that doesn’t find a solution; trace until

the failure is reported

• trace at a user-defined granularity

• communicate the obtained information to the GUI

• provide an adaptable system and format that is able to react to changing

requirements

Furthermore, the tracer needs to be able to obtain the following information

about each variable at a given timestamp in the program’s execution:

• the variable’s state (labeled or unlabeled)

• the variable’s current value if labeled

• the variable’s domain and the domain’s size

• the variable’s name as defined by the user

4 Architecture & Implementation 28

4 Architecture & Implementation

This chapter concerns itself with the actual implementation and architecture of

the software. It first gives a short overview of the application’s main compo-

nents and then proceeds to discuss their implementation in more detail.

The actual implementation of the system was split into two parts:

• the GUI, called Owl Inspector

• the tracer, called Owl Tracer

To be able to satisfy the cross-platform requirement of the GUI and to profit

from countless frontend libraries and frameworks, a web-based approach for

the GUI was chosen.

The tracer was written in SWI-Prolog. To obtain the necessary information, four

strategies were considered:

1. run the program through a meta-interpreter that mimics the CLP(FD)

system while obtaining information of the execution (as the in Chapter

2.41 discussed APT tool)

2. collect low-level data by accessing the system internals of the Prolog in-

terpreter itself

3. use the built-in trace predicate79

4. collect data from an annotated user code (as discussed in Chapter 2.44)

(1) was discarded to keep the tracer entirely separate from the CLP(FD) system;

the tracer should be an unobtrusive addition to any already existing CLP pro-

gram and not concern itself with the CLP system’s internal implementation.

(2) was discarded because of the sheer complexity.

(3) was discarded to keep the system independent from the trace predicate

and the debugging mode of SWI-Prolog. Also, the predicate’s output is very de-

tailed and would have to be analyzed and pruned extensively.80

79 Wielemaker 2017, 27–29. 80 Wielemaker et al. 2014, 207.


The decision was made that enough reflection predicates are being made avail-

able by SWI-Prolog’s CLP system to make (4) a viable option.81 Most tools re-

viewed in Chapter 2.4 take a similar approach. The decision was also highly in-

formed by the positive evaluation given by Fages et al., which was discussed in

Chapter 2.4.4.82 Chapter 6 provides a more detailed discussion of the repercus-

sions of this decision.

To keep the thesis organized, the remainder of the chapter is split into three

parts. First, the architecture and implementation of the tracer. Second, the ar-

chitecture and implementation of the GUI. And lastly, the data flow and com-

munication between each other.

The interested reader is invited to verify the following chapters themselves by

reading along in the project’s source code, openly available at GitHub.83

4.1 Owl Tracer

The tracer was implemented as a SWI-Prolog module. The main purpose of the

owl_tracer module is to expose a set of annotation predicates that can be

used to annotate certain parts of a CLP program and collect data on its execu-

tion.

The primary annotations were implemented as follows:

• owl_trace/1

• owl_trace/2

owl_trace/2 takes two arguments:

1. a list of variables that the user wants to trace

2. a list of strings that represent the names of the variables as they will be

displayed in the GUI. The names are given to each variable in the order

they appear in the first argument.

Figure 15 shows an example of using this predicate.

81 Ibid., 394. 82 Fages, Soliman, and Coolen 2004, 252. 83 Access the source code at <https://github.com/fstiehle/owl_inspector>


Figure 15: Example usage of the tracer predicate

The user can choose an arbitrary name for a variable, but to be able to identify

them internally, each name must be unique. Also, to avoid accidentally over-

riding a variable’s name, each variable can only be applied a name once.

owl_trace/1 takes an arbitrary Prolog predicate, executes it, and subse-

quently collects data of all the involved variables. This can be used to trace the

immediate effects of constraints. owl_trace/1 requires that all the in the

given predicate contained variables have been announced and assigned names

via owl_trace/2 before.

Any variable that a user wants to trace must, therefore, be given a name when

the system first encounters it. However, this doesn’t need to happen in one

predicate. Consider the in Figure 16 given valid program.

Figure 16: Example of the tracer predicate with separate name assignments

The decision to require the naming of the variables to be explicitly done by the

user was made to avoid any variables being traced accidentally. Of course, this

can lead to a tedious process when a program contains many variables to be

visualized. Also, the number of variables of a program may depend on other

factors. For example, in the popular 𝑛-queens problem, the number of variables

generated depends on the variable 𝑛.84

To address these issues, predicates have been implemented to automatically

generate names. While these predicates can be utilized, they still require the

generated names to be assigned to variables explicitly.

84 Erbas, Sarkeshik, and Tanik 1992.

owl_trace([A,B], ['A','B']).

owl_trace([A,B], ['A','B']),

% Code pertaining A and B

owl_trace([C,D], ['C','D']).

% Code pertaining C and D


The implemented predicates are defined as follows:

• owl_gen_names/2

• owl_gen_names/3

• owl_names_from_term/2

• owl_names_from_term/3

Each predicate was implemented to automatically generate names. The gener-

ated names 𝑁I can be formally defined as follows:

𝑁I = {𝐴1𝑝, 𝐵1𝑝,… , 𝑍1𝑝, 𝐴𝑁𝑝, … , 𝑍𝑁𝑝}

The initial 26 names are generated with index 1, as soon as more names are

required the index is increased by one. 𝑝 is a by the user defined postfix which

is appended to any variable name. owl_gen_names takes a number which rep-

resents the number of names to be generated, while owl_names_from_term

can be passed a Prolog term from which the number of necessary names is ex-

tracted by inspecting and counting the term’s variables.

A particular challenge of implementing the tracer predicates was to identify a

variable with its assigned name across different predicate calls. To the author’s

knowledge, there is no reliable way to obtain an identifier from a variable that

is consistent during the entire runtime. As a remedy, attributed variables were

utilized. Attributed variables are usually used to extend the unification algo-

rithm of Prolog, and have the following characteristics:85

• An attributed variable can be assigned an attribute in form of a Prolog

term.

• As soon as the attributed variable becomes ground a hook is executed.

The most prominent application of attributed variables are CLP systems itself.

Attributed variables allow a CLP system to define constraints and hook into the

standard Prolog unification process.86 To use this mechanism to assign names

to variables only might feel very heavy-handed, but while it makes the system

more complex internally, it enables a very clear and intuitive API for the user.

85 Wielemaker et al. 2014, 260–263. 86 Triska 2013.


owl_trace/2 applies the given names as attributes to the variables so that

owl_trace/1 can retrieve them.

While the immediate effects of constraints can be visualized by the

owl_trace/1 predicate, tracing domain propagation and the labeling process

proves to be more difficult. Both usually involve many to the CLP system inter-

nal predicate calls which may result in a variable becoming ground.87

To trace this, attributed variables were again utilized. As already described, at-

tributed variables provide a hook that is executed after any variable unifica-

tion.88 So every time the labeling process or a domain reduction grounds a vari-

able, this hook is executed. This offers the opportunity to obtain all the neces-

sary data of the ground variable and other involved variables.

Therefore, owl_trace/2, is not only used to assign names, but also to set up

the tracing of the given variables.

As just discussed, attributed variables were used to assign names to variables.

Originally, the implementation utilized the hook belonging to these attributed

variables to collect the necessary data during the labeling process and of do-

main propagations. However, for reasons still unknown, the hook wasn’t relia-

bly invoked. The when/2 predicate in combination with the ground(X) con-

dition was then utilized. The predicate internally also uses attributed variables

to execute a given goal once a given variable X becomes ground.89 However, by

utilizing this predicate, the hook was reliably invoked. Using two different

mechanisms relying on attributed variables may well be considered an ineffi-

ciency in the implementation. However, since the tracer isn’t subject to any

performance restrictions, this inefficiency doesn’t affect the results of this the-

sis. Still, the investigation of why the when/2 predicate succeeds and the other

approach failed as well as finding a more efficient and elegant implementation

should be subject to future work.

87 Ibid. 88 Wielemaker et al. 2014, 262. 89 Ibid., 263.


The data obtained after a predicate execution and on a variable ground is tem-

porarily saved to the Prolog database. This is done to allow the trace to be held

temporarily by the tracer in case the GUI requests the trace at a later point.

assertz/1 allows to assert a Prolog fact to the database during runtime.90 The

dynamic assertion of facts is usually considered to have a high impact on per-

formance, SWI-Prolog, however, guarantees the same performance for dynamic

assertion as for static assertion.91

Information is asserted as a tracepoint. Each tracepoint is inserted in chrono-

logical order to the database. This is important since tracepoints later depict

timestamps in the GUI and their order needs to reflect the actual execution of

the program. Each tracepoint collects the name of the executed predicate as

well as names of all involved variables, their values, their domains and their

domain sizes.

Each tracepoint isolates all required information of the state of the program at

a given timestamp, which has the advantage that they can each be investigated

independently. Making use of SWI-Prolog’s UTF8 support, instead of

owl_trace/1 and owl_trace/2, it is also possible to use '📌'/1 and '📌'/2

respectively to annotate the program.

Figures 18 and 19 show the from Chapter 2.3 familiar map coloring problem,

annotated with Owl Tracer annotations. Figure 17 shows the execution flow of

the tracer predicates. Figure 18 shows the Owl Tracer module in the context of

the entire system.

90 Ibid., 128. 91 Wielemaker 2017, 125.


Figure 17: The execution flow of the trace predicates

Figure 18: The Owl Tracer module in the context of the entire system

Which predicate?

Call trace predicate

owl_trace/1

Watch for a variableto become ground, thenassert data to database

Program finishesget_names

apply_names

Assert datato databse

Predicate returns

owl_trace/2

Execute given predicate

Which predicate?Which predicate?

owl_trace/1

owl_trace/2

Program finishesProgram finishes

owl_trace/1

Execute given predicate

owl_trace/2

Predicate returns

Execute given predicate Predicate

returns

GUI Process SWIPL Process

CLP(FD)

Owl Tracer Use

Annotated

Prolog program

Use

Disk

Annotated

Prolog program

load file

from disk

Use

WebsocketWebsocket

Generated trace


Figure 19: The annotated map coloring problem

Figure 20: Query of the annotated map coloring problem

4.2 Owl Inspector

The Owl Inspector is a web-based application capable of visualizing the trace

file. It is therefore completely decoupled from the tracer, and its only input is

the trace file. The following paragraphs first give a short introduction to the

technologies used to develop the application. The chapter then proceeds to give

a detailed explanation of the architecture and implementation of the GUI.

4.2.1 Technologies

To implement the views of the GUI, the JavaScript framework React was cho-

sen.92 React, an open source framework, originally developed by Facebook, is

one of the most popular front-end frameworks to implement web views and

manage their state. Its component-based approach as well as its enforced

92 Getting Started - React n.d.


:- use_module(tracer/owl_tracer).

regions(Rs):-

Rs = [WA,NT,Q,NSW,V,SA,_],

'📌'(Rs, ["WA","NT","Q","NSW","V","SA","T"]),

'📌'(Rs ins 0..2),

'📌'(WA #\= NT), '📌'(WA #\= SA),

'📌'(SA #\= NT), '📌'(SA #\= Q), '📌'(SA #\= NSW),

'📌'(SA #\= V), '📌'(NT #\= Q),

'📌'(Q #\= NSW), '📌'(NSW #\= V).

?- regions(R), labeling([], R).

R = [0, 1, 0, 1, 0, 2, 0]


philosophy of state management makes it a very effective tool to program mod-

ern, state of the art views.93

HTML elements were styled through SASS. SASS is a widely used extension to

CSS. It enriches CSS’ basic syntax with many useful features.94 To get started

quickly, the open source SASS library Sierra was used. Sierra is a very light-

weight and highly customizable library that provides a range of pre-styled SASS

components.95

To manage all dependencies of the GUI effectively, the npm package manager

was used. The npm package manager has become the most used package man-

ager for web projects with a vast library of frameworks and libraries available.96

To be interpretable by the browser, all SASS and React files97 need to be com-

piled to valid and browser compatible CSS and JavaScript files.

To accomplish this, the task tool Gulp was chosen.98 There are many other build

tools available which all offer a similar or equal feature set. Gulp was chosen

because it enables full control of the build process and the author’s general fa-

miliarity with the tool. Gulp tasks were written for a range of other purposes as

well, for example, to run a server during the development process or to com-

press and bundle files to increase the general performance of the application.

For the visualizations of the GUI, the library Echarts was chosen.99 Echarts sup-

ports 3D bar charts as well as 2D tree charts that are intuitively interactable.

Echarts also provides a coherent API, proper documentation as well as a React

wrapper component. Furthermore, Echarts provides an API to implement

tooltips to show additional information once a data point is hovered. The 3D

bar chart can be intuitively rotated and zoomed. The 2D tree view provides an

API to implement collapsible subtrees.

93 Thinking in React - React n.d. 94 Sass: Syntactically Awesome Style Sheets n.d. 95 Sierra: The smallest and lightest SCSS library n.d. 96 npm Documentation n.d. 97 Introducing JSX - React n.d. 98 gulp.js n.d. 99 ECharts Documentation n.d.


4.2.2 Architecture & Implementation

This chapter concern itself with the actual implementation of the GUI. It first

gives a broad overview of the architecture and the layout of the GUI. It then

provides a detailed description of the implementation of the 3D view and the

search tree view.

To visualize a given trace file in the JSON format (the trace file is discussed in

the next chapter), a basic parser was implemented. The parser consumes a JSON

file and tokenizes all given tracepoints to JavaScript objects.

These objects are then accumulated chronologically in a JavaScript object and

passed to the layout component. From there it is further distributed to the other

components through React’s state management system.100

One of React’s core philosophies is the component-based implementation of

web applications. Each view and each logical unit within a view can be repre-

sented as a React component.101 Figure 21 shows the component structure of the

GUI.

Figure 21: The GUI’s React components

The Layout component was implemented as the main view; it conditionally ren-

ders all the other views based on the chosen URL. The components are generally

organized according to the layout of the GUI. Each component in the Compo-

nents folder depicts a main view of the GUI, except for title, which is an auxil-

iary view component. The Panel folder contains the GUI’s panels. In the context

100 State and Lifecycle - React n.d. 101 Thinking in React - React n.d.

Components

Propagation

SearchTree

Log

Title

Layout Panel

Navigation

Variables

TimeWind


of the GUI, panels are reusable components, all styled consistently, which can

be used to enrich the main views. Figure 22 shows a screenshot of the GUI where

all the panel components are highlighted in yellow.

Figure 22: The GUI’s general layout with the Panel components highlighted in yel-

low

4.2.3 3D View

For the 3D view, the Echarts 3D bar chart was used. The data for the 3D view

was laid out as proposed by Carro et al. (discussed in Chapter 2.4.3):102

• Each bar depicts the state of one variable at a given timestamp

• The height of the bar represents its domain size

• timestamps progress along the x-axis

• variables are arranged along the y-axis

Figure 23 showcases this. Chapter 3 already detailed why this concept was cho-

sen.

102 Carro and Hermenegildo 2000a.


Figure 23: The axes of the 3D view103

Each bar depicts the state of a variable at a timestamp, each timestamp along

the x-axis depicts one of the following program states:

• after a traced variable became ground

• after the execution of a traced predicate

To enhance the 3D view, an option to toggle certain variables was implemented.

This feature allows to selectively include or exclude variables from the view.

The 3D view, as well as the search tree view, were further enhanced through the

time wind component. The time wind feature allows the user to inspect specific

timestamps of the trace while hiding others. The user can, through a slider,

specify a range to be shown, while excluding and hiding all the other

timestamps. Figure 24 showcases the feature.

Figure 24: The time wind panel selecting timestamps from 2 to 11

Figure 25: Panel to toggle variables

103 The axes were arranged differently to Carro et al. to reflect the arrangement of the axes in

Echarts.

ZY

X

X: TimestampsZ: Domain sizesY: Variable names


Both, the 3D view and the search tree view, were customized aesthetically to fit

in with the general style of the GUI. Figure 26 showcases the implemented 3D

view visualizing the familiar map coloring problem.

Through the variable and time wind feature, the user can directly modify the y

and x-axis by toggling variables and choosing a different range of timestamps

to be shown. These two axes are also the ones which are most prone to infor-

mation overload, either through the involvement of too many variables or a

long program execution resulting in many traced timestamps. Through the time

wind and variables feature this problem is under user control.

Figure 26: 3D view visualizing the map coloring problem

Each bar of the 3D view can be hovered over which then displays a tooltip with

further information about the variable. To depict the entire state of the solution

process, the tooltip was implemented to display the following information:

• the domain of the variable in propositional logic syntax, for example,

{2. .3 ∨ 5. .8}

• whether the variable is ground or not

• the value of the variable if ground

Additionally, each tooltip shows the name of the event that caused the

timestamp, either the name of the traced predicate or the name “Ground” to

signal the timestamp was caused by a traced variable becoming ground.


This allows, by inspecting each variable involved in a timestamp, a full compre-

hension of the state of the CLP program at this timestamp.

The 3D view can be generally interpreted as follows: The program’s execution

progresses from left to right. The variables usually start large in size and be-

come smaller as more constraints are evaluated. A variable with a domain size

of one is a ground variable. A timestamp solely consisting of ground variables

is a possible solution. If the possible solution is found to be invalid, variables

need to be backtracked; and the following timestamps show an increase in the

variable domain sizes. The execution continues from there until a valid solution

is found or the program reports a failure.

4.2.4 Search tree

To allow for a better understanding of the execution of the CLP program, the

search tree view was implemented. For this view, the Echarts 2D tree chart was

used. The search tree view can be seen as a complementary view to the 3D view.

Each node in the tree depicts a timestamp. The timestamp represents the state

of the program after a variable was ground or a traced predicate was executed.

The tree branches, by creating a new right subtree, as soon as a ground variable

is backtracked.

To correctly display the decisions made leading up to a node, each node is

marked with the values of the already ground variables. This essentially depicts

the choice stack as proposed by Bracchi et al. (discussed in Chapter 2.4.2).104

However, this implementation integrated the choice stack into the main view

itself in a condensed manner (just showing the ground variables).

Hovering over a node provides the following information about every involved

variable:

• whether the variable is ground or not

• if ground, the value it assumed

The view can be directly manipulated through the time wind feature. Also, all

subtrees are collapsible. This keeps information overload in check.

104 Bracchi, Gefflot, and Paulin 2001.


4.3 Data exchange

This chapter gives an overview of the communication between the tracer and

the GUI. Figure 27 gives a full overview of the GUI, the tracer, and their com-

munication.

The primary communication method between tracer and GUI is a WebSocket. A

WebSocket is a communication protocol on top of TCP. It allows for bidirec-

tional communication.105 The WebSocket allows both the GUI and the tracer to

initiate communication. The tracer was implemented to open a socket to the

GUI. This can be done by the owl_send/0 predicate. The GUI connects to the

socket and requests the trace.

Figure 27: The overall architecture of the GUI, the tracer, and their communication

The trace file is obtained by converting the in the Prolog database temporarily

saved data to JSON objects, according to the SWI-Prolog JSON library.106 The

general structure of the data saved in the database and the trace file is identical.

This made the process of converting the data to JSON very easy.

105 Hickson 2012. 106 Wielemaker n.d.

GUI Process SWIPL Process

CLP(FD)

Owl Tracer Use

Annotated

Prolog Program

Use

Disk

Annotated

Prolog Program

load file

from disk

Use

Generated

trace

Websocket

Websocket

React

Renderer

(Includes React Components and Parser)

View Controller

Use Use

Echarts


JSON was chosen as the format of the trace file for a number of reasons:

• the very flexible syntax

• to enable seamless communication with the web-based, in JavaScript im-

plemented GUI

• to be able to utilize SWI-Prolog’s feature rich JSON library107

Figure 28 shows the from Chapter 2.4 known CLP program and Figure 29 its

corresponding trace file.

To be valid, every trace file needs to first announce all of its involved variables

by supplying their names. The file then may contain an arbitrary amount of

tracepoints, each tracepoint represented by a JSON object.

This format has proven itself to be very flexible as it has undergone many

changes and additions during the experimental phase of the project. As every

JSON object contains all information necessary for its visualization, the trace

file could be theoretically split up and sent in pieces. This could be useful when

dealing with larger program traces but is out of scope for this thesis. Chapter 6

provides some discussion on this topic.

Figure 28: A little annotated CLP program

4.4 Additional Work

To test the GUI in a range of scenarios, common CLP problems were imple-

mented and annotated with the tracer module. Chapter 6 presents some of the

107 Ibid.



little_clp_programm(V) :-

V = [V1, V2, V3],

owl_names_from_term(V, Names),

'📌'(V, Names),

'📌'(V ins 0..2),

'📌'(V1 #< V2),

'📌'(V2 #< V3).


visualizations obtained. The examples can be reviewed in the codebase in the

examples folder.

A user guide was written to give new users an introduction to the program. The

user guide can be found in the codebase in the readme file.

Figure 29: The from the program in Figure 28 generated trace file

[ {"names": ["A1", "B1", "C1" ]}, { "id":"ins", "names": ["A1", "B1", "C1" ], "values": ["_6626", "_6632", "_6638" ], "domains": ["0..2", "0..2", "0..2" ], "domainSizes": [3, 3, 3 ] }, { "id":"#<", "names": ["A1", "B1" ], "values": ["_692", "_698" ], "domains": ["0..1", "1..2" ], "domainSizes": [2, 2 ] }, { "id":"Ground", "names": ["A1", "B1", "C1" ], "values": ["_698", "1", "_710" ], "domains": ["0..1", "1..1", "0..2" ], "domainSizes": [2, 1, 3 ] }, { "id":"Ground", "names": ["A1", "B1", "C1" ], "values": ["_698", "1", "2" ], "domains": ["0..1", "1..1", "2..2" ], "domainSizes": [2, 1, 1 ] }, { "id":"Ground", "names": ["A1", "B1", "C1" ], "values": ["0", "1", "2" ], "domains": ["0..0", "1..1", "2..2" ], "domainSizes": [1, 1, 1 ] }, { "id":"#<", "names": ["B1", "C1" ], "values": ["1", "2" ], "domains": ["1..1", "2..2" ], "domainSizes": [1, 1 ] } ]

5 Results 45

5 Results

The goal of this thesis was to develop a modern graphical user interface that is

capable of visualizing the process of SWI-Prolog’s CLP(FD) system. The thesis

especially focused its efforts on educational applications.

This chapter discusses first results of using the GUI to visualize CLP programs.

As discussed in Chapter 2.3, a CLP program’s execution generally involves the

following core procedures:108

• applying constraints to variables

• the labeling process

• domain reduction and domain propagation

This chapter gives two examples, focusing on those procedures, and discusses

how the GUI can be used to visualize and help comprehend them. It then shortly

outlines how the GUI could be used for different applications other than educa-

tional purposes.

The interested reader is invited to explore all these examples themselves as

they are all included in the example folder of the projects source code available

at GitHub. The user guide, also available at GitHub, gives a detailed explanation

on how to load and visualize these examples.109

5.1 Exploration of constraints and their resulting effect

The GUI has shown immense potential to showcase constraints and the result-

ing domain propagation and domain reduction. The following paragraph gives

one particularly fitting example where the GUI can be used to showcase domain

propagation and draw conclusions from it.

A recurring problem of CLP programs is the question of whether the constraint

all_different/1 or all_distinct/1 should be used.110 Both predicates

share similarities; however, all_distinct/1 generally propagates its effects

108 Gavanelli and Rossi 2010. 109 Access the source code at <https://github.com/fstiehle/owl_inspector> 110 Wielemaker 2017, 428–429.

5 Results 46

more effectively. In many cases, it is better to utilize all_distinct/1, how-

ever, in some cases all_different/1 may perform better since its CPU costs

are lower.111

A simple implementation of an annotated example program, which showcases

the difference of both predicates, is given in Figure 30.

Figure 30: Example CLP program to showcase all_different/1 and all_dis-tinct/1

Figures 31 and 32 show the visualizations of all_diff/1 and all_dist/1

respectively. Both predicates were implemented in the same way. Both yield the

same result: false. However, when taking a look at the visualization of the prop-

agation, we can see that all_dist/1 reported failure much earlier due to its

better propagation. all_diff/1 proceeds to the labeling process until the fail-

ure is caught. all_dist/1 reports the failure much earlier.

111 Ibid.; Triska 2013, 79; Ogborn n.d.



all_diff(A,B,C) :-

'📌'([A,B,C], ["A","B","C"]),

'📌'([A,B,C] ins 1..2),

'📌'(all_different([A,B,C])),

labeling([],[A,B,C]).

all_dist(A,B,C) :-

'📌'([A,B,C], ["A","B","C"]),

'📌'([A,B,C] ins 1..2),

'📌'(all_distinct([A,B,C])),

labeling([],[A,B,C]).

5 Results 47

Figure 31: Propagation of all_diff/1

Figure 32: Propagation of all_dist/1

In Figure 31, the second timestamp, on which a tooltip is shown, depicts the

applied all_different/1 constraint, the visualization showcases that this

has no immediate effect on the variables domains. The third timestamp depicts

the start of the labeling process and shows a failed attempt at grounding all

variables at the fifth timestamp. The labeling process then proceeds even

5 Results 48

further by backtracking and ungrounding variables until it finally reports the

failure. Figure 32 shows how all_distinct/1 reports the failure immedi-

ately. The program fails after one executed constraint.

In more complex programs, this can have an even more severe impact. Figure

33 showcases the propagation of the popular sudoku problem implemented

with all_distinct/1. Figure 34 shows the same program but implemented

with all_different/1. The particular implementation of the sudoku prob-

lem can be reviewed in the examples folder of the projects source code. The

implementation with all_distinct/1 is able to find a solution, while the im-

plementation utilizing all_different/1 fails to find a solution and would

require a continued search through the labeling/2 predicate.

Figure 33: Sudoku problem with all_distinct/1

This also shows that while the GUI can’t depict the actual computation time,

the number of timestamps shown by the GUI can be used to make a first deduc-

tion of the efficiency of a CLP program and its domain propagation.

5 Results 49

Figure 34: Sudoku problem with all_different/1, failing to find a solution

5.2 Exploration of labeling strategies

Another compelling use case of the GUI is the exploration of different labeling

strategies. As discussed in Chapter 2.3, the labeling predicate allows the user to

choose from a range of different strategies. Figure 35 shows the 3D view of the

𝑆𝐸𝑁𝐷 + 𝑀𝑂𝑅𝐸 = 𝑀𝑂𝑁𝐸𝑌 problem using the default labeling configuration.112

This is actually a problem where all_distinct/1 and all_different/1

are interchangeable.

Multiple browser windows, open at the same time, can be used to compare dif-

ferent strategies face to face. For each new strategy, a new GUI instance can be

opened in a window, leaving the old windows in their old state. Since the GUI

doesn’t depend on a permanent connection to the tracer and is purely a

frontend application, all the GUIs are fully functional and intractable.

The 3D visualization can be best used to showcase the efficiency of the value

selection strategy and the efficiency of the domain propagation and reduction

in general. Time wind can be used to focus on the labeling process only.

112 Ogborn n.d.

5 Results 50

Figure 36 shows the, compared to the in Figure 35 used default strategy, much

less efficient max value selection strategy.

Figure 35: Propagation of the 𝑆𝐸𝑁𝐷 + 𝑀𝑂𝑅𝐸 = 𝑀𝑂𝑁𝐸𝑌 problem with the default la-

beling strategy

Figure 36: Propagation of the 𝑆𝐸𝑁𝐷 + 𝑀𝑂𝑅𝐸 = 𝑀𝑂𝑁𝐸𝑌 problem with the max value

selection strategy

5 Results 51

The search tree can be best used to explore the variable instantiation strategy.

Furthermore, it can be used to inspect which branches of the tree result in re-

does, and how deep the branches were explored before a redo was reported. Fig-

ure 38 shows the search tree view of the 𝑆𝐸𝑁𝐷 + 𝑀𝑂𝑅𝐸 = 𝑀𝑂𝑁𝐸𝑌 problem

when combining min with the variable instantiation strategy up. Figure 37 dis-

plays the same problem, but with the default labeling configuration.

Figure 37: The search tree view of the 𝑆𝐸𝑁𝐷 + 𝑀𝑂𝑅𝐸 = 𝑀𝑂𝑁𝐸𝑌 problem using the

default labeling option. The time wind feature was used to focus on the labeling

process exclusively.

As can be seen in Figures 37 and 38, both explore the left subtree before report-

ing a redo, which leads to the tree branching off into a right subtree. However,

the default option in Figure 37 leads to a deeper right subtree. This means that

while they both explore the left subtree to the same depth, the min down strat-

egy yields a solution earlier.

This example also invites to explore the relationship between the 3D view and

the search tree in more detail. In Figure 35, the sixth timestamp from the right,

where all variables are ground (domain size of one), shows a failed attempt to

ground all variables. One timestamp to the right, some of the already grounded

variables need to be backtracked; this can be seen at a glance, since the domain

5 Results 52

sizes increase again. This backtracking essentially causes a redo and the crea-

tion of the right subtree in Figure 37.

Figure 38: Figure 38: The search tree view of the 𝑆𝐸𝑁𝐷 + 𝑀𝑂𝑅𝐸 = 𝑀𝑂𝑁𝐸𝑌 problem

using the min down labeling option. The time wind feature was used to focus on the

labeling process exclusively.

While there are many other observations to be made, the intention of this chap-

ter is not to analyze the 𝑆𝐸𝑁𝐷 + 𝑀𝑂𝑅𝐸 = 𝑀𝑂𝑁𝐸𝑌 problem. However, this

CSP masterfully shows how the 3D view and the search tree can be used com-

plimentary in reasoning over different labeling strategies.

5.3 Possible other applications

5.3.1 Exploration of failures

Since the tracer is collecting information until a failure of the user program is

caught, the GUI could be used to explore why a given user program is not able

to find a solution. This has already been shown partially in Chapter 5.1. The 3D

view is able to provide information on the domain reduction process and on why

and when certain values that should be included in the solution are ruled out

by the system. The search tree view provides information on why a certain

branch of the tree leads to a failure and why the system chose this branch in the

5 Results 53

first place. The practical usage of the GUI for this purpose, however, is still sub-

ject to further investigation.

5.3.2 Performance debugging and general debugging

Combining all the previously mentioned observations with console-based

benchmarks may provide all information necessary for performance debugging

and debugging in general. However, the GUI and tracer have yet to be tested in

real-world size projects. The possible limitations regarding real-world size pro-

jects are discussed in the subsequent chapter.

6 Discussion 54

6 Discussion

The subsequent paragraphs discuss the through Chapter 5 made observations

and how they relate to the most relevant defined requirements and related

works. They discuss the advantages and disadvantages of the implementation

of GUI and tracer and how they may affect future work.

Chapter 5.1 showed how the GUI could be used to showcase and comprehend

specific constraints as well as the resulting effect on other parts of the system

and the search for a solution in general. Chapter 5.2 gave an example of how

different labeling strategies can be compared and evaluated and how different

strategies affect a given CSP. This showed how the GUI can be successfully used

to comprehend and investigate the solution process of a given program as well

as how a CLP system operates in general.

The ability to explore these strategies in different windows concurrently, in-

creases the GUI’s practicality significantly. The GUI is also web-based, making

it available on every desktop platform.

The GUI applies most of the in Chapter 2.4 discussed visualization paradigms.

However, every visualization and the GUI in general, show a clear advancement

regarding aesthetics and the usability of the software. The 3D view was imple-

mented as proposed by Bracchi et al. (discussed in Chapters 2.4.3 and 2.4.4) but

was enriched with the variable toggle and time wind feature which can be used

to display data selectively. This enriches the usefulness of the view immensely

as seen throughout Chapter 5. Also, this provides means for the user to handle

information overload. The very positive conclusion made by Fages et al. (dis-

cussed in Chapter 2.4.4) regarding the 3D view’s usefulness to showcase domain

propagation is in line with the results obtained in Chapter 5.4 and can be gen-

erally strongly underlined.

The search tree view was mostly implemented as by Carro et al. and Bracchi et

al. described (discussed in Chapters 2.4.1 and 2.4.2). Each node represents the

execution of a predicate, or an attempt by the system, to ground a variable. Also,

each node depicted in the search tree can be collapsed. The view was further

improved by the time wind feature. The combination of both provide means to

6 Discussion 55

handle information overload as well as the selective display of data for better

oversight.

Contrary to the in Chapter 2.4.2 reviewed OPL Studio, the search tree incorpo-

rates the information of the so-called choice stack into the main view itself.

This is done in a condensed manner, by marking each node depict the ground

values only (essentially abstracting the choice stack). This allows to obtain a

notion of the program’s execution at first glance, without opening a second

view. More detailed information can be acquired by hovering over a node. While

this provides for a more useful and intuitive view, it may prove to be problem-

atic for visualizing programs with many variables. This is subject to further in-

vestigation.

Annotations proved to be very useful. Their handling was found to be mostly in

line with the evaluation given by Fages et al. (discussed in Chapter 2.4.4). How-

ever, the manual annotation of a larger program may become a very tedious

process. This may be alleviated by providing an option to automatically anno-

tate a given program in future iterations of the tracer. This could be done, for

example, by utilizing Prolog’s goal expansion feature.113 The question remains,

however, whether an automatic annotation may result in a valuable visualiza-

tion. Especially for larger programs, for which this problem occurs specifically,

it may be useful or even mandatory to selectively visualize certain parts of the

program, since the visualization of the entire program could lead to an incom-

prehensible amount of data.

Contrary to the implementation in CLPGUI, where variables given to an anno-

tation predicate are assigned default names when no names are given (dis-

cussed in Chapter 2.4.4), variable names, in this implementation, must be ex-

plicitly announced upon their first encounter. While this prevents unexpected

variables to show up in the visualization accidentally, it makes the process more

tedious. It can become a difficult process to understand which variables have

already been assigned names and which have yet to be announced to the tracer.

However, if a user lacks this insight, the question remains whether they will

attain much value from the visualization of such variables in the first place.

113 Wielemaker 2017, 93–94.

6 Discussion 56

Furthermore, with predicates such as owl_gen_names and

owl_names_from_term, as discussed in Chapter 2.4.1, the tracer provides

predicates to ease the inconvenience while still maintaining the benefits of the

imposed explicity. Experience collected so far from annotating different CSP

programs has shown that the advantages outweigh the disadvantages. However,

this implementation may become a significant problem when annotating larger

programs and is subject to further investigation.

Chapter 5.3 shortly described how the GUI could be used for applications other

than education. However, this is subject to further exploration. The scope of the

thesis was intentionally limited to educational applications. Future work may

be directed towards these fields and the visualization of real-world size prob-

lems. In addition to the problems already mentioned, a further obstacle that

might be encountered when advancing in this direction may be found in the

implementation of the tracer and how it internally handles the collected trace.

As discussed in Chapter 2.4.1, the tracer temporarily saves all the data to the

Prolog database. This may result in a performance overhead if too much data is

collected and temporarily saved. This process could potentially be avoided en-

tirely by, for example, abandoning the temporary storage. Every piece of data

could be communicated as soon as it is collected. This, however, is subject to

future work.

7 Conclusion 57

7 Conclusion

In Chapter 1, a general introduction to the contents of this thesis was given,

and the goal of developing a GUI to visualize SWI-Prolog CLP(FD) programs for

educational use was stated. By reviewing relevant literature, Chapter 2 laid out

the theoretical foundation necessary for the works of this thesis and examined

some of the related work in the field of CLP visualization. This informed the in

Chapter 3 for the system defined requirements. Chapter 4 gave a detailed ex-

planation of how the application was implemented and Chapter 5 showed and

discussed first findings obtained by using the implemented GUI practically.

Lastly, Chapter 6 discussed said findings in relation to the GUI’s targeted field

of education and pointed towards possible future work.

The initially stated aim of the thesis was achieved by presenting, to the author’s

knowledge, the first GUI capable of visualizing SWI-Prolog CLP(FD) programs:

The Owl Inspector. The GUI’s practicality for educational applications was suc-

cessfully shown in Chapter 5. The GUI was able to visualize and help compre-

hend the execution of different CLP programs and the CLP system in general.

While the implemented visualizations were mostly based on the reviewed liter-

ature, they present some additions like the time wind feature and an augmented

search tree view. Furthermore, every visualization and the GUI in general, show

a clear advancement regarding aesthetics and the usability of the software. The

GUI also presents, to the best of the author’s knowledge, the first web-based

solution for CLP visualizations, which allows any device capable of running a

browser the execution of the GUI. While the GUI shows much potential for ed-

ucational applications, it is worth to note its limitations. The GUI has yet to be

tested visualizing real-world size problems. Some of the limitations that might

be encountered were raised in Chapter 6. The GUI also lacks any presentation

of real-time benchmarks necessary for performance debugging. While Chapter

5.3.2 briefly discussed the GUI’s potential to help debug programs that fail to

obtain a solution, the GUI has yet to be tested in those fields. Future work may

be directed towards addressing these issues and advancing the GUI towards ap-

plications other than education.

Acknowledgments 58

Acknowledgments

To the many whiteboard scribblings in professor Oliver Eck’s office. To

the many hours discussing this very work with him. To the many ques-

tions emailed to François Fages. To my extraordinary proofreaders. To

the beautiful Owl Inspector logo designed by Masha Kornienko. And,

to the many coffees served at coffee shops throughout town.

Thank you.

References 59

References

Aggoun, A, F Bueno, M Carro, M Fabris, W Drabent, G Ferrand, M Hermenegildo, et al. 1997. CP Debugging Needs and Tools.

Apt, Krzysztof R. 2003. Principles of Constraint Programming.

Backofen, Rolf, and David Gilbert. 2006. Bioinformatics and Constraints. In Foundations of Artificial Intelligence, 2:905–944. Vol. 2. Elsevier. Availa-ble at <http://linkinghub.elsevier.com/re-trieve/pii/S1574652606800301>. Accessed 6 July 2018.

Bracchi, Christiane, Christophe Gefflot, and Frederic Paulin. 2001. Combining Propagation Information and Search Tree Visualization using ILOG OPL Studio. Proceedings of WLPE01: 27–39.

Carro, Manuel, L. Gómez, M. Hermenegildo, and Facultad De Informática. 1993. Some Paradigms for Visualizing Parallel Execution of Logic Programs. In In 1993 International Conference on Logic Programming, 184–201. MIT Press.

Carro, Manuel, and Manuel Hermenegildo. 2000a. Tools for Constraint Visual-isation: The VIFID/TRIFID Tool. In Analysis and Visualization Tools for Constraint Programming, edited by Pierre Deransart, Manuel V. Herme-negildo, and Jan Małuszynski, 1870:253–272. Vol. 1870. Berlin, Heidel-berg: Springer Berlin Heidelberg. Available at <http://link.springer.com/10.1007/10722311_11>. Accessed 6 July 2018.

Carro, Manuel, and Manuel Hermenegildo. 2000b. Tools for Search-Tree Visu-alisation: The APT Tool. In Analysis and Visualization Tools for Constraint Programming, edited by Pierre Deransart, Manuel V. Hermenegildo, and Jan Małuszynski, 1870:237–252. Vol. 1870. Berlin, Heidelberg: Springer Berlin Heidelberg. Available at <http://link.springer.com/10.1007/10722311_10>. Accessed 6 July 2018.

Carro, Manuel, J. M. Ramos, J. M. Ramos, and M. Carro. 1998. VIFID User’s Man-ual. Technical Report. Technical University of Madrid.

Cohen, Jacques. 2004. A Tribute to Alain Colmerauer. arXiv:cs/0402058. Avail-able at <http://arxiv.org/abs/cs/0402058>. Accessed 6 July 2018.

Colmerauer, Alain. 1990. An Introduction to Prolog III. In Computational Logic: Symposium Proceedings, Brussels, November 13/14, 1990.

Colmerauer, Alain, and Philippe Roussel. 1996. The Birth of Prolog. History of programming languages—II.

Erbas, Cengiz, Seyed Sarkeshik, and Murat M. Tanik. 1992. Different Perspec-tives of the N-Queens Problem. In Proceedings of the 1992 ACM Annual

References 60

Conference on Communications, 99–108. CSC ’92. New York, NY, USA: ACM. Available at <http://doi.acm.org/10.1145/131214.131227>.

Fages, Francois, Sylvain Soliman, and Remi Coolen. 2004. CLPGUI: A generic graphical user interface for constraint logic programming. Constraints 9 (4): 241.

Gavanelli, Marco, and Francesca Rossi. 2010. Constraint Logic Programming. A 25-year perspective on logic programming 6125: 64–86.

Hickson, Ian. 2012. The WebSocket API. Available at <https://www.w3.org/TR/2012/CR-websockets-20120920/>. Accessed 7 July 2018.

Jaffar, Joxan, and Jean-louis Lassez. 1987. Constraint Logic Programming. POPL ’87 Proceedings of the 14th ACM SIGACT-SIGPLAN symposium on Princi-ples of programming languages.

Ogborn, Anne. n.d. CLP(FD) Constraint Logic Programming over Finite Do-mains. Available at <http://www.pathwayslms.com/swipl-tuts/clpfd/clpfd.html#_all_different_list>. Accessed 9 July 2018.

Stuart, J. R., and N. Peter. 2003. Artificial Intelligence a Modern Approach.

Triska, Markus. 2013. Correctness Considerations in CLP(FD) Systems Disser-tation.

Wallace, Mark. 1996. Practical applications of constraint programming. Con-straints 1 (1–2): 139–168.

Wielemaker, J., L. De Koninck, T. Fruehwirth, M. Triska, and M. Uneson. 2014. SWI Prolog Reference Manual 7.1. Books on Demand. Available at <https://books.google.nl/books?id=eDvdAwAAQBAJ>.

Wielemaker, Jan. 2017. SWI Prolog Reference Manual 7.6.

Wielemaker, Jan. n.d. SWI-Prolog -- Manual: Supporting JSON. Available at <http://www.swi-prolog.org/pldoc/man?section=jsonsupport>. Ac-cessed 9 July 2018.

Wielemaker, Jan, Tom Schrijvers, Markus Triska, and Torbjörn Lager. 2012. SWI-Prolog. Theory and Practice of Logic Programming 12 (1–2): 67–96.

N.d. ECharts Documentation. Available at <https://ecomfe.github.io/echarts-doc/public/en/tutorial.html#Get%20Started%20with%20EC-harts%20in%205%20minutes>. Accessed 9 July 2018.

N.d. Getting Started - React. Available at <https://reactjs.org/docs/getting-started.html>. Accessed 9 July 2018.

N.d. gulp.js. Available at <https://gulpjs.com/>. Accessed 9 July 2018.

N.d. Introducing JSX - React. Available at <https://reactjs.org/docs/introduc-ing-jsx.html>. Accessed 9 July 2018.

References 61

N.d. npm Documentation. Available at <https://docs.npmjs.com/>. Accessed 9 July 2018.

N.d. Sass: Syntactically Awesome Style Sheets. Available at <https://sass-lang.com/>. Accessed 9 July 2018.

N.d. Sierra: The smallest and lightest SCSS library. Available at <http://sierra-library.github.io/>. Accessed 9 July 2018.

N.d. State and Lifecycle - React. Available at <https://reactjs.org/docs/state-and-lifecycle.html>. Accessed 9 July 2018.

N.d. Thinking in React - React. Available at <https://reactjs.org/docs/thinking-in-react.html>. Accessed 9 July 2018.

2018. TIOBE Index | TIOBE - The Software Quality Company. Available at <https://www.tiobe.com/tiobe-index/>. Accessed 6 July 2018.

possibilities of visualizing the solution process of ... · the best of the author’s knowledge,...

Documents