From sentto-44114-17014-1036678956-lojban-in=lojban.org@returns.groups.yahoo.com Thu Nov 07 06:52:44 2002 Received: with ECARTIS (v1.0.0; list lojban-list); Thu, 07 Nov 2002 06:52:44 -0800 (PST) Received: from n18.grp.scd.yahoo.com ([66.218.66.73]) by digitalkingdom.org with smtp (Exim 4.05) id 189o1Q-0004Al-00 for lojban-in@lojban.org; Thu, 07 Nov 2002 06:52:40 -0800 X-eGroups-Return: sentto-44114-17014-1036678956-lojban-in=lojban.org@returns.groups.yahoo.com Received: from [66.218.67.195] by n18.grp.scd.yahoo.com with NNFMP; 07 Nov 2002 14:22:36 -0000 X-Sender: Pycyn@aol.com X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-8_2_3_0); 7 Nov 2002 14:22:35 -0000 Received: (qmail 12472 invoked from network); 7 Nov 2002 14:22:35 -0000 Received: from unknown (66.218.66.216) by m2.grp.scd.yahoo.com with QMQP; 7 Nov 2002 14:22:35 -0000 Received: from unknown (HELO imo-m10.mx.aol.com) (64.12.136.165) by mta1.grp.scd.yahoo.com with SMTP; 7 Nov 2002 14:22:35 -0000 Received: from Pycyn@aol.com by imo-m10.mx.aol.com (mail_out_v34.13.) id r.c3.2b989d13 (17228) for ; Thu, 7 Nov 2002 09:22:21 -0500 (EST) Message-ID: To: lojban@yahoogroups.com X-Mailer: AOL 8.0 for Windows US sub 230 From: pycyn@aol.com X-Yahoo-Profile: kaliputra MIME-Version: 1.0 Mailing-List: list lojban@yahoogroups.com; contact lojban-owner@yahoogroups.com Delivered-To: mailing list lojban@yahoogroups.com Precedence: bulk Date: Thu, 7 Nov 2002 09:22:21 EST Subject: [lojban] Re: importing ro Content-Type: multipart/alternative; boundary="part1_c3.2b989d13.2afbd11d_boundary" X-archive-position: 2489 X-ecartis-version: Ecartis v1.0.0 Sender: lojban-list-bounce@lojban.org Errors-to: lojban-list-bounce@lojban.org X-original-sender: pycyn@aol.com Precedence: bulk Reply-to: lojban-list@lojban.org X-list: lojban-list --part1_c3.2b989d13.2afbd11d_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/6/2002 9:27:59 PM Central Standard Time, jjllambias@hotmail.com writes: << > that if we want {naku ro broda cu brode} to be > equivalent to {su'o broda naku brode}, we have to define > {ro broda cu brode} as {ro da ganai broda gi brode}. If we > don't define it like that, then the negation passage won't > always work. >> But why would we want that equivalence. It is a product of the same mistake that makes "Every S is P" into the universally quantified conditional. We have two ways to treat a universal in Logic. Lojban offers both and in the same format as they are offered in Logic. Further the two ways in Lojban are related exactly as they are in Logic. This seems to be the kind of result we would want. If you really want a short way to say non-importing {ro}, then use the device you devised (? {ni'u ro}?) and all will come out as you want. << [&] . It may be irrelevant to 99.9% of usage as a >whole, but is it irrelevant to 99.9% of usage of ro? I >don't think so -- necessarily-nonimporting "every" is very >common in English (at least in the varieties I'm exposed to >in quotidian and professional life); pc's experience differs). You may be right. It would be interesting to see the results if someone actually took the trouble of going through some corpus to measure the relative frequencies. >> I'm not sure just how this survey would work. Surely most cases are ones in which the subject term is non-null, so you cannot tell which kind of quantifier is used. I suspect that the number cases of using a null-subject universal when you know the subject is null is vanishing small outside of indirect proofs in mathematics and logic. Using a universal with a subject which turns out to be null is not uncommon, but claiming that you meant a non-importing quantifier seems just a way of avoiding being convicted of saying something false. I think there is a footnote in Vendler about some actual corpus checks, with essentially this outcome. --part1_c3.2b989d13.2afbd11d_boundary Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit In a message dated 11/6/2002 9:27:59 PM Central Standard Time, jjllambias@hotmail.com writes:
<<
that if we want {naku ro broda cu brode} to be
equivalent to {su'o broda naku brode}, we have to define
{ro broda cu brode} as {ro da ganai broda gi brode}. If we
don't define it like that, then the negation passage won't
always work.

>>
But why would we want that equivalence.  It is a product of the same mistake that makes "Every S is P" into the universally quantified conditional.  We have two ways to treat a universal in Logic.  Lojban offers both and in the same format as they are offered in Logic.  Further the two ways in Lojban are related exactly as they are in Logic.  This seems to be the kind of result we would want. If you really want a short way to say non-importing {ro}, then use the device you devised (? {ni'u ro}?) and all will come out as you want.

<<
[&] . It may be irrelevant to 99.9% of usage as a
>whole, but is it irrelevant to 99.9% of usage of ro? I
>don't think so -- necessarily-nonimporting "every" is very
>common in English (at least in the varieties I'm exposed to
>in quotidian and professional life); pc's experience differs).

You may be right. It would be interesting to see the results
if someone actually took the trouble of going through some
corpus to measure the relative frequencies.
>>
I'm not sure just how this survey would work.  Surely most cases are ones in which the subject term is non-null, so you cannot tell which kind of quantifier is used.  I suspect that the number cases of using a null-subject universal when you know the subject is null is vanishing small outside of indirect proofs in mathematics and logic.  Using a universal with a subject which turns out to be null is not uncommon, but claiming that you meant a non-importing quantifier seems just a way of avoiding being convicted of saying something false.  I think there is a footnote in Vendler about some actual corpus checks, with essentially this outcome.
To unsubscribe, send mail to lojban-unsubscribe@onelist.com

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
--part1_c3.2b989d13.2afbd11d_boundary--