From pycyn@aol.com Tue Mar 19 13:13:54 2002 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: unknown); 19 Mar 2002 21:13:54 -0000 Received: (qmail 16419 invoked from network); 19 Mar 2002 20:23:18 -0000 Received: from unknown (66.218.66.218) by m8.grp.scd.yahoo.com with QMQP; 19 Mar 2002 20:23:18 -0000 Received: from unknown (HELO imo-r06.mx.aol.com) (152.163.225.102) by mta3.grp.scd.yahoo.com with SMTP; 19 Mar 2002 20:23:18 -0000 Received: from Pycyn@aol.com by imo-r06.mx.aol.com (mail_out_v32.5.) id 7.13.8549370 (4505) for ; Tue, 19 Mar 2002 15:20:41 -0500 (EST) Message-ID: <13.8549370.29c8f799@aol.com> Date: Tue, 19 Mar 2002 15:20:41 EST Subject: Re: [lojban] Logic course To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_13.8549370.29c8f799_boundary" X-Mailer: AOL 7.0 for Windows US sub 118 From: pycyn@aol.com X-Yahoo-Group-Post: member; u=2455001 X-Yahoo-Profile: kaliputra X-Yahoo-Message-Num: 13833 --part1_13.8549370.29c8f799_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 3/19/2002 12:50:31 PM Central Standard Time, jjllambias@hotmail.com writes: > I thought {du} was an infinite-place relationship. At least I'm > sure it says so somewhere. > (Yuck! ptui!) But so it does turn out to be. <>{li xy du me'o da pi'i >da} seems to work somewhat better (it still fails, but I am begining to >suspect that the parser doesn't do MEX any better than we do). The parser does MEX according to the rules. The problem is with the rules, not with the parser. I think it's {[li] xy du li me'o da pi'i me'o da}.> This is still not screwed up enough, i.e., the parser rejects both versions. <>1){roda de zo'u li da su'i de du li no} The not-quite-equivalence of sumti and operands can be quite annoying. {li da} is not grammatical. You could write it as: roda de zo'u li no sumji da de or, if you insist with MEX: roda de zo'u li mo'e da su'i mo'e de du li no> But the parser accepts this and gives it the right parse. I wonder what is different here from the previous case <>1'){roxy. zy. zo'u li xy su'i zy. du li no} mean ? {ro xy zy} is a single number. You need {roboi xyboi zyboi} in the prenex. Other than that, I think it works. (Though I prefer the {sumji} version.)> Both rejected, apparently {ro xy} is not recognized (though it should be as a case of "all the X's" even if not as a quantifier). The predicative forms all work, of course. --part1_13.8549370.29c8f799_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 3/19/2002 12:50:31 PM Central Standard Time, jjllambias@hotmail.com writes:


I thought {du} was an infinite-place relationship. At least I'm
sure it says so somewhere.


(Yuck! ptui!) But so it does turn out to be.

<>{li xy du me'o da pi'i
>da} seems to work somewhat better (it still fails, but I am begining to
>suspect that the parser doesn't do MEX any better than we do).

The parser does MEX according to the rules. The problem is
with the rules, not with the parser. I think it's
{[li] xy du li me'o da pi'i me'o da}.>

This is still not screwed up enough, i.e., the parser rejects both versions.

<>1){roda de zo'u li da su'i de du li no}

The not-quite-equivalence of sumti and operands can be quite
annoying. {li da} is not grammatical. You could write it as:

   roda de zo'u li no sumji da de

or, if you insist with MEX:

   roda de zo'u li mo'e da su'i mo'e de du li no>

But the parser accepts this and gives it the right parse.  I wonder what is different here from the previous case

<>1'){roxy. zy. zo'u li xy su'i zy. du li no} mean ?

{ro xy zy} is a single number. You need {roboi xyboi zyboi}
in the prenex. Other than that, I think it works. (Though
I prefer the {sumji} version.)>

Both rejected, apparently {ro xy} is not recognized (though it should be as a case of "all the X's" even if not as a quantifier).

The predicative forms all work, of course.





 --part1_13.8549370.29c8f799_boundary--