Received-SPF: pass (google.com: best guess record for domain of kali9putra@yahoo.com designates 72.30.239.149 as permitted sender) client-ip=72.30.239.149;
References: <1323373742.18817.YahooMailRC@web81306.mail.mud.yahoo.com> <CAO7tK2dghkmpansUrBCZY7HkcH0sBGWzDpv+d8hB7ge9MuV9Ag@mail.gmail.com> <C261B304-A8BC-4955-9016-72D1F24B5471@yahoo.com> <CAO7tK2eRL4D7Yy-Sz=JUcTtnwuyKt_tnBx9XjhRkzpgQmB2igw@mail.gmail.com>
In-Reply-To: <CAO7tK2eRL4D7Yy-Sz=JUcTtnwuyKt_tnBx9XjhRkzpgQmB2igw@mail.gmail.com>
Mime-Version: 1.0 (iPad Mail 8G4)
Message-Id: <857BF1E4-628A-4E05-BC02-A90D15C6895E@yahoo.com>
From: "John E. Clifford" <kali9putra@yahoo.com>
Subject: Re: [lojban] semantic parser - tersmu-0.1rc1
Date: Fri, 9 Dec 2011 11:07:22 -0600
To: "lojban@googlegroups.com" <lojban@googlegroups.com>
Reply-To: lojban@googlegroups.com
Precedence: list
Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com
Sender: lojban@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam_score: -0.7
X-Spam_score_int: -6
X-Spam_bar: /

Curse you, auto- correct!  "helter skelter" ( as I suspect you know, but "h=
elper smelter" does sound weirdly appropriate)

Sent from my iPad

On Dec 9, 2011, at 9:24 AM, Jorge Llamb=EDas <jjllambias@gmail.com> wrote:

> On Thu, Dec 8, 2011 at 8:39 PM, John E. Clifford <kali9putra@yahoo.com> w=
rote:
>> I suppose my point is just that, when we make all these claims about bei=
ng logical ( even in the narrow sense), one expects that the way that sente=
nces are constructed has some rational connection to the logic below, not j=
ust helper smelter rules which happen to work, in some practical sense.  So=
, what I sketched briefly was one case of trying to make such a rule, where=
 the sentences clearly meant the same thing from beginning to end, not just=
 ending up right.  As I  say later, such rules may not be possible, but the=
y do deserve a look.
>=20
> The sentences have to mean the same thing from beginning to end with
> the helper smelter rules too, not just end up right. If there is one
> step where they mean something different, the helper smelter rule
> fails.
>=20
> It seems that what bothers you is that Lojban has eks and giheks, and
> quantifiers and negations admitted as pseudo-arguments. You may want
> to call that illogical, and in some sense it is, but it's been part of
> Lojban and of Loglan from the beginning, so you can't be finding out
> about it just now.
>=20
> Since these constructions are not part of standard notation, there
> have to be helper smelter rules to show how they come about from
> standard notation, or how to change them into standard notation.
>=20
> I don't see anything particularly irrational in the helper smelter
> rules as I proposed them, and you didn't give enough information about
> any alternative rule you have in mind that you claim would make more
> rational connections, so I can't compare.
>=20
>> As for what is ignored, the list in this case is fairly short: binding, =
instantiation, and role.  The one particular quantifier is governed by two =
universals ( more or less), which means it's instantiation has to take both=
 into account,
>=20
> How is "ro lo re prenu cu citka su'o plise" different from "la .djan.
> .e la .meris. citka su'o plise"? "Each of the two people ate an apple"
> vs. "Both John and Mary ate an apple"?
>=20
One is complex, the other compound; one has a quantifier in the scope of an=
other, the other doesn't (though the corresponding Skolem function would ha=
ve to take both names into account, which may be a similar constraint); one=
 has instances, the other doesn't.

> Or even better: How is "no lo re prenu cu citka su'o plise" different
> from "la .djan. na .e nai la .meris. citka su'o plise"? "None of the
> two people ate an apple" vs. "Neither John nor Mary ate an apple".
>=20
> Assuming we agree those are in some sense equivalent (but who knows if
> I can make that assumption), extend it now to "Each of the two boys
> and one of the two girls ate an apple" vs "John and Paul, and either
> Mary or Alice but not both, ate an apple". Is there any reason for
> that not to be the reading of "ro lo re nanla .e pa lo re nixli cu
> citka su'o plise"?

Well, the equivalence depends on the assumption that the groups named have =
indeed just the members named, but that is rather trivial.  And, of course,=
 the names version is hardly a reading of the quantifier version, though it=
 is an instance of it, under certain further conventions.  Of course, shift=
ing from quantifiers over variables to quantifiers on plural terms also cha=
nges the game somewhat, since we then have to deal with either set their of=
 some sort or plural reference, though it is not clear that this expansion =
presents any real problems.
>=20
>> while in the final analysis, the two particular quantifiers are each gov=
erned by a single quantifier and needs only to take that into account.  Nei=
ther of the two ultimate instantiations would be the one the single case wo=
uld give,  and, while you may say that the quantifier expressions are not t=
erms, they are certainly treated as such
>=20
> So that's what bothers you, right? That a quantifier is treated
> syntactically as a term, when it is obviously not a term semantically.
> If that's what you wanted to point out as irrational, then I agree,
> there is some irrationality in that. But it's something that has
> always been part of Lojban.

Well, yes, I suppose it is.  Thank you.  I have maintained since 1976 (with=
 occasional lapses) that there was something inherently wrong with the prop=
aganda about Logjam and just now I see the crux of it: scope lines are scra=
mbled and different quantifiers are treated as the same.  You cannot, for e=
xample, find veridical instance of the recto particular quantifiers in the =
examples with names.
>=20
>> (the claim that that they can't shift positions doesn't enter here, nor,=
 I would think, in analysis generally);they are, after all, joined just lik=
e names, not the overarching structural elements the are ( ultimately).
>=20
> Right, and that's why we need helper smelter rules to sort that out.
> Or do you think there is some other way?
>=20
>> Yes, every particular quantifier ( and universal, for that matter) is th=
e same in function, but surely not in content, a {su'o plise} in one senten=
ce points to different apples from that in another sentence. And similarly =
for a universal, if we are restricting our domain to just the immediately r=
elevant groups, as seems to be the (unacknowledged) case here.
>=20
> Is that also what bothers you, that a predicate may have different
> extensions in different instances of use due to domain of discourse
> shifts? This is a separate issue, and then you should also be worried
> about "la .djan. .e la .pol. cu prami la .meris." expanding as "la
> .djan. cu prami la .meris. .i je la .pol. cu prami la .meris.", since
> we can conceive of contexts in which "la .meris." has different
> referents in the expanded form but not in the collapsed form. The
> helper smelter rules assume a fixed domain of discourse so that "su'o
> plise" (or "ro plise", or "no plise") keeps the same domain every
> time.
>=20

Not the domain, the actual instances.  We would reject a collapse of the se=
cond sentence here into the first if the two Marys were different, so why a=
llow it when the two {su'o plise} point to different apples, even if from t=
he same pile?=20

>>>> (note the negation sign has here
>>>> been reassigned as part of the quantifier)
>>>=20
>> The objection is, of course, to burying a negation ( another structural =
element) in a term, a non-structural element.
>=20
> But that's what Lojban does and has always done. Surely you are not
> finding out about this just now.
>=20
No, just finding out about the source of an abiding gut feeling, which I ha=
d never quite found the right words to express.

>>> They are two instances of one and the
>>> same sentential operator, just like two instances of "na ku" would be
>>> two instances of one and the same sentential operator. (They are
>>> "terms" only in the sense that Lojban's formal grammar calls them
>>> that, but that's just Lojban being sloppy with technical terms as
>>> usual.)
>>>=20
>> Except that quantifiers, unlike negations, introduce references to thing=
s.
>=20
> In the sense that they need a domain of quantification? Yes. And the
> domain of quantification should be maintained for quantifier "terms"
> that are shared by eks or giheks.

Not domain, instances are the problem.

>=20
>>> That involves a donkey pronoun, and we don't as yet have spelled out
>>> proper rules to handle them. This is not part of the kind of unpacking
>>> rules we were discussing.
>>>=20
>> But it is just the kind of rule that needs to be discussed.
>=20
> Sure. But let's not confuse it with the helper smelter rules that deal
> with the much more tractable issue of expanding eks and giheks and
> moving "quantifier terms" and negations to the prenex, and the
> slightly more hairy but still manageable issue of dealing with
> implicit binding of variables. The jury is still out on donkey
> anaphora, but eks, giheks, quantifier terms and negations only need a
> reasonable convention. Let's not muddle the simple issues with the
> truly complicated ones.
>=20
Well, of course, I don't think donkey sentences are problems; we know exact=
ly how to handle them and always have.  they do present problems for rules =
of your sort which try to take items one at a time and in order, rather tha=
n a more global (at least context-sensitive) approach.  As soon as you assi=
gn a {su'o} to all "floating" variables, you have eliminated the possibilit=
y of donkey sentences, which may or may not cripple your results, but seems=
 rather arbitrary, given how natural languages work.

Again, this is a theoretical ( even aesthetic) comment.  The needs of a spe=
akable language override logical clarity.  If the crude rules always give t=
he right results, what's the problem? Even a little braggadocio does no har=
m.  But a bit of concern with justifying the rules by something other than =
their results wouldn't hurt either.
> mu'o mi'e xorxes
>=20
> --=20
> You received this message because you are subscribed to the Google Groups=
 "lojban" group.
> To post to this group, send email to lojban@googlegroups.com.
> To unsubscribe from this group, send email to lojban+unsubscribe@googlegr=
oups.com.
> For more options, visit this group at http://groups.google.com/group/lojb=
an?hl=3Den.
>=20

--=20
You received this message because you are subscribed to the Google Groups "=
lojban" group.
To post to this group, send email to lojban@googlegroups.com.
To unsubscribe from this group, send email to lojban+unsubscribe@googlegrou=
ps.com.
For more options, visit this group at http://groups.google.com/group/lojban=
?hl=3Den.