|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 1:51 PM
Points: 32,906,
Visits: 26,789
|
|
Mike McIver (1/9/2011) Really . . . another ridiculous article! I am responding to this reader's reply to illustrate the problem. Misinformation breeds misinformation . . . STR is deterministic!!!!!!!!!!!!!!!!!! Look it up in BOL!
As for the article itself . . . I say again "KNOW YOUR DATA TYPES"! Float and Real should automatically catch one's attention. All values may not be represented in certain formats, e.g. one third cannot be precisely represented in decimal format . . . then saying decimal is flawed does not make one insightful.
"Bad Rounding" . . . Just how is it the article's author knows something that an army of PhD scientists and mathematicians have not realized after well over a half century of computer development?! Moreover, he then judges not just SQL Server but by implication virtually all software products in the world as having flaws. Among others, Float/Real is addressed by:
- The Institute of Electrical and Electronics Engineers - American National Standards Institute - International Organization for Standardization - International Electrotechnical Commission
Should we let them, electronics manufactures (INTEL & AMD), and all other software companies (ORACLE too) know they have "Bad rounding"? Finally, poor Sir Isaac Newton, the inventor of calculus, never realized he too had "bad rounding" . . . but he did say:
"But the errors are not in the art, but in the artificers. He that works with less accuracy is an imperfect mechanic; and if any could work with perfect accuracy, he would be the most perfect mechanic of all . . ."
From Philosophiae Naturalis Principia Mathematica, Author's Preface to the Reader, first published 5 July 1687.
The point that STR "MAY" be imprecise is valid. But, that being at the extreme margins, the article's tone and approach to the issue is presumptuous, and only serves to promote ignorance and misunderstanding.
Here' some advice, especially for the up and coming (it's free so you know what it's worth). This article demonstrates the "inside out view" problem. Making SQL Server or any other one software (or thing) your point of reference limits your potential. Instead develop an "outside in view". All the fundamental knowledge that went into in SQL Server was already discovered or invented. Take the time to do a small amount of "outside" research to develop breath and depth of knowledge. Do this every day . . . over time the effort pay$.
BWAA-HAA!!!... having a bad day, Mike?
It's totally amazing to me that you missed the whole intent of the article. A great number of users don't know that STR makes a conversion to float and that the related "imprecision" (which they will most certainly interpret as "bad rounding") will occur because the function gives no warning.
Take the same advice you dish out so readily. Look at things from a different point of view.
--Jeff Moden "RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Thursday, August 30, 2012 9:37 AM
Points: 44,
Visits: 202
|
|
Oh crap... I 'discovered' STR about a 18 months back and have been using it as LTRIM(STR(n)) for creating strings.
.... well, at least my old code was using cast or convert.
Thanks Jeff for bringing this to my attention.
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 1:51 PM
Points: 32,906,
Visits: 26,789
|
|
Jay Hopping (3/8/2011) Oh crap... I 'discovered' STR about a 18 months back and have been using it as LTRIM(STR(n)) for creating strings.
.... well, at least my old code was using cast or convert.
Thanks Jeff for bringing this to my attention.
Be careful, now. The code you've written may not produce computational errors due to rounding errors. Check it and make sure. As I indicated in the article, there are places where STR works just fine. And the performance problems of STR may not be a problem for you. If you're stuff is running quickly, there's no sense in possibly making a mistake with another code change.
It IS worth double-checking, though.
--Jeff Moden "RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following... http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following... http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|