Somehow I've got to get us all thinking more along
the lines of logic programming. I say "all" because I have to
make the journey myself.
I'd like to return to the spiders and beetles example from
Trilogy. Here we have this box of spiders and beetles and a
count of the legs therein. The problem lies in determining
how many of each are in the box.
As spiders have 8 legs and beetles 6, if we let 'S' represent
the spiders and 'B' the beetles and 'L' the number of legs we
have the following equation: 8S + 6B = L. Now we can have a
"normalized" form of this equation by putting all the variables
on the righthand side, equating the result to 0:
0 = L - (8S + 6B). Now obviously (I say) if we have 6 legs in
the box, it contains 1 beetle; 8 legs, 1 spider; 12 legs, 2
beetles; 14 legs, 1 spider, 1 beetle; and so on.
Now what happens if we have 46 legs? Well, we know that
we have some mix of spiders and beetles as neither 6 nor 8
divide 46 evenly. It is also possible that no combination of
spiders and beetles can add up to 46: the assertion, i.e.
equation, is 'false'. It is also possible that multiple
combinations of beetles and spiders could exist: 1 or more true
instances. Once again to handle the possibility of 0, 1, or more
instances we have a list result.
So let's express the problem in program terms.
dcl a list;
dcl (S, B, L) fixed bin (15);
L = 46;
a[B,S] = L - ((8*S) + (6*B));
It results in two "tuples": [1,5] and [5,2]. To see this I offer
the following matrix:
# B S
1 6 8
2 12 16
3 18 24
4 24 32
5 30 40
6 36
7 42
You can see from this that the combination of 5 beetles (30)
and 2 spiders (16) or 1 beetle (6) and 5 spiders (40) provide a
true instance.
We could have cleverly written the program to do this for us:
dcl (i1, i2, i3, i4, L, B, S) fixed bin (15);
dcl A list fifo;
L = 46; /* number of legs in box */
i1 = L/6; /* max num of beetles possible */
i2 = L/8; /* max num of spiders possible */
do i3 = 1 to i1;
do i4 = 1 to i2;
if L = (6*i3) + (8*i4)
then insert [i3, i4] in A;
end;
end;
Now what we have just done is solve a 3 variable equation
with two unknowns (S and B) and 1 known (L) by writing a
program. Consider the following possibility. We could have an
equation with 0 unknowns by assigning values to L, B, and S
prior to evaluating the expression. We could have the same
equation with 1 unknown (L, B, or S), with 2 unknowns ([L,B],
[B,S], [L,S]), or with 3 unknowns ([L,B,S]).
Suppose we do the following:
dcl (L, B, S) fixed bin (15);
dcl A list;
L, B, S = 1...100; /* variables can assume values ranging from
1 to 100 */
A[L,B,S] = L - ((6*B) + (8*S));
This would produce tuples of [L, B, S] for all true instances of
the assertion. Note that solving for 0, 1, 2 and 3 unknowns
uses the same righthand side throughout. The lefthand side
provides the context for the variables of interest and their
true instances. You are welcomed to write all the algorithms
for all the combinations of unknowns as well as the select
clause (case statement) for deciding among them based on
the different pre-conditions affecting the variables.
The statement ' L, B, S = 1...100;' provides a means of having
the software automatically enumerate the set of all possible
combinations of values of the variables. We could have
specified a mixture of set values as well as value ranges, e.g.
'L = [1...100, 200, -20];'. This amounts to directing the
software for the values of concern.
The next step up from this in interpretive mode lies in marking
a section of the source code, having the interpreter show the
different variables whose values it needs, and then submitting
a list of values for each one containing known false as well as
true instances. The software will then enumerate the
different sets of values, substituting them in turn in evaluating
the source, and producing a list of true instances.
In point of practice this amounts to automated test data
generation as well as automated testing (the exhaustive
true/false proof stage of logic programming). We have this
relatively simple method to perform an exhaustive test of any
program or any section of a program.
This basically eliminates the need for alpha and beta releases
as well as alpha and beta testing or testers. The software
may not know what values you want included in the test.
You have to write them. However, once written the software
does the rest.
This follows the guidelines of "let people do what software
cannot and software what people need not".
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
<< Previous Message <<
Return to [ 31 |
October |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
