O''''Reilly Network For Information About''''s Book part 166 potx

1. When all entries in the main object table have been checked, we report the results to the user. Assuming that the user wants us to rebuild the file, we start phase two. After opening a new quantum file where we will store the rebuilt file, we examine each quantum containing actual user data, skipping any quanta containing the main object table, big pointer arrays, and little pointer arrays. For each such user-data quantum, we extract the object number to which that quantum belongs, and add the elements in that quantum to the appropriate element of the corresponding object in the new quantum file, using the index number of each element as stored with the element. Chapter dynhash.htm 1. Modifications to add capabilities to the dynamic hashing implementation: 1. Deleting records is almost exactly the inverse of adding records. Every time the number of records decreases by the average number of records per slot, we take the storage element from the highest- numbered slot and combine it with the one from its buddy slot, placing the result back in the buddy slot. Then we decrease the active slot count by one. If the active slot count becomes equal to one-half of the allocated slot count, we halve the allocated count. 2. The main problem with duplicate keys is that since records with the same key will always wind up in the same storage element, they make it imperative to handle the overflow problem. Once that is solved, handling duplicate keys is easy: once you have located all storage elements that might contain records with that key, search each of them to the end, rather than stopping when you get a match. Of course, you then have to decide which record you want to use, but that's an application-specific problem. 2. This is a wonderful application for templates. Even the name of the class is intended to suggest that it could very easily be changed to PersistentArray<type>. Chapter zensort.htm 1. One fairly obvious way to handle the problem of improper key distributions for the "divide-and-conquer" versions of the program is to use the information gained in the first pass to determine which algorithm to use. If the keys are reasonably uniformly distributed, then the "divide-and-conquer" version will have the best performance and should be used; however, if the keys are not uniformly distributed, the program should fall back to an earlier version of the algorithm that will work properly and efficiently with a skewed distribution of keys. Footnotes 1. Hash coding can also be used to eliminate binary or linear searches through tables in memory. 2. Caching can also be used to reduce processor time during searches of tables in memory, as the most recently or most frequently referenced items from the table can be kept in a cache. 3. A remarkable example of such hyperconservatism is the following statement, from an otherwise fine book by Edward Yourdon: "As a programmer, you will always be working for an employer. Unless you are very rich and very eccentric, you will not enjoy the luxury of having a computer in your own home ". (emphasis in the original) Yourdon, E. Techniques of Program Structure and Design. Englewood Cliffs, New Jersey: Prentice-Hall, Inc., 1975, pp. 2-3. This clearly ranks with the worst predictions of all time. 4. An excellent explanation of this important mathematical discovery can be found in Douglas Hofstadter's book Goedel, Escher, Bach. New York: Vintage Books, 1979. 5. They're the ones with the arrows in their backs. 6. Interestingly enough, the previously cited passage in Yourdon's book goes on to say: "In short, you cannot be an artist, separate and aloof; it is highly unlikely that the programming community will ever generate a Michaelangelo or a Rembrandt". This is quite a difficult standard to meet: how many artists of this stature have come from any field, including sculpture and painting? While the jury is still out on this prediction, I think we will see a great artist of programming one of these days, although his or her work might be inaccessible to the lay public. 7. Why is memory only "almost" a true random access device? Because the processor is much faster than the main memory of the computer; therefore, frequently used memory locations are copied into much faster memory either on or very close to the processor itself. This means that accessing locations in widely scattered parts of memory is likely to be noticeably slower than sequential access to memory. However, the difference in speed may be a factor of three or four rather than the relative speed difference of hundreds or thousands of times that we see between sequential and random disk accesses, so optimizing memory accesses is not as great a concern to us as the latter problem. About the Author Steve Heller had always been fascinated by writing. In his childhood days in the 1950s and 1960s, he often stayed up far past his bedtime reading science fiction. Even in adulthood, if you came across him in his off-hours, he was more likely to be found reading a book than doing virtually anything else. After college, Steve got into programming more or less by accident; he was working at an actuarial consulting firm and was selected to take charge of programming on their time-sharing terminal, because he was making much less than most of the other employees. Finding the programming itself to be more interesting than the actuarial calculations, he decided to become a professional programmer. Until 1984, Steve remained on the consuming side of the writing craft. Then one day he was reading a magazine article on some programming-related topic and said to himself, "I could do better than that". With encouragement from his wife of the time, he decided to try his hand at technical writing. Steve's first article submission to the late lamented Computer Language Magazine was published, as were a dozen more over the next ten years. But although writing magazine articles is an interesting pastime, writing a book is something entirely different. Steve got his chance at this new level of commitment when Harry Helms, then an editor for Academic Press, read one of his articles in Dr. Dobb's Journal and wrote him a letter asking whether he would be interested in writing a book for AP. He answered, "Sure, why not?", not having the faintest idea of how much work he was letting himself in for. The resulting book, Large Problems, Small Machines received favorable reviews for its careful explanation of a number of facets of program optimization, and sold a total of about 20,000 copies within a year after publication of the second edition, entitled Efficient C/C++ Programming. By that time, Steve was hard at work on his next book, Who's Afraid of C++, which is designed to make object-oriented programming intelligible to anyone from the sheerest novice to the programmer with years of experience in languages other than C++. To make sure that his exposition was clear enough for the novice, he posted a message on CompuServe requesting the help of someone new to programming. The responses included one from a woman named Susan, who ended up contributing a great deal to the book; in fact, about 100 pages of the book consist of email between Steve and Susan. Her contribution was wonderful, but not completely unexpected. What was unexpected was that Steve and Susan would fall in love during the course of this project, but that's what happened. Since she lived in Texas and he lived in New York, this posed some logistic difficulties. The success of his previous book now became extremely important, as it was the key to Steve's becoming a full-time writer. Writers have been "telecommuting" since before the invention of the telephone, so his conversion from "programmer who writes" to "writer" made it possible for him to relocate to her area, which he promptly did. Since his move to Texas, Steve has been hard at work on his writing projects, including Introduction to C++, a classroom text that covers more material in the same space as Who's Afraid of C++? at the expense of the email exchanges in the latter book, followed by Who's Afraid of Java?. Their latest project is Who's Afraid of More C++?, which came out in 1998. Steve and Susan were married in 1997. • Table of Contents • Index • Reviews • Reader Reviews • Errata Oracle PL/SQL Language Pocket Reference, 2nd Edition By Chip Dawes , Steven Feuerstein , Bill Pribyl Publisher : O'Reilly Pub Date : February 2003 ISBN : 0-596- 00472-9 Pages : 127 The new edition of this must-have pocket guide boils down the most vital information from Oracle PL/SQL Programming, the bestseller that many consider "the Bible" for PL/SQL development. This concise booklet summarizes features available in Oracle's powerful new product Oracle9i and provides essential information on PL/SQL block structure, fundamental language elements, control statements, and use of procedures, functions, packages, triggers, Oracle objects, external procedures, and methods of calling Java classes from PL/SQL. . distributions for the "divide-and-conquer" versions of the program is to use the information gained in the first pass to determine which algorithm to use. If the keys are reasonably uniformly. interested in writing a book for AP. He answered, "Sure, why not?", not having the faintest idea of how much work he was letting himself in for. The resulting book, Large Problems,. boils down the most vital information from Oracle PL/SQL Programming, the bestseller that many consider "the Bible" for PL/SQL development. This concise booklet summarizes features