Inspired by a mention of truth tables here (Thanks Mike), which reminded me of an old blog post of mine. --Paddy3118 07:24, 31 October 2011 (UTC)

Always glad to inspire :). --Mwn3d 13:16, 31 October 2011 (UTC)

Which operators?

Just to get ahead of a possible question, which operators should this program support? And, or, and not are pretty much locks, but do we need implication operators? Xor? --Mwn3d 13:16, 31 October 2011 (UTC)

And, or, not as a minimum; but if the rest are just more of the same then they could be left out for brevity. --Paddy3118 14:06, 31 October 2011 (UTC)
From a website I found, the ^ boolean operator is an AND and almost all examples here seem to use it as as the   XOR operator. This same website didn't even mention (or use) the & [AND] operator. The list that I used is in the REXX example. I'll change it if the consenus say that's incorrect, since there seems to be a very heavy   influence in Rosetta Code. I think it may be better to have consistency in the coding and examples. -- Gerard Schildberger 20:16, 28 April 2012 (UTC)
In C, ^ is the bitwise XOR operator. --Kernigh 20:40, 28 April 2012 (UTC)
I've changed the REXX coding example to comply with  
They probably used ^ for and to go along with the   and   operators from discrete math. I think it's fine to use whatever standard you like as long as you note it. --Mwn3d 00:07, 29 April 2012 (UTC)
I was wondering why the website I visited used a lowercase v --- it was modeled after the   character (disjunction). Conjunction is the   charcter. -- Gerard Schildberger 07:01, 30 April 2012 (UTC)
As for which boolean operators to support, the task description is (to me) pretty clear: boolean equation(s) are all or any boolean expression(s), whether or not your language of choice only supports two or three (or a few more). I've included all sixteen boolean operator names in the REXX language example; I hope the boolean operations are named correctly, there are many variants). Also added is support for the TRUE and FALSE boolean values, as well as boolean conditionals (comparisons). -- Gerard Schildberger 06:24, 30 April 2012 (UTC)
If anyone thinks the REXX example is too long, I could delete some of the boxed comments and put them here instead. But I thought the boolean operator names needed listing. -- Gerard Schildberger 06:35, 30 April 2012 (UTC)

Incorrect example

Why is the Déjà Vu example incorrect? AFAIK, it does exactly the same thing as the D and Go examples. --Gvx (talk) 14:35, 21 November 2013 (UTC)

Hi Gvx, I took a look and it seems that all three are incorrect for the same reason. You could look at the history of the page and find what the first few examples do, but in this case I think the task description does state that it wants the input of an expression to be parsed and evaluated. Some languages have that built-in; for others there is the hint of the mention of reverse-polish or infix evaluators.
If marked incorrect (or left out completely), it signals that a correct examples is needed. --Paddy3118 (talk) 08:00, 22 November 2013 (UTC)
This might help. --Paddy3118 (talk) 08:06, 22 November 2013 (UTC)
I agree with what Fwend said below. It seems to me that this is actually two tasks: Parsing a boolean expression and Printing a truth table. There are several other tasks on RS that are closely related, like Queue/Definition and Queue/Usage — and I think it makes more sense to split this one than the queue task. I'll rewrite the Déjà Vu example if we can't convince you. :) --Gvx (talk) 21:17, 5 December 2013 (UTC)

Incorrect title?

We could also mark the title of this task as incorrect, because what on earth has building a (not very robust) parser have to do with truth tables.Fwend (talk) 14:55, 22 November 2013 (UTC)

Most of the work might be in creating the parser if your language does not come with a suitable one. Other languages make that easy. The task title seems accurate to me? --Paddy3118 (talk) 05:40, 23 November 2013 (UTC)
Return to "Truth table" page.