From lojban+bncCKv97aq_GRC7jNHfBBoEHke3-A@googlegroups.com Wed May 19 13:13:03 2010 Received: from mail-ww0-f61.google.com ([74.125.82.61]) by chain.digitalkingdom.org with esmtp (Exim 4.71) (envelope-from ) id 1OEpdR-0006Oh-Ic; Wed, 19 May 2010 13:13:03 -0700 Received: by wwf26 with SMTP id 26sf15042wwf.16 for ; Wed, 19 May 2010 13:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:x-beenthere:received:received:received :received:received-spf:received:mime-version:received:received :in-reply-to:references:date:message-id:subject:from:to :x-original-authentication-results:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe:content-type; bh=C3Es3GU9HTmNl6qh1gvXIKXYrhjtiGUUGB1f+sUYhS4=; b=LO9b53F2VwEqLtQBxUhun0SRM+hH+7WTDFxZISofTwtEG0cX8m3cfQPvDxVVfVNmUw rywSEQ0rfufWHDBoywzbEICXov7sJf0FsGo+X2JK8Ap9FlM5xHEMFo2iA160VvilVA2f hHYzknKDH0SPX6ljlCb5pSbXFRUtD5XWxucDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-authentication-results :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe:content-type; b=W5zZLKGQ6XmW0L0M/E/BDeAJTYAZL9rcqtHqamW0CM+EN35FY7cjevaP8QR3150HMz Ksuc34ldpzZ7TiBPVWpDRpZOsuIRJln39550gqLI/u0+k0WuWlsjV8JbIBPgocSShKxO vu29fJBoROp4XD8qBO7tlQKL0NUGVRB2q/twY= Received: by 10.223.4.212 with SMTP id 20mr1246758fas.40.1274299963765; Wed, 19 May 2010 13:12:43 -0700 (PDT) X-BeenThere: lojban@googlegroups.com Received: by 10.204.32.206 with SMTP id e14ls288544bkd.2.p; Wed, 19 May 2010 13:12:38 -0700 (PDT) Received: by 10.204.140.13 with SMTP id g13mr69047bku.0.1274299958384; Wed, 19 May 2010 13:12:38 -0700 (PDT) Received: by 10.204.140.13 with SMTP id g13mr69046bku.0.1274299958302; Wed, 19 May 2010 13:12:38 -0700 (PDT) Received: from mail-fx0-f48.google.com (mail-fx0-f48.google.com [209.85.161.48]) by gmr-mx.google.com with ESMTP id v26si3230357bkt.3.2010.05.19.13.12.37; Wed, 19 May 2010 13:12:37 -0700 (PDT) Received-SPF: pass (google.com: domain of lamelnyk@gmail.com designates 209.85.161.48 as permitted sender) client-ip=209.85.161.48; Received: by mail-fx0-f48.google.com with SMTP id 16so2221755fxm.7 for ; Wed, 19 May 2010 13:12:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.102.210.18 with SMTP id i18mr1408850mug.92.1274299957037; Wed, 19 May 2010 13:12:37 -0700 (PDT) Received: by 10.204.117.15 with HTTP; Wed, 19 May 2010 13:12:36 -0700 (PDT) In-Reply-To: References: <20100518160715.GA6617@sdf.lonestar.org> Date: Wed, 19 May 2010 23:12:36 +0300 Message-ID: Subject: Re: [lojban] Named multiples From: Oleksii Melnyk To: lojban@googlegroups.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of lamelnyk@gmail.com designates 209.85.161.48 as permitted sender) smtp.mail=lamelnyk@gmail.com; dkim=pass (test mode) header.i=@gmail.com X-Original-Sender: lamelnyk@gmail.com Reply-To: lojban@googlegroups.com Precedence: list Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: Sender: lojban@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: multipart/alternative; boundary=0016364186a546cb6c0486f814bf --0016364186a546cb6c0486f814bf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2010/5/19 Jorge Llamb=EDas Can you give an example? ... Are you talking about human parsing? Yes. Let's take an example from NORALUJV.txt. I've spotted "backemselrErkru= " (: it is long enough to either got out of air in the middle of it, or just need to look into the dictionary to recall the next rafsi, whatever :). Any pause after the vowel and the stressed "lrE" leaves us with "rkru" as the last rafsi, so here was some error. Any pause after the consonant will aler= t us about "no LA before the cmene"(not morphology level, but easy/close enough for humans). Pause after the "CVV" rafsi (not in an example), will b= e noticed as "no stress in previous word". Only in "la backemselrErkru" the pause between the rafsi's will go unnoticed. In the cmevla, after the required LA, we do expect the sequence of names, so breaking one into several will cause almost no harm, we'll just glue them together up to the last consonant ending word. So, we are almost immune to the extra pauses inside the long words. Now, without the required LA, we'll get: ba.ckemselrErkru - can fail bac.kemselrErkru - OK back.emselrErkru - can fail backe.mselrErkru - can fail backem.selrErkru - OK backems.elrErkru - can fail backemse.lrErkru - can fail backemsel.rErkru - OK backemselr.Erkru - can fail backemselrE.rkru - can fail backemselrEr.kru - OK, can eat the next word backemselrErk.ru - OK backemselrErkr.u - OK Note, that all the "fails" only "_can_ be"; if there are the otherwise _allowed_ pause after the entire word, it will parse, giving us 2 wrong meaningful chunks. The exact same problem exists with or without the change. The > change has no relevance to word parsing. > So, the change affects an error detection. If the humans all were the reliable electronic devices with the error detection codes in the communication channel, that would be irrelevant. However they are not, and the language was meant to be "error detecting communication channel" for them. Why would a text be full of cmevla? As you say, cmevla are a > cumbersome type of word, so they don't blend well with normal Lojban > words. Simplifying their syntax would not make them morphologically > prettier, it would only make the syntax simpler. > I do like the idea. I just looking for the bad consequences. The result of the change would be the wider usage of cmevla. Otherwise, there are no reason to make it simpler. Trying to read them aloud would push "the live language" towards toki pona (as the best case). "." is OK in writing. Not so in speech. We do need to think/breath/rest/etc= . sometimes. That sounds just as ".......". So, using "." as the syntax marke= r looks bad for a human-spoken audio-video isomorphic language. --=20 mu'o mi'e lex --=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. --0016364186a546cb6c0486f814bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2010/5/19 Jorge Llamb=EDas <jjllambias@gmail.com>=A0

Can you give an example? ... Are you talking about human parsing?

Yes. Let's take a= n example from NORALUJV.txt. I've spotted "backemselrErkru" (= : it is long enough to either got out of air in the middle of it, or just = need to look into the dictionary to recall the next rafsi, whatever :). Any= pause after the vowel and the stressed "lrE" leaves us with &q= uot;rkru" as the last rafsi, so here was some error. Any pause after t= he consonant will alert us about "no LA before the cmene"(not mor= phology level, but easy/close enough for humans). Pause after the "CVV= " rafsi (not in an example), will be noticed as "no stress in pre= vious word". Only in "la backemselrErkru" the pause between = the rafsi's will go unnoticed. In the cmevla, after the required LA, we= do expect the sequence of names, so breaking one into several will cause a= lmost no harm, we'll just glue them together up to the last consonant e= nding word.

So, we are almost immune to the extra pauses inside the long words. Now= , without the required LA, we'll get:

ba.ckemselrErkru - can fai= l
bac.kemselrErkru - OK
back.emselrErkru - can fail
backe.mselrErkru - can fail
backem.selrErkru - OK
backems.elrErkru - can fail
backemse.lrErkru - can fail
backemsel.rErkru - OK
backemselr.Erkru - can fail
backemselrE.rkru - can fail
backemselrEr.kru - OK, can eat the next word
backemselrErk.ru - OK
backemselrErkr.u - OK

Note, that all the "fails" only "_can_ be"; if ther= e are the otherwise _allowed_ pause after the entire word, it will parse, g= iving us 2 wrong meaningful chunks.

The exact same problem exists with or without the change. The
change has no relevance to word parsing.
=
So, the change affects an error detection. If the humans all were the r= eliable electronic devices with the error detection codes in the communicat= ion channel, that would be irrelevant. However they are not, and the langua= ge was meant to be "error detecting communication channel" for th= em.

Why would a text be full of cmevla? As you say, cmevla are a
cumbersome type of word, so they don't blend well with normal Lojban words. Simplifying their syntax would not make them morphologically
prettier, it would only make the syntax simpler.

= I do like the idea. I just looking for the bad consequences. The result of = the change would be the wider usage of cmevla. Otherwise, there are no rea= son to make it simpler. Trying to read them aloud would push "the live= language" towards toki pona (as the best case).

"." is OK in writing. Not so in speech. We do need to think/b= reath/rest/etc. sometimes. That sounds just as ".......". So, usi= ng "." as the syntax marker looks bad for a human-spoken audio-vi= deo isomorphic language.
=A0
--
mu'o mi'e lex

--
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.
--0016364186a546cb6c0486f814bf--