From lojban+bncCIfp7ILVEBDgnJrwBBoEkNuJtQ@googlegroups.com Sat Jun 25 18:42:04 2011 Received: from mail-pv0-f189.google.com ([74.125.83.189]) by chain.digitalkingdom.org with esmtp (Exim 4.72) (envelope-from ) id 1QaeMM-0006UK-D9; Sat, 25 Jun 2011 18:42:04 -0700 Received: by pvc22 with SMTP id 22sf2346003pvc.16 for ; Sat, 25 Jun 2011 18:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:x-beenthere:received-spf:mime-version :in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-google-group-id:list-post :list-help:list-archive:sender:list-subscribe:list-unsubscribe :content-type:content-transfer-encoding; bh=uZ9BbwWxeAnyNxZ9tdWPypt5tCaBwSRtWZRZEEM0KYs=; b=nxeg5Cz2ZSCFVmZgGZfzCl/3pgG6K/OjddjU1g3BpaL7SIIhpSsK3qE/ECBxOotWX5 xhG/oQXR8PVJrMPhdcIHwzD3LpcRomGlQ8zBD5sCwuBsrbVgqdExO5ZxEAJdWIVbZQ3A 4T90LB/mARKspKX2fEeDBy9Me+XbEYPpim7wA= 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-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe:content-type :content-transfer-encoding; b=g3IujM10RdTaPizD29z+fNof0W1Ar/LxJgiklW9iPyJCrgmp3FOZJjttThcKzbsW3/ 5a8m+nM5qJA7pF67juTDGAWF4swIj2ZWoBFAF2fbge/f7QZyUQvhSXvGu4zmWlH1+RYn INGY3vBrX2pWzyVSfR4ljmhY2UM7bEc8rSxck= Received: by 10.142.4.4 with SMTP id 4mr708962wfd.53.1309052512740; Sat, 25 Jun 2011 18:41:52 -0700 (PDT) X-BeenThere: lojban@googlegroups.com Received: by 10.68.59.41 with SMTP id w9ls1098941pbq.1.gmail; Sat, 25 Jun 2011 18:41:51 -0700 (PDT) Received: by 10.68.16.201 with SMTP id i9mr930237pbd.32.1309052511866; Sat, 25 Jun 2011 18:41:51 -0700 (PDT) Received: by 10.68.16.201 with SMTP id i9mr930236pbd.32.1309052511853; Sat, 25 Jun 2011 18:41:51 -0700 (PDT) Received: from mail-pv0-f169.google.com (mail-pv0-f169.google.com [74.125.83.169]) by gmr-mx.google.com with ESMTPS id f8si8951519pbc.0.2011.06.25.18.41.51 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 25 Jun 2011 18:41:51 -0700 (PDT) Received-SPF: pass (google.com: domain of felipeg.assis@gmail.com designates 74.125.83.169 as permitted sender) client-ip=74.125.83.169; Received: by pvc12 with SMTP id 12so2963549pvc.14 for ; Sat, 25 Jun 2011 18:41:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.36.9 with SMTP id m9mr2253676pbj.11.1309052511600; Sat, 25 Jun 2011 18:41:51 -0700 (PDT) Received: by 10.68.48.102 with HTTP; Sat, 25 Jun 2011 18:41:51 -0700 (PDT) In-Reply-To: References: Date: Sat, 25 Jun 2011 22:41:51 -0300 Message-ID: Subject: Re: [lojban] non-ka properties From: =?ISO-8859-1?Q?Felipe_Gon=E7alves_Assis?= To: lojban@googlegroups.com X-Original-Sender: felipeg.assis@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of felipeg.assis@gmail.com designates 74.125.83.169 as permitted sender) smtp.mail=felipeg.assis@gmail.com; dkim=pass (test mode) header.i=@gmail.com Reply-To: lojban@googlegroups.com Precedence: list Mailing-list: list lojban@googlegroups.com; contact lojban+owners@googlegroups.com List-ID: X-Google-Group-Id: 1004133512417 List-Post: , List-Help: , List-Archive: Sender: lojban@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2011/6/25 Jorge Llamb=EDas : > 2011/6/23 Felipe Gon=E7alves Assis : >> >> Could you point me where this general meaning of {kau} is explained? > > I don't think there is any detailed explanation of "kau" anywhere, > largely because we haven't agreed on one. There has been a lot of > discussion about it on this list, if you have the patience to search > the archives. > I have actually been examining them, but there are just so many years of discussion... It was only not clear to me how settled the issue was, but as far as I can see, {kau} is really only documented as part of an indirect question with {du'u}, and the point is what the logic behind an indirect question is. ta'onai Thank you very much for all your careful considerations, xorxes. > (2) do "zmadu" and "jibni" require functions as their third argument. Having clarified the situation, allow me to try to attract you to my point of view. First, a thought experiment. Imagine you were assigned to define the place structure of a gismu based on the idea of "more", or comparatives. How would you define it? (Really, think a bit about that before proceeding) Now, what I believe my approach would be. I would start with "x1 is more than x2..." and think, "we need more places to specify in which sense x1 is more than x2". And in which senses may something be more than other? This is no mystery in logic or math. The general idea of "being more" is the concept of an order relation. My first proposal would possibly be "x1 is greater than x2 under order relation x3", with {zmadu} and {mleca} being the words used to talk generally about order relations. How can we express an order relation? Straightforwardly: {ko'a zmadu ko'e loka ce'u cnita ce'u}. Assuming the place structure of the order relation paralleled that of {mleca}, the above sentence would mean precisely {ko'a se cnita ko'e}. It turns out, though, that there is another relatively simple way, probably much more common, to specify an order relation. Given a general set X, an already ordered set Z, and a map f: X -> Z, there is a unique order relation in X which makes f monotone. This is the order induced in X by Z via f. This is what we mean when we say "Alice is heavier than Bob". We are comparing the folks with the relation induced by the usual real numbers ordering via the weight function. In these cases, it would be much simpler to just make x3 the function. It could be argued that this is a sumti raising over the original definitio= n. This implicit sumti raising could be made standard with no risk of ambiguity. {jibni} is a similar case, requiring a metric to specify the kind of closeness, which on its hand might be specified as induced via a map into a metric space. > As for (2), while it would have been possible to define "zmadu" and > "jibni" that way, they just weren't defined that way as far as I > understand them. Let us look first at the definition. "x1 exceeds/is more than x2 in property/quantity x3 (ka/ni) by amount/exces= s x4" Granted, the line of thought of the gismu finti was not the same as mine. However, you certainly agree that the x3 is meant to specify the kind of more-ness being expressed. If you also think that a {zmadu} necessarily entails some order relation, you should agree that it is the x3 that allows the speaker to specify it. (The x4 is a separate issue, addressed at the end) Now, let us examine current use. In the sentence {ko'a zmadu ko'e loni ce'u clani}, would you describe the x3 as rather (a) a property abstraction in the same sense that {loka ce'u clani} is? (b) a quantity in the same sense as {loni ko'a clani} is? (c) the length function? (d) something else? Option (c) is clearly the answer for me. This means that the idea of a map in this position is not new. Unfortunately, the {ni} approach is limited, besides being a part of the grammar that might not please xorxes: > [...] Personally I > don't like it, because I think something that starts with "lo cmene" > should refer to names, and the function that maps people to names is > not itself a name. zo'o zo'onai I should have mentioned the ni-cehu case in the first message. (About the x4 in {zmadu}: This place appears to imply that our actual {zmadu} reflects the general structure of ordered metric spaces, rather than simple posets. This may be a consequence of the gismu finti having numbers in mind rather than general ordered sets. Anyway, the structure can still be induced via a suitable map. Also, the trivial metric is compatible with any poset.) Let us now proceed to the question of how to represent functions more generally, and in a practical way. > (1) how do we refer to a function in Lojban > You could refer to the function in the longwinded fashion: "lo fancu > be lo prenu bei lo valsi bei lo ka makau cmene ce'u", "the function > from people to words by the rule of what their name is" I would feel relieved if able to use at least that kind of construction, but even the nature of the x4 is unclear to me. I noticed you used the ka-kau, which I still consider messy. {fancu} would be more useful were it defined as, e.g., "[...] defined by expression x4 with free variable x5 (letteral)". What do you think of my using the undefined x5 like that? {fancu fo lu lo cmene be me'o xy. li'u me'o xy.} > but there is no cmavo (say "lo'au") that condenses that into > something like "lo'au cmene be ce'u". > I would suggest using a function cmavo, like "lo'au", for that. Alternatively, the new cmavo could play the role of {ce'u}, and bind to the usual descriptors, instead of abstractions: {lo cmene be ce'au} {loni ce'au clani} You will probably say that the function is not the territory, but unless there is serious consideration for an experimental cmavo, we should not argue about that. As a general note, whatever the means to representing a function may be, it should be relatively easy to specify its defining expression and range. The precise domain is usually unimportant. All in all, I am still convinced that functions are not only important, but also the right thing to fill some places. Nevertheless, I am not sure about how to best express them concisely while still keeping in line with current lojban grammar and usage... mu'o mi'e .asiz. --=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.