From pycyn@aol.com Tue Mar 19 19:53:24 2002 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: unknown); 20 Mar 2002 03:53:23 -0000 Received: (qmail 80596 invoked from network); 20 Mar 2002 03:53:23 -0000 Received: from unknown (66.218.66.216) by m5.grp.scd.yahoo.com with QMQP; 20 Mar 2002 03:53:23 -0000 Received: from unknown (HELO imo-d04.mx.aol.com) (205.188.157.36) by mta1.grp.scd.yahoo.com with SMTP; 20 Mar 2002 03:53:23 -0000 Received: from Pycyn@aol.com by imo-d04.mx.aol.com (mail_out_v32.5.) id 7.80.192771d9 (4069) for ; Tue, 19 Mar 2002 22:53:11 -0500 (EST) Message-ID: <80.192771d9.29c961a7@aol.com> Date: Tue, 19 Mar 2002 22:53:11 EST Subject: Re: [lojban] Logic course To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_80.192771d9.29c961a7_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 --part1_80.192771d9.29c961a7_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 3/19/2002 2:37:26 PM Central Standard Time, gordon.dyke@bluewin.ch writes: > > Apparently only {da, de, di} . {xy} and so on are anaphoric pronouns and > > will pick up other things. BUT in a clearly MEX environment, they > function > > as variables, for reading formulae. Question: How tell that this is a > > clearly MEX environment. I think it is, since there is a formula to > read: > < > > 1)AxEy(x + y = 0)> > > ??? > I couldn't agree more. MEX is a mess, more so the moe we have occasion to try to use it. Some day I will figure out what is meant by words like "operand" and so on. many of which have clear meanings that clearly do not fit the present cases (an old loglang problem -- autodidacts!) <{roda goi xy. de goi zy. zo'u li xy su'i zy du li no} {roda de zo'u li no sumji da de} these parse> I should hope so! Are the {li}s necessary? <{du} is a two-place argument, RefGramm 18;7> Yeah. I still don't like it, but I see its usefulness. <7.2) py. du xy.boi zy. ``p'' is-identical-to ``x'' ``z'' p = x = z I don't get why this is not li py du li xy du li zy> Well that would be ungrammatical, for all it is like math. The {du} after {xy} doesn't fit anywhere: {li xy} is the second argument of the first {du} and there is not end of sentence (or beginning of new sentence) mark after it. Since {du} has indefinitely many arguments, the whole string can be done at once -- more efficient than the math notation, though slightly less clear, perhaps <> 5){roda zo'u de zo'u li da du li de te'a re .inaja di zo'u li da du li di > pi'i vo}> > > An argument for forethought connectives, though I think this works out right. > And you could skip the internal preneces. how? (this is a question, not a challenge ;-)> {roda zo'u da du de te'a re .inaja da du di pi'i vo}, which doesn't work for other reasons, but has the quantified variables with scope over the chunks all right {da du de} works as well as {de zo'u da du de} for the same purpose. . <> But, perversely, {vo} needs a > {li}. only because the da should have taken one...> No, because here it stands for a number rather than enumerating something as a quantifier, as it would be taken to be without the {li}. <>. is there a better way to check comething parses than to write it into a file, open a ms dos prompt, cd jbofihe and jbofihe test.txt?> Well, I can never get jbofihe to work so I use the official parser, which I keep open in background, then just copy text, switch over to parser, and paste text (have to use the button, not ^V). xorxes: <>< 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. Typo: me'o -> mo'e (another reason why MEX sucks.)> This puts the whole thing in the wrong category (in any vaguely usual sense of "operand", whereas the {me'o} at least was said to give a sumti where one was required. But, it does give the right parse. <>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). {ro xy} should be a number, {roboi xy} should be "all x".> {ro xy} is refused altogether; {roboi xy} is accepted as something, Lord knows what. But {ro ko'a} is OK, as is {ro ri}. Apparently letterals are not pronouns in the same sense that {ko'a} and {ri} and {vo'a} are. --part1_80.192771d9.29c961a7_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 3/19/2002 2:37:26 PM Central Standard Time, gordon.dyke@bluewin.ch writes:


> Apparently only {da, de, di} .  {xy} and so on are anaphoric pronouns and
> will pick up other things.  BUT in a clearly MEX environment, they
function
> as variables, for reading formulae.  Question: How tell that this is a
> clearly MEX environment.  I think it is, since there is a formula to read:
<
> 1)AxEy(x + y = 0)>

???


I couldn't agree more.  MEX is a mess, more so the moe we have occasion to try to use it.  Some day I will figure out what is meant by words like "operand" and so on. many of which have clear meanings that clearly do not fit the present cases (an old loglang problem -- autodidacts!)

<{roda goi xy. de goi zy. zo'u li xy su'i zy du li no}
{roda de zo'u li no sumji da de}

these parse>
I should hope so!  Are the {li}s necessary?

<{du} is a two-place argument,

RefGramm 18;7>

Yeah.  I still don't like it, but I see its usefulness.

<7.2) py. du xy.boi zy.
``p'' is-identical-to ``x'' ``z''
p = x = z

I don't get why this is not li py du li xy du li zy>

Well that would be ungrammatical, for all it is like math. The {du} after {xy} doesn't fit anywhere: {li xy} is the second argument of the first {du} and there is not end of sentence (or beginning of new sentence) mark after it.  Since {du} has indefinitely many arguments, the whole string can be done at once -- more efficient than the math notation, though slightly less clear, perhaps

<> 5){roda zo'u de zo'u li da du li de te'a re .inaja di zo'u li da du li di
> pi'i vo}>
>
> An argument for forethought connectives, though I think this works out
right.
>  And you could skip the internal preneces.

how? (this is a question, not a challenge ;-)>

{roda zo'u   da du de te'a re .inaja  da du di
pi'i vo},  which doesn't work for other reasons, but has the quantified variables with scope over the chunks all right {da du de} works as well as {de zo'u da du de} for the same purpose.
.
<> But, perversely, {vo} needs a
> {li}.

only because the da should have taken one...>

No, because here it stands for a number rather than enumerating something as a quantifier, as it would be taken to be without the {li}.

<>. is there a better way to check comething parses than to write it into a
file, open a ms dos prompt, cd jbofihe and jbofihe test.txt?>

Well, I can never get jbofihe to work so I use the official parser, which I keep open in background, then just copy text, switch over to parser, and paste text (have to use the  button, not ^V).

xorxes:
<>< 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.

Typo: me'o -> mo'e (another reason why MEX sucks.)>

This puts the whole thing in the wrong category (in any vaguely usual sense of "operand", whereas the {me'o} at least was said to give a sumti where one was required.  But, it does give the right parse.

<>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).

{ro xy} should be a number, {roboi xy} should be "all x".>

{ro xy} is refused altogether; {roboi xy} is accepted as something, Lord knows what.
But {ro ko'a} is OK, as is {ro ri}.  Apparently letterals are not pronouns in the same sense that {ko'a} and {ri} and {vo'a} are.














--part1_80.192771d9.29c961a7_boundary--