From lojban-out@lojban.org Sun Sep 29 16:40:35 2002
Return-Path: <lojban-out@lojban.org>
X-Sender: lojban-out@lojban.org
X-Apparently-To: lojban@yahoogroups.com
Received: (EGP: mail-8_1_1_4); 29 Sep 2002 23:40:33 -0000
Received: (qmail 52088 invoked from network); 29 Sep 2002 23:40:33 -0000
Received: from unknown (66.218.66.216)
  by m9.grp.scd.yahoo.com with QMQP; 29 Sep 2002 23:40:33 -0000
Received: from unknown (HELO digitalkingdom.org) (204.152.186.175)
  by mta1.grp.scd.yahoo.com with SMTP; 29 Sep 2002 23:40:34 -0000
Received: from lojban-out by digitalkingdom.org with local (Exim 4.05)
  id 17vnii-0006gD-00
  for lojban@yahoogroups.com; Sun, 29 Sep 2002 16:43:28 -0700
Received: from digitalkingdom.org ([204.152.186.175] helo=chain)
  by digitalkingdom.org with esmtp (Exim 4.05)
  id 17vnhw-0006fi-00; Sun, 29 Sep 2002 16:42:40 -0700
Received: with ECARTIS (v1.0.0; list lojban-list); Sun, 29 Sep 2002 16:42:38 -0700 (PDT)
Received: from cs6668125-184.austin.rr.com ([66.68.125.184] ident=root)
  by digitalkingdom.org with esmtp (Exim 4.05)
  id 17vnhW-0006fY-00
  for lojban-list@lojban.org; Sun, 29 Sep 2002 16:42:14 -0700
Received: from cs6668125-184.austin.rr.com (asdf@localhost [127.0.0.1])
  by cs6668125-184.austin.rr.com (8.12.3/8.12.3) with ESMTP id g8TNkMGZ057389
  for <lojban-list@lojban.org>; Sun, 29 Sep 2002 18:46:22 -0500 (CDT)
  (envelope-from fracture@cs6668125-184.austin.rr.com)
Received: (from fracture@localhost)
  by cs6668125-184.austin.rr.com (8.12.3/8.12.3/Submit) id g8TNkHe7057388
  for lojban-list@lojban.org; Sun, 29 Sep 2002 18:46:17 -0500 (CDT)
Date: Sun, 29 Sep 2002 18:46:17 -0500
To: lojban-list@lojban.org
Subject: [lojban] Re: paroi ro mentu
Message-ID: <20020929234617.GA57203@allusion.net>
References: <F128dtMyW2hztblpaAK00009c83@hotmail.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv"
Content-Disposition: inline
In-Reply-To: <F128dtMyW2hztblpaAK00009c83@hotmail.com>
User-Agent: Mutt/1.4i
X-archive-position: 1741
X-ecartis-version: Ecartis v1.0.0
Sender: lojban-list-bounce@lojban.org
Errors-to: lojban-list-bounce@lojban.org
X-original-sender: fracture@allusion.net
Precedence: bulk
X-list: lojban-list
X-eGroups-From: Jordan DeLong <fracture@allusion.net>
From: Jordan DeLong <lojban-out@lojban.org>
Reply-To: fracture@allusion.net
X-Yahoo-Group-Post: member; u=116389790
X-Yahoo-Profile: lojban_out

--ZGiS0Q5IWpPtfppv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 29, 2002 at 08:58:19PM +0000, Jorge Llambias wrote:
> la djorden cusku di'e
> >First of all, what you're talking about here is totally different:
> >na behaves differently because it needs to export to the leftmost
> >end of the prenex (inverting any quantifiers) before being interpreted.
>=20
> I did not use {na}. I used {naku} both times, which exports in the
> order where it appears. {na} goes directly to the leftmost without
> inverting anything.

I was, of course, refering to naku.

> >Next, though, is that all of the above interpretations work provided
> >that ko'a and ko'e either can do quantifier inversion automatically
> >(which I think makes sense) or that in this case they were bound
> >to single items so inversion is a no op:
> > naku ko'a .e ko'e broda =3D=3D
> > naku zo'u ko'a .e ko'e broda =3D=3D
> > naku zo'u ge ko'a broda gi ko'e broda
> >It is false that: ko'a and ko'e broda.
>=20
> Correct so far.
>=20
> >This is the truth function FFFT,
>=20
> Nope. It is the negation of TFFF, i.e. FTTT.
> It is the case that either ko'a is not broda
> or ko'e is not broda (or both). In other words:
> naku ko'a broda ija naku ko'e broda

You're right.

> Just as passing a negation through {ro} changes it to {su'o},
> passing a negation through {e} changes it to {a}.
>=20
> The rest is an expansion of {ko'a e ko'e naku broda}:
>=20
> >which you can get with
> > ko'a na.enai ko'e broda
> > ko'a .e ko'e na broda
> >or
> > ko'a na broda .ijenai ko'e broda
> > ko'a na broda .ije ko'e na broda
> >which means
> > naku ko'a broda .ije naku ko'e broda =3D=3D
> > naku zo'u ko'a broda .ije naku zo'u ko'e broda
> >works fine.
>=20
> See the section starting on pg. 407.

I dunno where that is; I don't have a hardcopy (chapter+section is
better). But you're right about the expansions since I misthunk
the truth function.

> >I'm not even sure what the relation you're suggesting is anyway.
> >You have "ko'a .e ko'e" and can say "ro le re broda" meaning the
> >same thing... so what? You can always say the same thing in many
> >different ways, and the transformation loses information.
>=20
> It's deeper than that. You can think of a quantification with
> {ro} as a long string of conjunctions:
>=20
> ro broda =3D le broda e le broda e le broda e le broda e ...
>=20
> where each {le broda} picks one member of {lo'i broda}.
> See also
>=20
> http://nuzban.wiw.org/wiki/index.php?DeMorgan%27s%20Laws
>=20
> for more about this.

So e has scope then, and it matters where you put the naku boundary
with regard to it, etc. But I still don't see the relevance here
to which convention is used for tag+sumti scoping. We still can
interpret
paroiku ko'a .e ko'e broda
as
ko'a paroi broda .ije ko'e paroi broda
because floating tenses work differently than naku. And
paroi ko'a .e ko'e broda
as
paroi ko'a broda .ije paroi ko'e broda

--=20
Jordan DeLong - fracture@allusion.net
lu zo'o loi censa bakni cu terzba le zaltapla poi xagrai li'u
sei la mark. tuen. cusku

--ZGiS0Q5IWpPtfppv
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)

iD8DBQE9l5DIDrrilS51AZ8RAiVwAKC+kLyRLp9fBpz4y/rah9YPAzBSoACbBFkL
N6Xyyd7XI/zCEXs5byEYT+k=
=5MNn
-----END PGP SIGNATURE-----

--ZGiS0Q5IWpPtfppv--

