From pycyn@aol.com Thu Aug 09 17:43:00 2001
Return-Path: <Pycyn@aol.com>
X-Sender: Pycyn@aol.com
X-Apparently-To: lojban@yahoogroups.com
Received: (EGP: mail-7_3_1); 10 Aug 2001 00:42:59 -0000
Received: (qmail 27579 invoked from network); 10 Aug 2001 00:42:58 -0000
Received: from unknown (10.1.10.142)
  by m8.onelist.org with QMQP; 10 Aug 2001 00:42:58 -0000
Received: from unknown (HELO imo-r08.mx.aol.com) (152.163.225.104)
  by mta3 with SMTP; 10 Aug 2001 00:42:58 -0000
Received: from Pycyn@aol.com
  by imo-r08.mx.aol.com (mail_out_v31.9.) id r.c5.1492208a (4068)
  for <lojban@yahoogroups.com>; Thu, 9 Aug 2001 20:42:52 -0400 (EDT)
Message-ID: <c5.1492208a.28a4880b@aol.com>
Date: Thu, 9 Aug 2001 20:42:51 EDT
Subject: Re: [lojban] A or B, depending on C, and related issues
To: lojban@yahoogroups.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part1_c5.1492208a.28a4880b_boundary"
X-Mailer: AOL 6.0 for Windows US sub 10531
From: pycyn@aol.com

--part1_c5.1492208a.28a4880b_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

In a message dated 8/9/2001 6:24:35 PM Central Daylight Time, 
jjllambias@hotmail.com writes:


> "if P then Q, else R," which are also pleasantly simple:
> >(if P then Q) and (if not P then R)" and "(P iff Q) and (not P iff R)" 
> >While
> >I am sure there are easier ways to show that these are the simplest forms 
> >for
> >these functions, I confess to just having run all the possibilities from
> >disjunctive normal forms on down.
> 
> Neither of them is "Q or R, depending on P" though. One of
> the versions of that would be:
> 
> [(if P then Q) and (if not P then R)] xor
> [(if not P then Q) and (if P then R)]
> 

Well, they are in fact the two things that I usually see when I ask for an 
explanation of that phrase, and they do fit the requirements. I admit the 
other is more thorough sounding, but does it really introduce a new 
possibility in the concrete? Similarly, is the "P or Q, depending on the 
weather" more than an inspecific way to saying something of the first or 
second sort -- just failing to mention how the dependency goes. Since this 
all is out of the {makau} thread, which is about hiding significant 
information, perhaps that is an important fact, but then we need to see how 
these connections are going to work: (if Pkau then Q) and (if not-Pkau then 
R)?

The best simplification I could find in a dash was ~(Q&R) &(P => QvR) , 
which, while shorter, is markedly less informative when talking about 
depndencies.

--part1_c5.1492208a.28a4880b_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

<HTML><FONT FACE=arial,helvetica><BODY BGCOLOR="#ffffff"><FONT SIZE=2>In a message dated 8/9/2001 6:24:35 PM Central Daylight Time, 
<BR>jjllambias@hotmail.com writes:
<BR>
<BR>
<BR><BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">"if P then Q, else R," which are also pleasantly simple:
<BR>&gt;(if P then Q) and (if not P then R)" and "(P iff Q) and (not P iff R)" &nbsp;
<BR>&gt;While
<BR>&gt;I am sure there are easier ways to show that these are the simplest forms 
<BR>&gt;for
<BR>&gt;these functions, I confess to just having run all the possibilities from
<BR>&gt;disjunctive normal forms on down.
<BR>
<BR>Neither of them is "Q or R, depending on P" though. One of
<BR>the versions of that would be:
<BR>
<BR>[(if P then Q) and (if not P then R)] xor
<BR>[(if not P then Q) and (if P then R)]
<BR></BLOCKQUOTE>
<BR>
<BR>Well, they are in fact the two things that I usually see when I ask for an 
<BR>explanation of that phrase, and they do fit the requirements. &nbsp;I admit the 
<BR>other is more thorough sounding, but does it really introduce a new 
<BR>possibility in the concrete? &nbsp;Similarly, is the "P or Q, depending on the 
<BR>weather" more than an inspecific way to saying something of the first or 
<BR>second sort -- just failing to mention how the dependency goes. &nbsp;&nbsp;Since this 
<BR>all is out of the {makau} thread, which is about hiding significant 
<BR>information, perhaps that is an important fact, but then we need to see how 
<BR>these connections are going to work: (if Pkau then Q) and (if not-Pkau then 
<BR>R)?
<BR>
<BR>The best simplification I could find in a dash was ~(Q&amp;R) &amp;(P =&gt; QvR) , 
<BR>which, while shorter, is markedly less informative when talking about 
<BR>depndencies.</FONT></HTML>

--part1_c5.1492208a.28a4880b_boundary--

