Received: from localhost ([::1]:57151 helo=stodi.digitalkingdom.org) by stodi.digitalkingdom.org with esmtp (Exim 4.76) (envelope-from ) id 1Tqz2t-0005Nd-Q3; Thu, 03 Jan 2013 20:38:16 -0800 Received: from mail-ea0-f172.google.com ([209.85.215.172]:46230) by stodi.digitalkingdom.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1Tqz2l-0005NW-Bc for jbovlaste@lojban.org; Thu, 03 Jan 2013 20:38:13 -0800 Received: by mail-ea0-f172.google.com with SMTP id a1so6465172eaa.17 for ; Thu, 03 Jan 2013 20:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=YaAku8hCfYmJxlX547vwGyoc61Gfx2ZvdnSqzk+GGcg=; b=aSE7KycrjojNJhCvUPwx5PuBnHE7niPuFoz/dHYFjKl5kCd+AqojBPaZn5Ily07V6j SMiS4FnlyDxx7R4UBaTQDy77VOhpAsYrJItFOix0FPRo5U+FngXdxaFKhIyRtoilJi5S UYjbcysK3dnvnbqLK8m8y8+yXQ5gehq0zZktyxTi4ln36Jhp/jO22cEFbQ9PnQSX1TWJ pRyk8VrHirN558s9qxwd2n1smiGh0WAqEfiTA40QbJtERet419TLwhClKYiOxE27yKhT QLK8TWiP+yXcNJRXnAyzsTFyQBJzmwhdfUvKfImgBqKEnRwstXOAyXwQpguEbPUSCctQ 71zg== MIME-Version: 1.0 Received: by 10.14.208.137 with SMTP id q9mr139318387eeo.28.1357274279746; Thu, 03 Jan 2013 20:37:59 -0800 (PST) Received: by 10.223.151.16 with HTTP; Thu, 3 Jan 2013 20:37:59 -0800 (PST) In-Reply-To: <2496675.noDcb1HzR9@caracal> References: <20130103201946.GA18038@stodi.digitalkingdom.org> <2496675.noDcb1HzR9@caracal> Date: Thu, 3 Jan 2013 23:37:59 -0500 Message-ID: From: Eitan Postavsky To: jbovlaste@lojban.org X-Spam-Score: 0.2 (/) X-Spam_score: 0.2 X-Spam_score_int: 2 X-Spam_bar: / X-Spam-Report: Spam detection software, running on the system "stodi.digitalkingdom.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: I discern three opinions on this apparent conflict between {banro} and {brabi'o}: 1. They're different: roughly speaking, {banro} is about the beginning and ending /forms/, while {brabi'o} is about the beginning and ending /sizes/. 2. {brabi'o} is superfluous; delete it. 3. {brabi'o} is superfluous; restrict {banro} so that {brabi'o} not superfluous. [...] Content analysis details: (0.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (eitanp32[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (eitanp32[at]gmail.com) 0.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Subject: Re: [jbovlaste] [eitanp32@gmail.com: {banro} gets default sense of "grow"; conflicting with some lujvo] X-BeenThere: jbovlaste@lojban.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: jbovlaste@lojban.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4800817461294887216==" Errors-To: jbovlaste-bounces@lojban.org --===============4800817461294887216== Content-Type: multipart/alternative; boundary=047d7b621d164e9dd804d26f0be0 --047d7b621d164e9dd804d26f0be0 Content-Type: text/plain; charset=UTF-8 I discern three opinions on this apparent conflict between {banro} and {brabi'o}: 1. They're different: roughly speaking, {banro} is about the beginning and ending /forms/, while {brabi'o} is about the beginning and ending /sizes/. 2. {brabi'o} is superfluous; delete it. 3. {brabi'o} is superfluous; restrict {banro} so that {brabi'o} not superfluous. My respective responses (straw man much?): 1. The gismu list is very clear that {banro} involves an increase in some sense. ke'u it's not just changing from one form into another. {barda} (and {zenba}) captures quite well "increase in some sense", so... 2. I concur. Ian Johnson said it well (though I guess he later defected to 1?): "Seems to me that {banro} is {barda zenba}, with all the possible vagueness that barda2/barda3 introduce, and that {brabi'o} is superfluous." 3. That's crazy. I'll talk to la pier directly. li'a you're suggesting that we take {banro} to be restricted to increases resulting from life. Your velji'i is either independent of {brabi'o}, or dependent on it; that is, either {brabi'o} figures somewhere in your reasoning, or it figures nowhere in your reasoning. If it is independent, then basically you're interpreting the gismu list's definition of {banro} to be restricted to increases resulting from life; the word "life" figures nowhere in there, so clearly that is not the case. Therefore, your velji'i is dependent on {brabi'o}. So basically, because {brabi'o} is so similar to {banro}, you want to restrict {banro} so that it's not so similar. But the gismu list is /known/ to be redundant; that is, it is known that, for many a gismu G, you can construct a lujvo L out of gismu other than G so that L is so similar to G. By your reasoning, for each such G and L, we ought to narrow G so it's not so similar to L. That's absurd. By exhaustion, I conclude that your reasoning is absurd (or "crazy"). (Likely you'll disagree with the two parts of this paragraph that are labeled with the word "basically".) --047d7b621d164e9dd804d26f0be0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I discern three opinions on this apparent conflict between {banro} and {bra= bi'o}:
1. They're different: roughly speaking, {banro} is about = the beginning and ending /forms/, while {brabi'o} is about the beginnin= g and ending /sizes/.
2. {brabi'o} is superfluous; delete it.
3. {brabi'o} is superflu= ous; restrict {banro} so that {brabi'o} not superfluous.

My resp= ective responses (straw man much?):
1. The gismu list is very clear that= {banro} involves an increase in some sense. ke'u it's not just cha= nging from one form into another. {barda} (and {zenba}) captures quite well= "increase in some sense", so...
2. I concur. Ian Johnson said it well (though I guess he later defected to = 1?): "Seems to me that {banro} is {barda zenba}, with all the possible= vagueness that barda2/barda3 introduce, and that {brabi'o} is superflu= ous."
3. That's crazy. I'll talk to la pier directly. li'a you're= suggesting that we take {banro} to be restricted to increases resulting fr= om life. Your velji'i is either independent of {brabi'o}, or depend= ent on it; that is, either {brabi'o} figures somewhere in your reasonin= g, or it figures nowhere in your reasoning. If it is independent, then basi= cally you're interpreting the gismu list's definition of {banro} to= be restricted to increases resulting from life; the word "life" = figures nowhere in there, so clearly that is not the case. Therefore, your = velji'i is dependent on {brabi'o}. So basically, because {brabi'= ;o} is so similar to {banro}, you want to restrict {banro} so that it's= not so similar. But the gismu list is /known/ to be redundant; that is, it= is known that, for many a gismu G, you can construct a lujvo L out of gism= u other than G so that L is so similar to G. By your reasoning, for each su= ch G and L, we ought to narrow G so it's not so similar to L. That'= s absurd. By exhaustion, I conclude that your reasoning is absurd (or "= ;crazy"). (Likely you'll disagree with the two parts of this parag= raph that are labeled with the word "basically".)
--047d7b621d164e9dd804d26f0be0-- --===============4800817461294887216== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ jbovlaste mailing list jbovlaste@lojban.org http://mail.lojban.org/mailman/listinfo/jbovlaste --===============4800817461294887216==--