Exponent Engima

  • I have to admit, I was totally distracted by the caret, and didn't even consider bitwise ops. Nice distraction.

    There are problems with the question, though.

    Why is @b-2 declared and never used?

    Where is @b-17? Answer B cannot be correct

    Answer A is not just a distraction, it's wrong to include the "=2^64" because you are deliberately misleading us. A much better A would have been "16^16 is out of range for the bigint datatype' which [in hindsight] is clearly not true.

    Still, a nice question. BOL should be updated.

  • Festeron (8/7/2008)


    There are problems with the question, though.

    Why is @b-2 declared and never used?

    Where is @b-17? Answer B cannot be correct

    Yikes! You are right, "@b" shouldn't be in there and Answer B should read "@a-17...". Fortunately, it doesn't change the correct answer.

    Answer A is not just a distraction, it's wrong to include the "=2^64" because you are deliberately misleading us. A much better A would have been "16^16 is out of range for the bigint datatype' which [in hindsight] is clearly not true.

    Yes it is trying to mislead you by playing on the mistaken assumption that "^" is the exponent operator, just as the Title is. However, that is the whole point of the Question: it is a mistaken assumption and if you do not figure that out, you will come to the wrong conclusion.

    And after all, (A) is an incorrect answer, whether it is incorrect for one reason or two (and both the same reason at that) doesn't really matter.

    [font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
    Proactive Performance Solutions, Inc.
    [/font]
    [font="Verdana"] "Performance is our middle name."[/font]

  • so, would this be the proper expression if it were really an exponential question?

    DECLARE @a BIGINT

    , @b-2 BIGINT

    SET@a = 16

    SELECTSQRT(POWER(@a,@a - 17))

    bc

    [font="Arial Narrow"]bc[/font]

  • Almost:

    DECLARE @a BIGINT

    , @b-2 BIGINT

    SET @a = 16

    SELECT SQRT(POWER(@a,@a) - 17)

    and this will give an overflow error.

    [font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
    Proactive Performance Solutions, Inc.
    [/font]
    [font="Verdana"] "Performance is our middle name."[/font]

  • No argument on the format, trick or the answer. After one of the earlier questions last week that was a slight bit tricky I looked real close and got it right.

    You got to be careful to be right. But that is the way business is isn't it? 🙂

    Thanks

    Miles...

    Not all gray hairs are Dinosaurs!

  • Good question, the bitwise XOR ^ made this a school day for me (always good). Once I took out the -17 it became clear that sqrt (n^n) (n is any integer) returned 0 rather than a positive number; meaning that the -17 caused the error. It also explained why the first answer was wrong.

    And then it was simple to assume that Sql 2005 didn't like imaginary numbers (which is what I remember calling square roots of negative numbers back in the day).

    And so the fault can also be achieved by:

    select sqrt(-17)

  • And then I found this forum post from May!

    http://www.sqlservercentral.com/Forums/Topic239436-8-1.aspx

  • Hi,

    Good Question!!!! For once answered correctly.

    I would love to see i and other mathematical imaginary features and operations in SQL Server just a little bit more complex than listed in the today's article "Calculating Mathematical Values in SQL Server"

    http://www.mssqltips.com/tip.asp?tip=1547

    that discussed 1*1

    As for the possible other answer that should be listed: "Bug in documentation"

    Regards,Yelena Varsha

  • rbarryyoung (8/7/2008)


    Festeron (8/7/2008)


    There are problems with the question, though.

    Why is @b-2 declared and never used?

    Where is @b-17? Answer B cannot be correct

    Yikes! You are right, "@b" shouldn't be in there and Answer B should read "@a-17...". Fortunately, it doesn't change the correct answer.

    Answer A is not just a distraction, it's wrong to include the "=2^64" because you are deliberately misleading us. A much better A would have been "16^16 is out of range for the bigint datatype' which [in hindsight] is clearly not true.

    Yes it is trying to mislead you by playing on the mistaken assumption that "^" is the exponent operator, just as the Title is. However, that is the whole point of the Question: it is a mistaken assumption and if you do not figure that out, you will come to the wrong conclusion.

    And after all, (A) is an incorrect answer, whether it is incorrect for one reason or two (and both the same reason at that) doesn't really matter.

    I got totally caught with the @B. I actually knew that the '^' was the exclusive or operator and not the EXP operator but I took @b-2 to be the result of @a^@a, in which case the expression evaluates to 0-17 = -17. This just confused me more because there are two correct answers with this assumption and, of course, I picked the wrong one.

  • Melville (8/7/2008)


    Good question, the bitwise XOR ^ made this a school day for me (always good). Once I took out the -17 it became clear that sqrt (n^n) (n is any integer) returned 0 rather than a positive number; meaning that the -17 caused the error. It also explained why the first answer was wrong.

    And then it was simple to assume that Sql 2005 didn't like imaginary numbers (which is what I remember calling square roots of negative numbers back in the day).

    And so the fault can also be achieved by:

    select sqrt(-17)

    Great job, Melville. One of my goals was to ask a question that could not be answered by just copying the text into a Query window and executing it, but that could be answered without an encyclopedic knowledge of SQL Server, just using good problem-solving skills. I'm glad to see that that worked for at least some people!

    [font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
    Proactive Performance Solutions, Inc.
    [/font]
    [font="Verdana"] "Performance is our middle name."[/font]

  • Folks:

    For What It's Worth: I sincerely doubt that I would have gotten this question right myself. I am pretty sure of that because I have actually tripped over several times myself in the course of my work.

    In fact, that is what inspired me to use it (the assumption that "^" is the exponent operator) as the basis for a QotD.

    [font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
    Proactive Performance Solutions, Inc.
    [/font]
    [font="Verdana"] "Performance is our middle name."[/font]

  • Allof you, you have had wrong! I know from school, and everybody knows, that sqrt function did not support negative numbers (except complex numbers). But with this in your mind, you will be wrong in computers world. You should be guided by documentation of language. And this documentation is clear enough: sqrt supports negative float numbers. I know, you will say about ansi sql and other stuff like superior programming languages. But this issue is obviously clear.

    In Theory, theory and practice are the same...In practice, they are not.
  • Sorin Petcu (8/7/2008)


    Allof you, you have had wrong! I know from school, and everybody knows, that sqrt function did not support negative numbers (except complex numbers). But with this in your mind, you will be wrong in computers world. You should be guided by documentation of language. And this documentation is clear enough: sqrt supports negative float numbers. I know, you will say about ansi sql and other stuff like superior programming languages. But this issue is obviously clear.

    No... because SQRT returns a float.

    AND THE FLOAT DATATYPE DOES NOT SUPPORT COMPLEX/IMAGINARY NUMBERS.

    Hence SQRT cannot receive a negative number as an input and a domain error will occur because the result of the SQRT(-1) or SQRT(-.01) is outside of the domain of a FLOAT datatype.



    --Mark Tassin
    MCITP - SQL Server DBA
    Proud member of the Anti-RBAR alliance.
    For help with Performance click this link[/url]
    For tips on how to post your problems[/url]

  • So two things crop up here,

    1) how do you raise a number to a power in SQL server?

    and

    2) was the misspelling of enigma deliberate ( the author has used "Engima")

    Tim Brimelow

  • tim_brimelow (8/7/2008)


    So two things crop up here,

    1) how do you raise a number to a power in SQL server?

    and

    2) was the misspelling of enigma deliberate ( the author has used "Engima")

    Ah, now those I can answer:

    1) POWER(x,y) function.

    2) Nope. This is the first time that I noticed it. Good catch.

    [font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
    Proactive Performance Solutions, Inc.
    [/font]
    [font="Verdana"] "Performance is our middle name."[/font]

Viewing 15 posts - 16 through 30 (of 52 total)

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