Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!clyde.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!att!cbnews!cbnewsm!lfd From: lfd@cbnewsm.att.com (Lee Derbenwick) Newsgroups: comp.software-eng Subject: Re: Reusability considered harmful??(!!) Summary: incomplete spec sheets Message-ID: <1991Feb19.214713.403@cbnewsm.att.com> Date: 19 Feb 91 21:47:13 GMT References: <88431@tut.cis.ohio-state.edu> <6108@stpstn.UUCP> <1127@TALOS.UUCP> <88637@tut.cis.ohio-state.edu> Organization: AT&T Bell Laboratories Lines: 53 In article <88637@tut.cis.ohio-state.edu>, ogden@seal.cis.ohio-state.edu (William F Ogden) writes: > Lee Derbenwick writes: > .... > #The data book helps, but it still never does the complete job. The > #sine routine that someone else mentioned is a good example: its behavior > #was good enough on average, but its worst-case error happened to be > #around the most critical values for one application. The spec sheet > #is not normally going to give you a chart of error tolerance (or time > #delay, or whatever) vs. input values. .... > > I say that if you really want reusable software components, then > you're going to view a spec for a sine routine that doesn't include > error tolerances (or execution times, etc.) as simply inadequately > specified. > ... Error tolerances will normally be expressed in terms of average or RMS and worst-case errors. They are _not_ going to tell you, "By the way, the worst-case negative error is at 44 degrees and the worst-case positive error at 46 degrees." If you are concerned about values near 45 degrees, this may well be a problem. In fact, a discontinuity in the error might be a serious problem: are you also going to spec limits on the first derivative of the error? If, for your application, you spec the derivative of the error, what will you do when none of the spec sheets for available "sine-function parts" happen to mention it? In hardware spec sheets, you will probably find "typical" and "worst- case" delays. And you probably can't afford to design conservatively enough to use only worst-case delays; someone else will undersell you by half the price by figuring out how to avoid the worst-case conditions. (The terminal you're reading this on would probably stop working if all of its components suddenly started operating at their worst-case specs.) In the sine-function example, the significant cost may be execution time. You might have two sine function implementations readily available: a single-precision one that meets your execution time spec with acceptable RMS error; and a double-precision one whose worst-case error is guaranteed to cause you no trouble, but that you can't use because it's too slow. You have to try the single-precision one, but you may then discover that its worst-case error is exactly at your operating point. You can no longer use it, and you may have to roll your own rather than get any reuse. In many cases a spec sheet will be adequate; in many it will not give enough data about the exact operating conditions that concern you. -- Speaking strictly for myself, -- Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ -- lfd@cbnewsm.ATT.COM or !att!cbnewsm!lfd