Re: CLP(FD) team for the ASP solver competition

LudovicoVan <julio@xxxxxxxxxxxxx> writes:
On 18 Feb, 21:31, ulr...@xxxxxxxxxxxxxxxxxxxxxxxxxx (Ulrich Neumerkel)
wrote:
bart demoen <b...@xxxxxxxxxxxxxx> writes:
And why is throwing an exception to a catcher (which is somewhere you
have no idea about) more safe than failing (and backtracking to a place
you have no clue about) ?

Failure in a pure program means: No solution. Many programs search
for counterexamples. Here, failure means effectively: Proof established.

IMHO you approach risks to be far from the substance of concrete
software development.

It is in such a context that silent failure would be desastrous.

There is nothing disastrous if the specification correctly models the
given requirements. It's just doing what it is supposed to do.
....
What I mean is that there is nothing correct or incorrect "a priory"

First, in the context of that post, I referred to a specific type of
pure programs, explained in an other posting soon thereafter.

So let me respond in a more general manner. Every programming
language has its specific conventions that developed with the use of
the language. Part of them is folklore, personal style, and part of
it is caused by the inherent properties of a language - your a priori.
From the outside, it is often difficult to distinguish between those.
You might get rid of folklore, or develop some other style, but
questioning Prolog's inherent properties will cause you a lot of extra
attention and work. You can specify whatever procedural behaviour you
want, (like failure, when S is a variable), - and sometimes there is
no way around - but you will pay for that:

You will have to remember exactly what you wanted, you will have to
figure out how that predicate is called exactly. Otherwise trivial
changes in the program will have an effect. You will not be able to
rely on many nice properties of the program. Testing will be more
difficult. For others it will be hard to figure out, how to use it.
"Others" includes you in some weeks, when memory fades.

When you go with the language (after you understood it), things are
easier. Let's look at your example. Your question was why Markus
recommended to remove integer(S). Consider integer/1 commented out:

:- use_module(library(clpfd)).

all_sums(S, A, B, C) :-
% integer(S),
chain([0,A,B,C,S], #<),
A mod 2 #= 1,
B mod 2 #= 1,
C mod 2 #= 1,
A + B + C #= S.

Or better:

Let us *not* look at it, but simply use it! How can you use a
predicate without knowing what it is about? Just leave all arguments
as free variables (most general goal) and see what you get.

?- all_sums(S, A, B, C).
S in 9..sup, -1*S+A+B+C#=0, C#=<S+ -1,
A in 1..sup, A#=<B+ -1, A mod 2#=1,
B in 3..sup, B#=<C+ -1, B mod 2#=1,
C in 5..sup, C mod 2#=1.

This answer tells us a lot - in fact everything about the relation.
See the . at the end? That means: there is only this answer and the
predicate terminates.

The answer describes the actual solutions, some integer-values for the
variables. How many is not clear to us (unless you can solve all
equations just by looking at them). But some things we can see
immediately:

See the S in 9..sup? That means: S must be 9 or greater. It cannot
be less, otherwise Prolog will answer false. I guess you did not know
that - well, I didn't.

Then there are constraints (in the order of the variables appearing in
the query). Here, you could understand everything, but in general
this will be too complex.

What is striking, is that all intervals end with sup (supremum). This
suggests, that there might be infinitely many solutions. Might be!
For, the constraints may not hold, or may effectively have only
finitely many solutions.

Maybe we try to find a solution. From the answer above we knew that
all variables are positive. clpfd only offers to enumerate finitely
many values - to guarantee termination for all library predicates. To
enumerate them, we have to constrain them arbitrarily.

?- Zs = [S,A,B,C], Zs ins 0..100000, all_sums(S, A, B, C), labeling([], Zs).
Zs = [9, 1, 3, 5],
S = 9,
A = 1,
B = 3,
C = 5

(Thats only the first solution)

Is it possible that the first and second argument are equal (somehow,
maybe with a very big number)?

?- S #= A, all_sums(S, A, B, C).
false.

Never.

Is it possible that S is smaller than A?

?- S #< A, all_sums(S, A, B, C).
S in 19..sup, -1*S+A+B+C#=0, C#=<S+ -1, S#=<A+ -1,
A in 20..sup, A#=<B+ -1, A mod 2#=1,
B in 7..sup, B#=<C+ -1, B mod 2#=1,
C in 7..sup, C mod 2#=1.

So the systems says, yes provided all these equations hold. How could
we solve that? In general, that is impossible (in fact: undecidable,
welcome to Z!). But here, our solver is too weak. Try it with a
concrete interval and labeling. That's no proof - of course.

Now consider your original version. It would have said false to all
those queries. From the Prolog point of view, it would have said "no
solution". Of course you could say - that's what I specified! But
believe me, you will forget that. So the spec will effectively
vanish. And what remains is code that behaves erratically. Worse:
Sometimes the predicate pretends to be a relation:

?- all_sums(9, A, B, C).
A = 1,
B = 3,
C = 5.

And some time later, when you try to generalize things...

?- S in 8..100, all_sums(S, A, B, C).
false.

If you really want to insist, that S is known, you can use
must_be(nonvar,S) - or must_be(integer,S). In that case, the system
would alarm you in those situations, instead of telling you a wrong
answer.



What makes things even more complex is that Prolog consists
effectively of several language layers. The highest is the level we
have used now. Those below are needed as well, but they do not share
the same properties. integer/1 was a good example. Some levels below
integer/1 you cannot even play with them easily.

But playing as above helps develop the intuition you need for bigger
programs. There, the answers are that large that you cannot read
them, but you can be sure that you can reason about them much as
above.

There are many other properties you can rely on in that pure monotonic
part of Prolog. But let's stop here, lest I will not keep my promise.
.

Relevant Pages

  • Re: If you were developing a database in Forth...
    ... database that worked well, and then Dennis Ruffer provided source code ... to do the same thing in some other language and it failed it was ... It doesn't matter if the project was a stunning success or a ... that failure was the language we invented. ...
    (comp.lang.forth)
  • Re: How much intelligence?
    ... operations needed for the processing of logical statements with truth values. ... the drawbacks of natural language for discussing the nature of truth. ... tautological mechanics and I see a lot of confusion using established ... predicate or a truth value, the and'ing of them doesn't produce a predicate ...
    (comp.ai.philosophy)
  • Re: Scott and Georges Teaching Thread
    ... Please think of this as a programming language. ... predicate in this language is e. ... The axioms jointly CLARIFY AND EXPLAIN ... Some of these logical primitives are from 0th-order logic; ...
    (sci.logic)
  • Re: Error/Beep/Blink codes
    ... the digits needs about 10 seconds of recording time, ... course the language selection DIP switches/flash may also fail ..... ... In practice, if the system suffers a catastrophic failure, the most ... If the inverter for the CCFL's fails, the display is rendered ...
    (comp.arch.embedded)
  • Re: relative complement?
    ... If the designer fails to capture information in database design, if information is hidden from the user, or if the user incompetently fails to express their intent [Ed. ... Or if the data language is not sufficiently expressive], it will certainly produce seemingly anomalous or "surprising" results when faced with these problems. ... My reason is the assumption that at any all times, all the relations recorded by an rdbms must have predicates and implications of those predicates that aren't contradictory. ... Personally, if I were designing a language, I think I would have to state that B's predicate is indeterminate. ...
    (comp.databases.theory)