The Truth Table

  • Comments posted here are about the content posted at http://www.sqlservercentral.com/columnists/yEkhtiari/2903.asp

  • I've never used this xml procedure before so it would really be nice if the author had used a decent coding style to make it easier to read. This is especially true when it comes to dynamic SQL. So, I'll just pack it off to my sandbox and figure it out there.

  • we're not all mathematical genius you know

  • Found the proc and concept interesting, but had a few issues.  The syntax of the proc statement wasn't explained at all, and it would have taken five seconds to explain some of the newer functionality.  The point of the exercise wasn't fully explained, and the values in the end product were nebulous. Obviously the author knows more than I do, but the point of the exercise was to learn not to show off. 

  • I would not have minded a bit more explaination on the syntax, but that I work around.  I would have liked some idea/example of how this is used though.  Seems like an academic excercise?

  • I didn't get the impression that the author was trying to show off, and most of the comments are well founded, but I especially agree with the "answers were nebulous" comment.  I can go look up syntax and new functions but it would be nice if the author would provide a follow-up with a few examples where this finely-tuned result set would save us time elsewhere.

  • This article does not mention an important thing, namely that SQL (at least MS SQL) has no just 2 truth values but 3: true, false, and unknown(*). 'unknown' may stem from comparing NULL values (**), among other things. Boolean operators work as you'd expect if you interpret "unknown" as "don't know whether true or false" or "maybe true maybe false": true AND unknown = unkown (since the value of 'true AND x' depends on whether x is true or false); true OR unknown = true (the value of 'true OR x' is 'true' regardless of x); etc.

    (*) not sure what's the official name for that 3rd value.

    (**)

    e.g.

    select 'error'

    where 0 = NULL

    returns nothing, not because 0 = NULL evaluates to "false", but because 0 = NULL evaluates to "unknown". Indeed, the "opposite" condition also returns nothing:

    select 'error'

    where not (0 = NULL)

    because '0 = null' evaluates to 'unknown', then 'not (0 = null)' evaluates to the logical negation of 'unknown' which is again 'unknown'.

  • A few years ago, I was trying to figure out how 9 combinations of activities, 9 "if this, then that" trials and all their combinations, caused certain events to happen in a help desk developed by a major company. Their engineers couldn't answer my questions as to why I was getting an odd result when certain actions were combined. I decided to hand-build a truth table to show each possible case (in between my regular job duties) and after a month was able to show that a certain sequence of events gave a "predictable" but undesirable result that no one had anticipated. I sent the tables to the engineers and they fixed the "bug" Since the possible results of a set of actions grow exponentially, if I had had this procedure I would have saved myself hours (days) of work! Thank you for the procedure - it's a great help so, absolutely, keep showing off!!!

  • I also declare myself ignorant, and read the article looking for a practical everyday application. Not that the article wasn't interesting and valid, it's just that you normally expect a general and pragmatic application for most articles you see on this site... That being said, I'm sure that anybody in this specific field would appreciate the article, and being able to use SQL to tackle this problem.

    Probably the first thing to do is to learn more about what a Truth Table is: http://en.wikipedia.org/wiki/Truth_table The Wikipedia mentions that it is used in digital/electronic design as an alternative to logic gates or code, including the design of a bit adder. I remember building a 4 bit adder (or was it 2 bit?) in college using logic gates, and I can see how having a truth table could have been useful in debugging it (maybe having expresions for intermediate outputs). The Wikipedia article has links to a couple online truth table generators, in case you require generating such a table, and don't have a SQL server handy to run the code in the article...

  • I found the article generally interesting. As a tester, I often need to build truth tables and this tool could come in handy.

    However, I've never come across the "IMPLIES" operator before. The article gives:

    Implies P IMP Q ~P | Q

    What exactly does this mean? From the meaning of implies, I would expect it to mean:

    1. If P is true then Q must be true.

    2. If P is false, then Q may be true.

    But, given the logic, I have no idea where he's trying to go.


    Steve Eckhart

  • There are times where you can store flags in one column - these are bitwise flags 1 2 4 8 16 32 64 etc

    This can be very handy - if you dont know why - then dont comment.

    It could well be that are occasions where this generic code could be very useful too.

     

     

     

  • A little leisure reading for those of you that may be a little rusty on the topic of propositional logic:

    http://www.earlham.edu/~peters/courses/log/terms2.htm

    Although lacking a specific example of its use, the article was well done.  It allowed me to dip my toe in the XML pool without drowning at the same time bringing back memories of coding in i8080A machine language, front panel switch input and LED output on my IMSAI 8080 (31 years old & still kickin')!

    An understanding of low level topics such as logic, binary (octal & hex, too), discrete electronics, relational math, etc. has made life a great deal easier as a programmer and as a DBA.  Do not dismiss the basics!

    ...and yes, the Bowmar Brain was a wonderful tool but it would not have been nearly as valuable without the understanding of manual cypherin' (as Jethro Bodine would say).  Try your hand at a little long division, square roots or bit masking.  It will go a long way to improving your understanding of what those electrons are really doing in there!

    Just my $0.02

  • I would like to thank you for your comment especially Cheryl Marsh .

    I did not mean to show off myself,I just wanted to share my Idea with you.

    If you have seen my previous article,you may find that the idea behind this procedure code is self-explanatory.

    I knew that there is a 3rd value for bit that is UNKNOWN,but there are only 2 values

    in propositional logic :true and false ,not more,so I did not need to deal with UNKNOWN

    values.

    consider the following table:

    create table #stu(

    id int,

    sex char(1) check( sex in( 'm','f')),

    grade char(1),

    courseTaken int

    )

    we are asked to make a report that show all the students with

    these conditions:

    if the student has a score='a' then sex must be 'f' .

    if the student has a score='b' then courseTaken must be greater than 7.

    so the question implicitly says that the other students that do not meet aforementioned

    condition should be in result set

    since there is no Implies operator in SQL you need to use the following formula

    p IMP Q==~P | Q

    if you call

    insert #stu

    select 1,'f','a',4

    union all

    select 2,'m','a',10

    union all

    select 3,'f','b',8

    union all

    select 4,'m','a',5

    union all

    select 5,'f','c',6

    union all

    select 6,'f','b',5

    union all

    select 7,'f','c',6

    select *

    from #stu

    where (grade'a' or sex='f')

    and (grade'b' or courseTaken>7)

    drop table #stu

    I do agree this is not a clear example, but I have used it more often than not ;hope it gives you some idea

    when implies operator will come in handy.

    --Yousef Ekhtiari

  • Here's how to write xml entity replacements in html:

    &

    <

    >

    "

    '

    This will display as:

    &

    <

    >

    "

    '

  • we are asked to make a report that show all the students with

    these conditions:

    if the student has a score='a' then sex must be 'f' .

    if the student has a score='b' then courseTaken must be greater than 7.

    I think this is an unclear method of stating a business requirement. If I were to receive this as my requirements with a request for all rows that violate this rule, I would write;

    SELECT id, sex, grade, courseTaken
    FROM #stu
    WHERE
        (grade = 'a' AND sex != 'f') -------- those that fail the first condition
     OR (grade = 'b' AND courseTaken <= 7) -- those that fail the second condition
    

    (~P | Q) for the first rule would read

    "IF the student does not have a score of 'a' THEN sex may or may not be 'f'"

    And those that satisfy this test (anyone with out a grade of 'a') are not in violation of the original first rule. They are in compliance by implication. The issue is, that the only way the rule can be broken is if the condition is met and the expectation is not met. If the condition is not met, then there is no expectation...

Viewing 15 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic. Login to reply