Return-Path: <@CUNYVM.CUNY.EDU:LOJBAN@CUVMB.BITNET> Received: from kantti.helsinki.fi by xiron.pc.helsinki.fi with smtp (Linux Smail3.1.28.1 #1) id m0suyz6-0000ZOC; Tue, 19 Sep 95 12:29 EET DST Received: from fiport.funet.fi (fiport.funet.fi [128.214.109.150]) by kantti.helsinki.fi (8.6.12+Emil1.1/8.6.5) with ESMTP id MAA09753 for ; Tue, 19 Sep 1995 12:28:58 +0300 Received: from CUNYVM.CUNY.EDU (MAILER@CUNYVMV2) by FIPORT.FUNET.FI (PMDF V5.0-3 #2494) id <01HVGL0C249S000NRY@FIPORT.FUNET.FI> for veion@XIRON.PC.HELSINKI.FI; Tue, 19 Sep 1995 12:29:56 +0200 (EET) Received: from CUNYVM.CUNY.EDU (NJE origin LISTSERV@CUNYVM) by CUNYVM.CUNY.EDU (LMail V1.2a/1.8a) with BSMTP id 6972; Tue, 19 Sep 1995 05:28:31 -0400 Date: Tue, 19 Sep 1995 02:24:34 -0700 From: Gerald Koenig Subject: Re: algorithms Sender: Lojban list To: Veijo Vilva Reply-to: Gerald Koenig Message-id: <01HVGL0C3MWI000NRY@FIPORT.FUNET.FI> Content-transfer-encoding: 7BIT X-To: lojban@cuvmb.cc.columbia.edu MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Length: 3949 Lines: 117 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 >