Accessing and changing data 2008
-
I think it's interesting that, with nearly 1000 responses, the answers are nearly split 50/50. In general, this community does get the QotD right more often than not, so 50/50 reflects the fact that knowledgeable members got the "wrong" answer (which I think was correct - they are equivalent). However, the fact that 1/2 the respondents got the "right" answer suggests either that this question was more confusing than I initially thought, or that a lot of people have waited until the answers were posted to actually come and submit their response.
Just my 2 cents....
EricF
[font="Tahoma"]Eric Flamm, Flamm Consulting[/font]
-
GSquared (9/24/2008)
Don't worry about the English-language aspect of the question..
Agree with that, but it is a bit disturbing that we are now down to arguing about semantics. To me, being fluent in five languages, the words "same" and "equivalent" aren't really equivalent, but are used interchangeably in common use, which is fair enough.
By the definition being used to justify the answer on this one, neither query is equivalent to itself, since floating point operations are not guaranteed to give identical results in any circumstances.
Thus, the first query isn't equivalent to itself, and the second query isn't equivalent to itself, and neither is equivalent to the other. At least, per the post justifying the negative answer.
Like this statement. Geez, how will we ever be able to prove that our re-written statements or re-factored applications produce the same result as the original one.
Personally, I disagree with that, but that's obviously the intent here.
The question was on a good subject. I wasn't aware of that feature of 2008. Neat, potentially powerful feature. I can think of plenty of uses for it in reporting.
If that was the intent, then I think it was misguided. The objective of this site is to teach people about SQL, not about grammar. Admitted, it pointed one to a new feature in 2K8 T-SQL (of which I was aware by the way), but the question was stated so badly that a long thread like this had to develop. Not the first one in the last month or two that caused so much controversy.
But I do disagree with the answer and the justification for the answer
So do I.
Regards,
Jan
-
There is a remark in BOL saying 'Aggregates on floating-point numbers might return slightly different results.' Where in the question does it say that the sales column is a floating point data type? I typically use Numeric when needing decimal places.
Plus the two queries used in this question are ripped directly, ver-batim from BOL and BOL (under GROUPING SETS Equivalents) says they are equivalent. There is no explicit label that 'sales' is a floating point datatype in the BOL page either.
-
While the intention was good (showing new features of SQL Server 2008), I give up on the equivalent vs. same wording. maybe this is an intentional trap that obviously 50% of the respondent fell to. Maybe next time I should just wait till the answer comes out before I answer if the question smells fishy :w00t:
*turning off the notification for this thread... couldn't care less now*
-
BitBucket - Pls be carefull next time. We are here to discuss/debate SQL server and not language issues.
"Keep Trying"
-
Chirag (9/24/2008)
BitBucket - Pls be carefull next time. We are here to discuss/debate SQL server and not language issues.Well said and correctly pointed out....:)
-
Just about the first things I learnt about floating point numbers (over 35 years ago) was a) never compare actual equality, and b) actual results that are equivalent algebraicly can differ (e.g. A + B + C might not equal C + A + B, especially if A & B are 'large numbers' and 'A + B' & C are 'close to zero'.
So to say that the resulting datasets could be different with floating point point is spurious. In theory, running the IDENTICAL aggregate T-SQL statement on IDENTICAL rows with floating point data could give DIFFERENT resulting datasets if the rows are [processed] in a different order; i.e. the resulting datasets will be 'similar' but not 'identical'. In other words, they'll [usually] be 'close enough' for real-world applications.
SO GIMME MY POINTS!
Well, I get one for posting anyway - maybe I should just post again ...
-
I agree with everyone else. How am I supposed to know that "sales" is a float?
... there's 1 point back
-
... and there's my 2 points back!
-
I agree. Without the background of the question, either answer could be correct all hinging on the datatype which wasn't spelled out. If anything the QOTD's at least get us to look deeper into the product features and documentation, although it is nice when you get the answer correct, and in this case I believe the answer could be either.
-
The correct answer is "They are the same AND if you are using float type for monetary data, you should be summarily tarred and feathered."
-
I think, there is some mistake in the correct answer. Both the queries are same in the sense that they return same resultset. In the explanation of the question, it is said that they are 'equivalent' so the correct answer should be 'they are same'.
-
Hi
In the MSDN blog says both the code is same. But the answer returned in wrong.
could you please help us which one is correct ?
-
Ummm . . .
http://technet.microsoft.com/en-us/library/bb510427.aspx
:angry:
Am I missing something here?
+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/ -
GSquared (9/23/2008)
I know others have already objected on this one, but I decided to post anyway.ditto. I won't post the code I put together after blinking, with boggled mind, at the answer, because apart from making customers ints instead of strings and sales ints instead of money (is it the number of vacuum cleaners sold, or the sales revenue) and using different numbers it's the same as yours.
I have to disagree with the answer given, based on actual tests. I also tested it with the same test, using float instead of money for the sales data type, and still got the same results from both queries.
I think the person who wrote the question mistook the difference between "is the code the same" and "are floating point operations deterministic".
I think you've got that slightly wrong: the FP operations are indeed deterministic on a particular machine, but a string of such operations is not order-independent. Or are T-SQL floating point operations really indeterminate? - that would be quite startling! (Anyway, it can be argued that the result of calculation A is the same as the result of calculation B provided each is within the limt of the other's rounding error, so those apparent differences don't count. )
Tom
Viewing 15 posts - 31 through 45 (of 49 total)
You must be logged in to reply to this topic. Login to reply