From pycyn@aol.com Sat Mar 09 13:15:16 2002 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: unknown); 9 Mar 2002 21:15:15 -0000 Received: (qmail 33795 invoked from network); 9 Mar 2002 21:15:15 -0000 Received: from unknown (216.115.97.167) by m8.grp.snv.yahoo.com with QMQP; 9 Mar 2002 21:15:15 -0000 Received: from unknown (HELO imo-m04.mx.aol.com) (64.12.136.7) by mta1.grp.snv.yahoo.com with SMTP; 9 Mar 2002 21:15:15 -0000 Received: from Pycyn@aol.com by imo-m04.mx.aol.com (mail_out_v32.5.) id r.176.4c5f9ea (4469) for ; Sat, 9 Mar 2002 16:15:08 -0500 (EST) Message-ID: <176.4c5f9ea.29bbd55c@aol.com> Date: Sat, 9 Mar 2002 16:15:08 EST Subject: Re: [lojban] Re: Quantifiers, Esistential Import, etc. To: lojban@yahoogroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_176.4c5f9ea.29bbd55c_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_176.4c5f9ea.29bbd55c_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 3/9/2002 12:49:42 PM Central Standard Time, jjllambias@hotmail.com writes: > This does have regularity, but it makes transformations > complicated. For example, {naku ro broda} goes to > {su'o da poi broda naku} instead of just {su'o broda naku}, > and so on. > Sure, because the denial of an importing quantifier is a free one (but you don't need the {su'o} in the second). This is a regular feature of all the DeMorgan's in this system -- with the convenience that you can tell at a glance whether an expression is importing or not ({lo broda} v. {da poi}) I have complained about that passage -- and a couple of others of the same sort -- since before the book came out. With my usual success, of course (obviously). It's bad logic and worse Lojban. Unless, of course, it were taken to mean that {da poi} was also +, which it clearly is not in other places and certainly in common practice. Does mine miss any (in content, form is screwed up a bit here)? Yes, I have had to fiddle a bit with the meaning of {da poi} -- a meaning that was not very clearly worked out anyhow, as witness your example on 399 in contrast with several other cases. I admit that, when I started this, I had hopes of keeping {da poi} on the + side and making all the - go over to {ganai gi}, but a bit of water-testing assured me this would never fly -- in spite of 399 and the other places. I would be more than happy to go to that system if I thought I could get away with it among the users. The present one is a compromise keeping as much as makes good use of the usual material without doing too much damage to bad habits people (including Central) have picked up. --part1_176.4c5f9ea.29bbd55c_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 3/9/2002 12:49:42 PM Central Standard Time, jjllambias@hotmail.com writes:


This does have regularity, but it makes transformations
complicated. For example, {naku ro broda} goes to
{su'o da poi broda naku} instead of just {su'o broda naku},
and so on.


Sure, because the denial of an importing quantifier is a free one (but you don't need the {su'o} in the second).  This is a regular feature of all the DeMorgan's in this system -- with the convenience that you can tell at a glance whether an expression is importing or not ({lo broda} v. {da poi})

<The Book has {ro da poi broda cu brode} for A+ (pg 399), which
goes against both our systems>

I have complained about that passage -- and a couple of others of the same sort -- since before the book came out.  With my usual success, of course (obviously).  It's bad logic and worse Lojban.  Unless, of course, it were taken to mean that {da poi} was also +, which it clearly is not in other places and certainly in common practice.

<it allows all the transformations
that my system allows (section starting on page 405).>

Does mine miss any (in content, form is screwed up a bit here)?

<It also says
explicitly that {su'o da poi verba naku klama su'o de poi ckule}
is identical in meaning to {su'o verba naku klama su'o ckule},
which is what my system allows, but not yours.>

Yes, I have had to fiddle a bit with the meaning of {da poi} -- a meaning that was not very clearly worked out anyhow, as witness your example on 399 in contrast with several other cases.  I admit that, when I started this, I had hopes of keeping {da poi} on the + side and making all the - go over to {ganai gi}, but a bit of water-testing assured me this would never fly -- in spite of 399 and the other places. I would be more than happy to go to that system if I thought I could get away with it among the users.  The present one is a compromise keeping as much as makes good use of the usual material without doing too much damage to bad habits people (including Central) have picked up.

--part1_176.4c5f9ea.29bbd55c_boundary--