Re: algorithms

[Gerald Koenig <jlk@NETCOM.COM>]

la stivn pa cusku

>Actually, there is something I've been wondering about, which perhaps has
>some bearing on the existential import issue, and also (perhaps) on the
>issue of the much belabored 3 men who pet 3 dogs.
>
>How are algorithms expressed in lojban? Of course, one could just describe
>them, but the concepts seem a little rich for the syntax of mathematical
>expression.
>It would be interesting if one could say:
>
>man=Array[mana, manb, manc]
>dog=Array[doga, dogb, dogc]
>For i taking values from one to three
> For j taking values from one to three
>  man[i] pets dog[j]
> End For
>End For
>
(deletions)

>
>There are several languages which might provide lots of fermentive ideas:
>APL, for example, or its modern progeny J Both languages from Ken Iverson.
>Mathematica by Steven Wolfram a very rich language.
>
>I believe that handling of problems involving statements about the dogs and
>men might benefit from some algorithmic thinking. By the way, the example
>algorithmic expression was chosen for clarity of expressing the idea. There
>are some powerful operaters in J and Mathematica which would handle these
>types of expressions with elegant precision and compactness.
>
>Any ideas?

djer:  I believed that the last, prenex form, for 3 men and 3 dogs that
I posted really was already an algorithm. Not one that could be put
directly into a computer, but I think it fit the common meaning of a
recipe to accomplish an action.  It is an interesting question you
raise about the relation of a spoken language to a computer language. I
think lojban has the best chance of keeping a close correspondence
between the two. Although too much compactness in the mathematical way
of abstraction can be a bar to understanding, in my view.  Of course
when we program a computer we are forced to be precise because the
computer will not forgive us for inaccuracy and substitute something
plausible. Not yet, anyway.

As far as I know, Prolog is the language that is closest to lojban
because they are both derivitives of predicate calculus. It is
interesting to me that they are suffering analogous growth problems.
The absence of quantifiers in Prolog has led to extensions, such as
LnProlog, which adds the universal and existential quantifiers and two
forms of negation. Quantifiers and negation have been problem areas for
the growth of lojban, as we all know.  I wonder what Prolog will look
like ten years from now.

As a result of your post I programmed the instant problem in prolog with
the following result: (actually 4 entities instead of 3)

touchers(U,V):-

        member(U,[djer,xorxes,stivn,pc]),
        member(V,[falla,daphne,medusa,lassie]).

        member(X,[X|_]).
        member(X,[_|Y_tail]):- member(X,Y_tail).


Here is the output:

djer--falla
djer--daphne
djer--medusa
djer--lassie
xorxes--falla
xorxes--daphne
xorxes--medusa
xorxes--lassie
stivn--falla
stivn--daphne
stivn--medusa
stivn--lassie
pc--falla
pc--daphne
pc--medusa
pc--lassie

This program treats the set of men or dogs as a list, but this is not a
necessity as Prolog has set operators such as bag_of as well. I think
most of your examples could be programmed quite succintly. But after
doing this I don't feel that there is a gain in simplicity of concept,
or really much increased clarity. Underlying the simple looking member
predicate is a lot of complicated mechanism. The main gain to my mind is
the ability to do huge lists with the same effort as a small example.

This example is the all,all case and is natural to current Prolog. The
some, all etc. cases would require an advanced Prolog, or maybe much
more sophisticated programming than I can do.

Thanks for your interesting post.

djer




>-stivn
>
>
>Steven M. Belknap, M.D.
>Assistant Professor of Clinical Pharmacology and Medicine
>University of Illinois College of Medicine at Peoria
>
>email: sbelknap@uic.edu
>Voice: 309/671-3403
>Fax:   309/671-8413
>