From pycyn@aol.com Sun Dec 03 13:11:58 2000 Return-Path: X-Sender: Pycyn@aol.com X-Apparently-To: lojban@egroups.com Received: (EGP: mail-6_3_1_2); 3 Dec 2000 21:11:57 -0000 Received: (qmail 18440 invoked from network); 3 Dec 2000 21:11:18 -0000 Received: from unknown (10.1.10.26) by l9.egroups.com with QMQP; 3 Dec 2000 21:11:18 -0000 Received: from unknown (HELO imo-d01.mx.aol.com) (205.188.157.33) by mta1 with SMTP; 3 Dec 2000 21:11:18 -0000 Received: from Pycyn@aol.com by imo-d01.mx.aol.com (mail_out_v28.34.) id a.b2.df420f8 (16337) for ; Sun, 3 Dec 2000 16:11:15 -0500 (EST) Message-ID: Date: Sun, 3 Dec 2000 16:11:15 EST Subject: de-, un- ce zo'e (was: common words) To: lojban@egroups.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_b2.df420f8.275c10f3_boundary" Content-Disposition: Inline X-Mailer: Unknown sub 171 From: pycyn@aol.com X-Yahoo-Message-Num: 4961 --part1_b2.df420f8.275c10f3_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The encrypt/decrypt set is obviously only one of a large set of do/undo pairs and, rather than getting too bound in the messinesses of a single case or so, we might look for a general solution. None of the obvious seem quite right: {tol} has been examined already, {na'e} gets the wrong results too often, {fa'e} regverses orders but in fact the order of steps in the process is often not reversed but the reversal comes in a different place (the steps in coding and decoding are often the same, just the nature of the input differs -- though, of course, there are many cases where the two processes are quite different, but still not reversals), and {dut} is almost the same as {tol} at least in definition. So we need to rethink what is involved here and work more on it. --part1_b2.df420f8.275c10f3_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit The encrypt/decrypt set is obviously only one of a large set of do/undo pairs
and, rather than getting too bound in the messinesses of a single case or so,
we might look for a general solution.  None of the obvious seem quite right:
{tol} has been examined already, {na'e} gets the wrong results too often,
{fa'e} regverses orders but in fact the order of steps in the process is
often not reversed but the reversal comes in a different place (the steps in
coding and decoding are often the same, just the nature of the input differs  
-- though, of course, there are many cases where the two processes are quite
different, but still not reversals), and {dut} is almost the same as {tol} at
least in definition.  So we need to rethink what is involved here and work
more on it. --part1_b2.df420f8.275c10f3_boundary--