August 7, 2008 at 8:23 am
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.
August 7, 2008 at 8:38 am
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]
August 7, 2008 at 9:04 am
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]
August 7, 2008 at 9:18 am
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!
August 7, 2008 at 9:42 am
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)
August 7, 2008 at 9:43 am
And then I found this forum post from May!
August 7, 2008 at 9:57 am
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
August 7, 2008 at 11:39 am
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.
August 7, 2008 at 11:51 am
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]
August 7, 2008 at 11:57 am
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]
August 7, 2008 at 12:46 pm
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.
August 7, 2008 at 2:04 pm
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.
August 7, 2008 at 5:28 pm
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
August 7, 2008 at 5:44 pm
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