Here's the same message, with less annoying word wrapping. (Especially useful for mailers that show different levels of quotes in different colours.)
Trewth Seeker wrote: > Mark A. Biggar wrote: > > Trewth Seeker 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 supppose 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. (signatures removed)
