One core question in modelling a problem is "what are the relevant variables?"

"Consider a traveller somewhere in the tropical rain forest of northern Australia. She wishes to paddle across a fast flowing river in an inflatable boat. It is important to cross the river as quickly as possible since it is full of crocodiles. There is a single small clearing on the other side of the river at which she must land. Where should she set off from her side of the river in order to reach the clearing in the least time?"

We simplify the problem by assuming (correctly) that the fastest way across is to head directly across the river, and allow the current to carry the boat downstream

So the relevant variables are the width W and speed S of the river, the rowing speed R, and the distance upstream P from which the boat should be launched

Finally, to relate the crossing and downstream distances, we will need a variable T to represent the time taken (but this variable need not be visible to the outside World

Thus the rule will be

Assuming a river 24m wide flowing at 1m/s, and a rowing speed of 1.5m/s we would run the query

To get the answer

Conversely, suppose our traveller cannot set off any more than 20m upstream, and her rowing speed is between 1 and 1.3 m/s. Can she make it?

And the answer…

Perhaps we'll have to think further about this… (see exercise P5.1)

A second core issue in modelling is "what relationships do we need to represent?"

The following might represent the basic data about a particular family:

We can construct more complex relationships using rules:

We can check if Peter has any cousins:

or whether Fi has any older cousins:

A call option gives the holder the right to buy a fixed number of shares for a fixed price, the exercise price, prior to the (fixed) expiry date

A put option gives the holder the right to sell a fixed number of shares for a fixed price, the exercise price, prior to the (fixed) expiry date

Since you have the choice of whether to exercise an option (and presumably will not exercise it if it is cheaper not to), buying options in effect limits the total exposure:

We may choose to model options trading via the parameters C (cost of option), E (exercise price), S (share price), P (total payoff) (we assume all options contracts are in units of 100 shares)

Buying a call option could be modelled by the rules:

We would then need to write a separate set of rules for selling call options; it is simpler to introduce a parameter B to distinguish between buying and selling:

The butterfly is a more complex combination of put and call options which has the effect of yielding a payoff within a narrow range, but has a guaranteed maximum loss outside that range

So far, we have just looked at finding solutions to constraints

Often, we would like to find a best (eg minimal) solution to a set of constraints

There is no standard way of doing this within CLP systems; Marriott and Stuckey use the syntax

for a predicate which will find the solutions to G which give the smallest value of E

For example,

would find the maximum payoff and corresponding share price for the butterfly described in the text (S = 3, P = 100)

would find the maximum loss and corresponding share price for the same butterfly (S <= 1 or S >= 5, P = -100)

Note that there is no built-in minimize construct for CLP(R), and SICStus and ECLiPSe have them only for finite domains

So far, our modelling problems have depended only on simply structured data

There are many problems for which this is not enough

The steady-state temperature at each point in a steel plate is just the mean of its orthogonal neighbouring points:

T22 = (T12 + T21 + T23 + T32) / 4

T23 = (T13 + T22 + T24 + T33) / 4

This approach is feasible for a small grid, but for a larger mesh would be impossibly tedious and error-prone to express

The simplest data structuring approach in CLP languages is to wrap a number of items together in a term (we've already seen examples of this)

For example, we could represent the imaginary number a + ib as c(a,b)

We could then, for example, define addition and multiplication of complex numbers:

In dealing with imaginary numbers, we will often be interested in only the real part

To save having to invent names for variables in which we are not interested, CLP languages permit us to refer to c(R, _), where the "_" is effectively a notation for "any value"

This will be more important in larger and more complex data structures, where the burden of inventing irrelevant variable names would become impossibly burdensome

Lists are probably the most widely used CLP data structure

Their importance lies in their extensibility - we don't have to know ahead of time how long a list is (in particular, we can write constraints which deal with lists of arbitrary, or even indefinite, length)

Lists are represented with square brackets

represents the sequence of the first 10 positive integers

There is a special notation for the empty list

and another (this is the really important bit) for separating out the first element of a list from the rest:

The commonest use for lists is in recursive (ie almost circular) constraints

For example, what does it mean for two lists to combine together end to end to make a third?

Like most LP constraints, this can be run in directions which may not be obvious: