brian@digi-g.UUCP (Merlyn Leroy <Brian Westley>) (11/01/84)
#ifdef BUG Just to put in my $2E-2 on Things I Would Like to C in 'C': Why isn't there a logical XOR operator? There is & and && for bitwise and logical AND, | and || for bitwise and logical OR, but only ^ for bitwise XOR. Why can't ^^ be used for logical XOR? This is especially annoying since you have to say: (a || b) && (!a || !b) (two evals of a and b, yuck) or something like: ((a == 0) != (b == 0)) (ugly! ugly! ugly! obscure, too) instead of simply (a ^^ b). If you know that the true values of a and b are identical (instead of simply being non-zero), you can say a != b, but this is not always the case. Why not be consistent and offer logical XOR? The other operation(s) I would like is circular shift. zero fill << and >> are very inefficient if you really want a circular shift. There is a problem with insuring that the bit pattern wraps at the boundary you want (8, 16, 32, etc bits), but the compiler knows the size of the operand, and you can always typecast to force it. The operators could be <> and ><, or <$ and >$, or <^ and >^, or anything that isn't ambiguous. (If any of these are ambiguous, I don't care. I'm sure <> and >< aren't, but they can be confusing). /* comments? */ Merlyn Leroy #endif
abv@pucc-h (David Stevens) (11/03/84)
The "opop" syntax is for allowing short circuit evaluation of
boolean expressions. Thus && is there so that C can allow the programmer
to optimize, where apropriate. Exclusive Or, on the other hand, requires
that both operands be evaluated, so ^^ has no place.
Since boolean expressions evaluate to 1 or 0, bitwise operations
perform the same function as a non-short-circuit evaluation, and so &
does it all. I don't see where you lose by using just ^.
Of course, tese are all my opinions about the reasoning behind it,
since they didn't ask me.
----------
David L Stevens
{decvax|harpo|ihnp4|inuxc|seismo|ucbvax}!pur-ee!pucc-h:abv
The oppinions expressed above are not necessarily my own, or anyone else's.joe@petsd.UUCP (Joe Orost) (11/06/84)
<> David L Stevens says: > The "opop" syntax is for allowing short circuit evaluation of >boolean expressions. Thus && is there so that C can allow the programmer >to optimize, where apropriate. Exclusive Or, on the other hand, requires >that both operands be evaluated, so ^^ has no place. > Since boolean expressions evaluate to 1 or 0, bitwise operations >perform the same function as a non-short-circuit evaluation, and so & >does it all. I don't see where you lose by using just ^. > Of course, tese are all my opinions about the reasoning behind it, >since they didn't ask me. I disagree. The bitwise operators operate on every bit of their arguments, whereas the logical operators operate on zero -vs- non-zero. Therefore, i^j is not the same as i^^j. i^^j is equivalent to: i?(j?0:1):(j?1:0) which is only the same as i^j when i and j are 0 or 1. Therefore, I vote for the ^^ operator. regards, joe -- Full-Name: Joseph M. Orost UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!joe US Mail: MS 313; Perkin-Elmer; 106 Apple St; Tinton Falls, NJ 07724 Phone: (201) 870-5844
johnl@cca.UUCP (11/07/84)
#R:digi-g:-35200:ima:10100003:000:313 ima!johnl Nov 6 10:12:00 1984 Logical XOR? Sheesh. How about this: !a != !b or if you really like your truth values uninverted, !!a != !!b (Incidentally, PCC and other C compilers I've seen generate good code for such constructs.) John Levine, ima!johnl PS: What's the syntax for logical XOR of two complex BCD aggregate constants?
ark@alice.UUCP (Andrew Koenig) (11/07/84)
Joseph Orost suggests a new operator ^^ such that a^^b would be equivalent to a? (b?0:1): (b?1:0) What is wrong with writing a!=b for this purpose?
joe@petsd.UUCP (Joe Orost) (11/08/84)
<> >Joseph Orost suggests a new operator ^^ such that > > a^^b > >would be equivalent to > > a? (b?0:1): (b?1:0) > >What is wrong with writing > > a!=b > >for this purpose? Sorry, this is not the same. Take, for instance, a=3 and b=4. a^b = 7 a!=b = 1 a^^b = 0 Next take a=3 and b=0: a^b = 3 a!=b = 1 a^^b = 1 Another expression for a^^b is (a==0)^(b==0). Yet another one is (a!=0)^(b!=0). And yes, you have to evaluate both a and b no matter what. regards, joe -- Full-Name: Joseph M. Orost UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!joe US Mail: MS 313; Perkin-Elmer; 106 Apple St; Tinton Falls, NJ 07724 Phone: (201) 870-5844
fcy@iham1.UUCP (Fred Yankowski) (11/08/84)
Although "A != B" does not work as a C implementation of logical-
exclusive-or, "!A != !B" (or "!!A == !B") does, since the '!'
operator has the effect of converting an integer into a "canonical"
boolean value: zero or one (and negating the logical sense, of
course). Logical equivalence for arbitrary integers can be
similarly defined by "!A == !B".
Fred Yankowski ::: AT&T Bell Laboratories ::: ihnp4!iham1!fcyark@alice.UUCP (Andrew Koenig) (11/08/84)
Joseph Orost suggested that there should be a ^^ operator for logical exclusive-or, and I suggested that writing a!=b would work. I blew it. But this one works: !a != !b
john@x.UUCP (John Woods) (11/09/84)
> I disagree. The bitwise operators operate on every bit of their arguments, > whereas the logical operators operate on zero -vs- non-zero. Therefore, i^j Quite correct. However, you can get the effect of i ^^ j by typing !!i ^ !!j. ^^ would be nice, but it isn't strictly necessary (and the code sequence I gave might not be too poor on a decent compiler). -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1114 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA
abv@pucc-h (David Stevens) (11/09/84)
<bugs bugs bugs> Joe Orost says: >I disagree. The bitwise operators operate on every bit of their arguments, >whereas the logical operators operate on zero -vs- non-zero. Therefore, i^j >is not the same as i^^j. i^^j is equivalent to: > i?(j?0:1):(j?1:0) >which is only the same as i^j when i and j are 0 or 1. > >Therefore, I vote for the ^^ operator. > > regards, > joe > I disagree with you. The two important features of && over & are that 1) it is logical (not bitwise), and 2) it is short-circuit. Boolean expressions evaluate to 0 or 1, so ^==^^ in this case, and since both expressions must be evaluated, you gain nothing by adding ^^. If you are checking for "nonzeroness", then neither "a!=b" (as someone else suggested) nor "a^b" is equivalent to a^^b, but the question here is whether, for "nonzeroness", "(a!=0) != (b!=0)", or "(a!=0) ^ (b!=0)" is so ugly that an extension to include ^^ is reasonable. If a and b are not *really* logical expressions, then I say that what you want is "!=0", and not some magic to make them be treated like logcial expressions. I vote no for ^^. ---------- David L Stevens {decvax|harpo|ihnp4|inuxc|seismo|ucbvax}!pur-ee!pucc-h:abv DISCLAIMER: The opinions expressed above are not necessarily my own, or anyone else's.
pdf@garfield.UUCP (Paul D Fardy) (11/09/84)
The expression a ^^ b is not logically equivalent to a != b. if a = 2 and b = 3, then a ^^ b is false, but a != b is true. 1 is not true in C. 0 is false and !0 is true.
bsa@ncoast.UUCP (Brandon Allbery) (11/10/84)
> Article <3081@alice.UUCP>, from ark@alice.UUCP (Andrew Koenig) +---------------- | Joseph Orost suggests a new operator ^^ such that | a^^b | would be equivalent to | a? (b?0:1): (b?1:0) | | What is wrong with writing | a!=b | for this purpose? C programmers like to cut corners; witness all those on1 messages that depend on && evaluating as little as possible. It may be in K&R, but I've seen too many harebrained implementations of too manu programs... The problem with a!=b is that some of us use other corner-cutters: one of mine is if (index("AIJKLRaijklr", cmdchr)) dothis(); where index (strchr for USGers) returns either NULL or a pointer. This will NOT work if you use != for an xor: if (iscmd!=index("AIJKLRaijklr", cmdchr)) dothis(); is only true if !iscmd and !index(...), since index will usually NOT return a 1... --bsa -- Brandon Allbery @ North Coast Xenix | the.world!ucbvax!decvax!cwruecmp! 6504 Chestnut Road, Independence, Ohio | {atvax!}ncoast!{tdi1!}bsa (216) 524-1416 \ 44131 | E1439@CSUOHIO.BITNET (friend's acct.) ---------------------------------------+--------------------------------------- `Confusion is my natural state.'
tom@uwai.UUCP (11/11/84)
> Joseph Orost suggests a new operator ^^ such that > > a^^b > > would be equivalent to > > a? (b?0:1): (b?1:0) > > What is wrong with writing > > a!=b > > for this purpose? Consider the following: a = 5; b = 6; if ( a ^^ b ) foo(); /* foo would not execute - both a and b are true */ Now, if you said if ( a != b) boo(); /* foo would execute - a and b not the same */ you would not get the same thing, since I believe that the ^^ operator should treat its operands as strictly logicals, ie, force a !! coversion on each of them, just as the && and || operators do. I suppose you could say if ( !!a != !!b ) foo(); but there is something to be said for the elegance of ^^. I find myself of need of it now and again. -- Tom Christiansen University of Wisconsin Computer Science Systems Lab ...!{allegra,heurikon,ihnp4,seismo,uwm-evax}!uwvax!tom tom@wisc-crys.arpa
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/11/84)
> > a^^b > > > >would be equivalent to > > > > a? (b?0:1): (b?1:0) > > Another expression for a^^b is (a==0)^(b==0). > Yet another one is (a!=0)^(b!=0). To my mind, one of the sloppiest aspects of C is the omission of a true Boolean data type and the substitution of "nonzero integer" instead. The first expression given above at least has the advantage that it does not require evaluating an operand more than once nor using bitwise operators. There are a total of 16 Boolean binary operators, some of which are reducible to simpler expressions. Allowing for "conditional" operators (e.g. && ||) there are a few more possibilities. How many of these need to be in the language?
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/13/84)
> C programmers like to cut corners; witness all those on1 messages that > depend on && evaluating as little as possible. ??? The short-circuit behavior of && and || is a very important language feature; it is there by deliberate design. Without it, correct code for many types of loops would be quite awkward (`a la Pascal).
coltoff@burdvax.UUCP (Joel Coltoff) (11/13/84)
< ----------- >
What is at issue here is not if the ^^ is really needed. Anyone with
half a brain knows that it isn't. When I look at ^^ I can think of logical
exclusive OR right away. When I see !a != !b ( or !!a != !!b ) I have to
stop and think about it. If we want to get rid of ops that aren't needed
lets get rid of &&. Afterall ( a && b ) can be done by ( !( !a || !b ) )
How about getting rid of the minus operator. All we have to do is complement
and add. If the question is should the size of C be allowed to grow I say
leave it as is. If people are opposed to ^^ because it isn't needed then
maybe the whole language should be evaluated for frivolous features.
--
Joel Coltoff {sdcrdcf,bpa,psuvax1}!burdvax!coltoff
(215)648-7258henry@utzoo.UUCP (Henry Spencer) (11/13/84)
> The problem with a!=b is that some of us use other corner-cutters: one > of mine is [implicit comparison against 0 of the return from index()]. He who cuts corners sometimes cuts himself. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
ix269@sdcc6.UUCP (Jim) (11/15/84)
(Hate inclusions, but could misquote elsewise :->) /* * I will answer the ?problem? lower down ---v */ > David L Stevens says: > > > The "opop" syntax is for allowing short circuit evaluation of > >boolean expressions. Thus && is there so that C can allow the programmer > >to optimize, where apropriate. Exclusive Or, on the other hand, requires > >that both operands be evaluated, so ^^ has no place. > > Since boolean expressions evaluate to 1 or 0, bitwise operations > >perform the same function as a non-short-circuit evaluation, and so & > >does it all. I don't see where you lose by using just ^. >> edit << > > I disagree. The bitwise operators operate on every bit of their arguments, > whereas the logical operators operate on zero -vs- non-zero. Therefore, i^j > is not the same as i^^j. i^^j is equivalent to: > i?(j?0:1):(j?1:0) > which is only the same as i^j when i and j are 0 or 1. > > Therefore, I vote for the ^^ operator. >> edit << > Full-Name: Joseph M. Orost > UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!joe > US Mail: MS 313; Perkin-Elmer; 106 Apple St; Tinton Falls, NJ 07724 > Phone: (201) 870-5844 (Where do I vote :-) ?) Perhaps what you are searching for is this: if (( condB ) ^ ( condA )) /* conditionB XOR conditionA */ int x,y; char a,b; x = 1; y = 365; a = b = 't'; if ((x == y)^(a == b)) /* see? yes/no? */ putchar(a); else... although not all machines have booleans as 1, it is *hoped* that they will do it the same way everytime they do what they do. This should make TRUE some bit pattern and FALSE 0, FALSE should be 0 everywhere (meaning if it isn't where you are, send me mail so that I can avoid your county/state/machine :-).). The real question is perhaps, who needs this anyway? If you need it, please send me mail on what you use it for? Please. -=-=-=- -=-=-=- -=-=-=- -=-=-=- -=-=-=- < this disclaimer may have no intrinsic meaning. > Jim of HCDE {dcdwest,ucbvax}!sdcsvax!sdcc6!ix269 Usenet <ix269%sdcc6@sdcsvax> Arpanet (HCDE coming soon to be an illuminati near you)
ark@alice.UUCP (Andrew Koenig) (11/16/84)
Jim of HCDE says: "... although not all machines have booleans as 1, ..." From K&R, page 189: The operators < (less than), > (greater than), <= (less than or equal to), and >= (greater than or equal to) all yield 0 if the specified relation is false and 1 if it is true. From K&R, pag 190: The == (equal to) and the != (not equal to) operators are exactly analogous to the relational operators except for their lower precedcence. The && operator groups left-to-right. It returns 1 if both its operands are non-zero, 0 otherwise. Unlike &, && guarantees left-to-right evaluation; moreover the second operand is not evaluated if the first operand is 0. Page 191 contains a similar statement for ||
berry@zinfandel.UUCP (Berry Kercheval) (11/16/84)
In article <1799@burdvax.UUCP> coltoff@burdvax.UUCP (Joel Coltoff) writes: > What is at issue here is not if the ^^ is really needed. Anyone with >half a brain knows that it isn't. >...lets get rid of &&. Afterall ( a && b ) can be done by ( !( !a || !b ) ) >How about getting rid of the minus operator. All we have to do is complement >and add. Hear, hear! I've said for a long time to anyone who would listen (hold still! It's for your own good) that all any REAL programmer needs are <,>, * and 0. That is, move tape right, move tape left, write mark and erase mark. Presto! Church's thesis tells us this will suffice for ALL computation! Talk about RISC! Watch out Berkeley. Excuse me, the doctor says it's time for my electro-shock..... -- Berry Kercheval Zehntel Inc. (ihnp4!zehntel!zinfandel!berry) (415)932-6900
ron@brl-tgr.ARPA (Ron Natalie <ron>) (11/20/84)
> > Hear, hear! I've said for a long time to anyone who would listen > (hold still! It's for your own good) that all any REAL programmer > needs are <,>, * and 0. That is, move tape right, move tape left, write mark > and erase mark. Presto! Church's thesis tells us this will suffice for > ALL computation! Talk about RISC! Watch out Berkeley. > But says nothing about order of complexity being reasonable when compared to RAM. -Ron
mwm@ea.UUCP (11/21/84)
/***** ea:net.lang.c / zinfande!berry / 8:20 am Nov 19, 1984 */ Hear, hear! I've said for a long time to anyone who would listen (hold still! It's for your own good) that all any REAL programmer needs are <,>, * and 0. That is, move tape right, move tape left, write mark and erase mark. Presto! Church's thesis tells us this will suffice for ALL computation! Talk about RISC! Watch out Berkeley. Excuse me, the doctor says it's time for my electro-shock..... -- Berry Kercheval Zehntel Inc. (ihnp4!zehntel!zinfandel!berry) (415)932-6900 /* ---------- */ Then there's the other end of the scale, the Super CISC machine. The instruction is "SUBAB a, b, next". It subtracts the contents of location b from the contents of location a, results go back into a, and if the result is zero, branch to next instead of executing the next instruction. This is computationally sufficient, and a pipelined implementation will run at 1 instruction per clock tick. My version used 60 bit words, each word having 3 20 bit addresses when used as an instruction. Talk about fast! Now, where did I leave my add macro? <mike
steve@zinfandel.UUCP (12/15/84)
Sorry I'm a little late into this discussion, but my favorite way of saying logical_XOR(a,b) in C is: a?!b:b Note that the value returned is either zero or non-zero as opposed to zero or 1, so is good only when you want the expression to be evaluated for as zero or non-zero (as in an if or while). Steve Nelson zehntel!zinfandel!steve