Received: from VMS.DC.LSOFT.COM (vms.dc.lsoft.com [205.186.43.2]) by locke.ccil.org (8.6.9/8.6.10) with ESMTP id HAA13397 for ; Sun, 18 Feb 1996 07:00:04 -0500 Message-Id: <199602181200.HAA13397@locke.ccil.org> Received: from PEACH.EASE.LSOFT.COM (205.186.43.4) by VMS.DC.LSOFT.COM (LSMTP for OpenVMS v1.0a) with SMTP id 62B87E6D ; Sun, 18 Feb 1996 6:25:39 -0500 Date: Sun, 18 Feb 1996 11:25:16 +0000 Reply-To: ucleaar Sender: Lojban list From: ucleaar Organization: baseline subversion guerilla force Subject: Re: TECH: fuzzy logic To: lojban@cuvmb.cc.columbia.edu X-Mozilla-Status: 0011 Content-Length: 3469 X-From-Space-Date: Tue Feb 20 15:05:18 1996 X-From-Space-Address: - > >I too wish to declare that, like everyone else, I am not making > >grammar change proposals either. I think an immediate baseline should > >be declared, so your tension levels drop a bit. Instead, I am > >engaged in discussions about how the grammar should change if it > >ever were to change. > Does this mean I do not have to read and respond to your postings? > because I am not interested in anything beyond the baseline until > after the baseline. %^) It's not for me to say whether you have to read and respond to my postings, though my opinion is that you don't have to. I'm amazed at your persistence. *You* call *me* stubborn! I don't think I ever say much that requires the scrutiny of the LLG president. > >> BUT na'e is not solely used for scales on brivla, so we have to be > >> careful about adding to the set of scalar variables. > >Could you explain more? > Look at references to NAhE in the machine grammar. To my shame and frustration I have never managed to think my way into the formalism. Maybe when a thicko's guide to it comes out I'll be able to pretend to be an expert on it. > Allow your construct in any of them. Do they make sense in all. > Likewise NA (which among other things MAY mean that your fuzzy XVV > construct can end up in a logical connective in place of, say "na.a"). I see. Well for my xoi/xio proposals I did think of this matter. If the semantics of {na a} and {jaa a} is compositional, then {xoi a} ought also to have predictable meaning (if the basic logic is understood). But it may be that the meaning of {na a} is idiomatic, in which case there need be no expectation that {jaa a} or {xoi a} will mean anything. [My impression is that {na a} is idiomatic, but that it's fairly easy to extrapolate to {jaa a} and {xoi a}.] The same goes for NAhE, but even more so. If every member of NAhE has a meaning in every context in which NAhEs are permitted, then so will {xio}. > >> Otherwise we will get something or another that will use And's > >> proposal and have to be interepreted isiomatically just as you fear > >> as the case for NAhE xi quantifier. > >& explain this too...? > Well, see the above reference to na.a, and imagine replacing na by > your construct. Come up with a conventional interpetation. Promise me > that no other conventional interpreetation will EVER conflict with it. > Repeat for all occurances of NA and NAhE to cover all of your proposal. I answer this above. > This is similar to the question of putting lambda in KOhA. Does it > have meaning in ALL places where KOhA can appear. If not, you need > conventions, and those conventions need to be immutable as possible > (e.g. the convention on ke'a, which is anothe KOhA that has no meaning > in many contexts) The selmao of the lambda variable is an irrelevance. Since {ka} does not have a selmao to itself, there is no way to constrain its occurrence to within ka...kei. Selmao CUhE is in this respect no better than KOhA. As you say, there is a convention for {kea}, which is why it made so much sense to use {kea} for the lambda variable. I proposed a perfectly straightforward convention that would cover all uses of {kea}. OK - I failed to persuade you there was a semantic basis for making {kea} do all these jobs, not least because my arguments were very unpersuasive (though even when they are very persuasive you never get persuaded), but the fact remains that the {kea} solution would have worked okay. coo, mie and