hull@hao.UUCP (Howard Hull) (12/30/84)
Dick Dunn @opus writes: >[Interesting side-side issue: You may have heard the quip that "Every >program has at least one bug and can be shortened by at least one ??? ?? ^^^^^^^^^ >instruction"--from which, by induction, one can deduce that every program >can be reduced to one instruction which doesn't work. IEFBR14, if written >as the obvious, single-instruction program " BR 14", does NOT work. I really like this! Where did you hear it? Only trouble is, it conflicts with my experience. Usually, when I find a bug, 1. Both decreases and increases in instruction count are likely by some number, the average being 2.71828182845904523536 The implication is that to avoid bugs, every program to do a function must be written in every possible way. To be absolutely sure that you have the solution in the bag, you must write a program to do everything there is to do, by writing a set of programs to do each thing. Then all of these programs must work together. The probability that they will do this is given by 1/(n factorial) in each case, where n is the number of ways to do each particular task. For some of you, the number of tasks, t, approaches infinity. The result will inescapably include both of the following: needed functions unnecessary functions that have been omitted that have been included Now then, if all of the above are properly combined, you have: UNITY (There is in each case, after all, always t only one *right* way to do everything!) The Result = Sigma _______________________________________ n=0 (n!) 2. The bug will be in a real-time program running under one of the Unix clones adapted for the purpose. The change in the program length will wreck something else, either spatially or temporally. 3. Because the numeric mentioned under [1.] above is greater than unity, and is also greater than the binary base, the average (program, data) length will grow (perhaps stochastically) faster than its intellegent content - in a very familiar way - the number of bits of address will crawl over the edge of any imaginable page size definition in a vernier fashion as the program is developed. 4. As a result of bug fixes, a program has some random probability of either vanishing completely, or of consuming the entire storage capacity of the machine. Which way it will go depends mostly on the rounding algorithm used in the (undocumented) arithmetic subroutines that came with the software, and the (erroneously documented) algorithm the mainframe manufacture used for the determination of which instructions will set, clear, or not molest the carry bit. :-) {ucbvax!hplabs | allegra!nbires | harpo!seismo } !hao!hull