supposed to when—bang!—it breaks. With a bit of debugging and a bit of time in the lab I can explain what’s broken to the vendor. I even have source code for the driver so I can patch it when I understand what’s broken and send them patches; sometimes they send me patches.
It’s the part where they send me patches that has been a bit more interesting. I had been faithfully applying patches from the vendor and testing their fixes and I kept getting this sneaking feeling that they were not testing the patches before they sent them out. I had that feeling not just because I’m a naturally paranoid and suspicious person, which I am, but because each patch would fix say, only 70% or 80% of the problem and then I’d have to provide the remaining bit of the fix. Finally, I got a patch that proved that although I am paranoid, it is not without reason. I applied a patch and it didn’t compile: the C keyword struct had been spelled incorrectly. Ha! I had them. They had not even applied their own patch; they were just
sending me hacked bits of the driver that they thought would work. All I could think was, “Did you even compile this!?!?” But of course I already knew the answer.
Now I don’t bring this up just because I like to say, “I told you so,” because I don’t. I’d much prefer the code I received worked the first time, since my employers expect the same from me. I bring this up as yet another example of unwarranted programmer optimism.
People who send out a “small patch” without even compiling it are far too confident in their own abilities. Please! Stop! Don’t do that! I don’t care if you see bits in your dreams and they assemble correctly in the morning when you type them in. The amount of time you waste by not doing the most basic tests on code you’re patching isn’t only your own; it’s multiplied by all the hapless suckers who took your patch and tried to use it.
Returning to my earlier remark, I would have thought this was obvious—as obvious as how to spell “struct”—but I have discovered this is not the case.
George V. Neville-Neil ( kv@acm.org) is the proprietor of neville-neil consulting and a member of the ACM Queue editorial board. he works on networking and operating systems code for fun and profit, teaches courses on various programming-related subjects, and encourages your comments, quips, and code snips pertaining to his Communications column.
copyright held by author.
HANDBOOK OF Statistical Analysis
Data Mining Applications
authors:
Robert Nisbet, PhD
Pacific Capital Bank Corporation
Santa Barbara, CA, USA
John Elder, IV, PhD
Elder Research, Inc.
Charlottesville, VA, USA
Gary Miner, PhD
StatSoft, Inc.
Tulsa, OK, USA
The Handbook of Statistical Analysis and Data Mining Applications is a comprehensive professional reference book for business analysts, scientists, engineers and researchers that brings together in a single resource all the information a beginner will need to rapidly learn how to conduct data mining and the statistical analysis required to interpret the data patterns once mined.
“If you want to roll-up your sleeves and execute on predictive analytics, this is your definite, go-to resource. To put it lightly, if this book isn’t on your shelf, you’re not a data miner.”
— Eric Siegel, Ph.D.,
President, Prediction Impact, Inc., San Francisco, and Founding Chair, Predictive Analytics World
key features:
• Provides key statistical analysis methods
• Clearly describes modern algorithms for AI/Machine learning
• Practical advice from successful real-world implementations
• Includes extensive case studies, examples, tutorials, MS PowerPoint slides and datasets
ORDER TODAY & SAVE 15%
May 2009, Hardcover, 900 pp
ISBN-13: 978-0-12-374765-5
List Price: $89.95/£ 45. 99 /€ 57. 95
Use offer code 94637 when ordering.
2M90104_HA_Nisbet_050_1200_Amstat.indd 1
elsevierdirect.com
3/5/09 11:06: 25 AM
References:
Archives