Well, consider expressions with xor that only contain values 1 and 0. What should "1 xor 1 xor 1" return? Least surprise would suggest that it should be 1 not 0. I was ignoring the fact that non-zero values perk through (which is not very useful in the "xor" case, unlike that for "or" or "and") and only was considering the eventual boolean meaning of the result.
Yes, we are discussing the definition of the language and of course there isn't any such function as xor(p1,p2,p3...) yet. We are attempting to determine just what that should mean it it were to be added. All we really have to go on right now is the carry over of the meaning from perl5 of "p1 xor p2 xor p3" which happens to be the same as "p1 xor (p2 xor p3))", I.e., built from a binary right-associative "xor" op. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > > --- "Mark A. Biggar" <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] wrote: > > > > > I see here another case of a common erroneous approach to > > > problem-solving. People are trying to enumerate definitions to > > impose > > > on something, rather than starting with the thing at hand and > > > exhausting any clues it may provide before moving on. This can > > lead to > > > serious and, in hindsight, embarrassing mistakes. > > > > > > In this case, we are dealing with '^^', a meaningless > > unpronounceable > > > symbol. Oh, but wait ... we also spell it 'xor', which I suppose > > is > > > often pronounced "ex or", which might be the source of the > > difficulty. > > > Because 'xor' stands for ... ... 'exclusive or'. Exclusive? > > It's not > > > hard to figure out what that means. Here are some of the > > relevant > > > dictionary definitions: > > > > > > Not allowing something else; incompatible: mutually exclusive > > > conditions > > > Not accompanied by others; single or sole > > > > > > So what does that say about proposing that xor(p1,p2,...) is true > > if an > > > odd number of p[i] are true? Other than that people should > > pronounce > > > these operators out loud more often? > > > > > > Clearly, xor is true iff *exactly* one of its arguments is true, > > and of > > > course it should return that argument (or bool::false if no > > argument is > > > true). > > > > > > That should now be so blatantly obvious that everyone should be > > > embarrassed for not having seen it immediately. But don't run > > from > > > embarrassment (or become defensive and attack the messenger) -- > > it's a > > > powerful tool (which is why we evolved to have it). It should > > cause > > > one to question one's thought processes and consider how to > > improve > > > upon them, which is all to the good, isn't it? > > > > Except that xor or ^^ is only a binary operation, there is no > > "xor(p1,p2,...)", only "p1 xor p2 xor ..." which can really only be > > > > understood if you add () to disambiguate the order that the binary > > ops > > are performed. Fortunately, xor is associative so it doesn't > > matter how > > you add the (), you get the same answer. Try it out, you will > > discover > > that "p1 xor p2 xor ..." is true iff an odd number of the p's are > > true. > > As long as you build "p1 xor p2 xor ..." out of binary xor ops > > that is > > the result you get. Computing parity is much more common that your > > > > multi-arg operation. Besides, all the literature about logic and > > circuit design define "p1 xor p2 xor ..." in terms of binary xor, > > so > > your trying to buck hundreds of years of consensus. > > Sorry, but you're quite wrong here, because that literature applies > to an associative operator, which Perl's xor is not. ((1 xor 2) xor > 3) == 3, while (1 xor (2 xor 3)) == 1. I again ask that you pay more > attention to the thing you're dicussing, rather than to simply > generate stuff out of your own head, so as to avoid trivial > embarrassing error. You wrote q(Try it out, you will discover that > "p1 xor p2 xor ..." is true iff an odd number of the p's are true) -- > this fails on two counts; 1) it begs the question, which was how "p1 > xor p2 xor p3" should be evaluated -- it can only be "tried out" if > that answer has already been decided upon; and it ignores the > context of the discussion in which it has been noted that the value > of "p1 xor p2" is either p1 or p2 or bool::false, but not "true". > > The literature on logic design treats n-ary exclusive xor as modular > arithmetic, which is natural to do since it is an associative > operator. But it provides no guidance as to the value of "1 xor 2 > xor 3", nor do your remarks, starting out with your claim that there > is no "xor(p1,p2,...)". The language is being defined, so such > claims are meaningless; there is no reason why xor cannot be an n-ary > function. My position is that it should either have its linguistic > meaning, or expressions of the form "p1 xor p2 xor p3" should be > disallowed, since there is no other natural meaning for it. > bool::true is not an acceptable result (unless one of p1, p2, or p3 > is bool::true), and simply picking one or the other of p1, p2, and p3 > when they are all true is arbitrary. All of which was obvious if you > were to follow my advice about problem solving.
