bluuebunny/crossref_metadata_2025 huggingface dataset:
Equivalence checking between behavioral and RTL descriptions with virtual controllers and datapaths
Authors: Fujita Masahiro
Published: February 2006

In this article, we present techniques for comparison between behavioral level and register transfer level (RTL) design descriptions by mapping the designs into virtual controllers and virtual datapaths. We also discuss about how the equivalence between behavioral level and RTL designs can be defined precisely using the proposed “attribute statements” in an interactive fashion. Implementation issues as well as considerations on real life industrial design examples are also presented.
Using 2-domain partitioned OBDD data structure in an enhanced symbolic simulator
Authors: Feng Tao , Wang Li-C , Cheng Kwang-Ting (Tim) , Lin Chih-Chang (Andy)
Published: February 2006

In this article, we propose a symbolic simulation method where Boolean functions can be efficiently manipulated through a 2-domain partitioned OBDD data structure. The functional partition is applied by automatically exploring the key decision points implicitly built inside a circuit. The partition can help to significantly reduce the OBDD sizes, solving problems that could not be solved with monolithic OBDD data structure. We demonstrate the performance of the approach through the symbolic simulation of several benchmark circuits with complex control logics and datapath. The symbolic simulation based on 2-domain partitioned OBDD can be also applied in equivalence checking. It can generate the signature of functions to identify the critical partition points in the optimized gate-level netlist.
Test chip experimental results on high-level structural test
Authors: Al-Yamani Ahmad A. , McCluskey Edward J.
Published: February 2006

Using complex (high-level) gates, such as multiplexers, full adders, etc., for automatic test pattern generation (ATPG) has several advantages. It makes ATPG faster and potentially reduces the size of the test set that needs to be applied. A variety of other techniques are used to reduce the size of test sets for digital chips. They typically rely on preserving the single-stuck-fault coverage of the test set. This article presents data obtained from applying a variety of test sets on the ELF35 test chip and recording the test escapes. The data presented show the test quality effect of using complex gates as fault sites. The article also shows the impact of test compaction and reduced fault coverage on the test quality.
An event-based monitoring service for networks on chip
Authors: Ciordas Calin , Basten Twan , Rădulescu Andrei , Goossens Kees , Meerbergen Jef Van
Published: February 2006

Networks on chip (NoCs) are a scalable interconnect solution for multiprocessor systems on chip. We propose a generic reconfigurable online event-based NoC monitoring service, based on hardware probes attached to NoC components, offering run-time observability of NoC behavior and supporting system-level debugging. We present a probe architecture, its programming model, traffic management strategies, and a cost analysis. We prove feasibility via a prototype implementation for the Æthereal NoC. Two MPEG NoC examples show that the monitoring service area, without advanced optimizations, is 17--24% of the NoC area. Two realistic monitoring examples show that monitoring traffic is several orders of magnitude lower than the 2GB/s/link raw bandwidth.
An approach towards detailed documentation
Authors: Farber Andrew R.
Published: February 2006

In two previous articles, methods for writing maintenance documentation from program listings were presented. An index card for each module (main program or subroutine) was made showing its vital statistics. This was information giving the module name, a short (one-line) description of the module, the subroutines it called, if any, and a list of the files accessed by the module, from these cards a system data flow chart was drawn. Documentation for each program was then written. This documentation contained a data flow chart for the individual program plus a program description which varied in detail from a short narrative on the functions of the routine to a detailed flow-chart or pseudo-code description.
Program description language as a documentation tool
Authors: Sachs Jonathan
Published: February 2006

My employer maintains a data base used for consumer credit history checks by credit bureaus in over fifty U.S. cities. The data base receives data from several thousand credit grantors.
Standards?
Authors: Patterson Diana
Published: February 2006

I have this fear of standards, I'd like to talk about. They say talking about your fears helps, so, please bear with me.
Variations on HIPO
Authors: Rigo Joe
Published: February 2006

The chart on this page is one of several variations on HIPO that are turning up in business applications. This one combines the HIPO diagram with the traditional system operations chart. If you know of other variations, send a copy of one to the newsletter.
23rd International Technical Communication Conference, "Meeting the Challenge of Economic Reality"
Authors: Patterson Diana
Published: February 2006

In aid of cross fertilization I'll attempt to bring you the best genes from this May Conference, particularly since our own Trish Durr was a participant. Most sessions dealt with the practical information: editing, graphics and management, based on the notion that in days of tight budgets, you have to be good to keep your job. Many of the ideas here are gleaned from several papers.
Temps Perdu
Authors: Bethke Frederick John
Published: February 2006

No, Temps Perdu is not the meteorologist brother of Frank, the tender chicken man. It is a French swan's way of saying "lost time."
Achieving user-oriented documentation
Authors: Standley Hilda
Published: February 2006

The term "user-oriented" is impossible to define in an absolute sense. At best it can be used as a relative measurement, i.e., "something is more user-oriented than something else." I will by-pass any sort of definition -- much has been said already, check lists have been constructed, etc. -- and attempt to bring this idea into some sort of workable focus. How is "it" attained?
The reverse pamphlet document scheme
Authors: Patterson Diana
Published: February 2006

All documentation must be readable. Much of it isn't.
An approach to office simulation
Authors: Leavenworth Burt
Published: February 2006

Future Office Systems will incorporate a variety of interactions among people involved in these systems and between people and a variety of machine and computer facilities. We have already seen some reorganization of the traditional office structure based on the word processing/administrative support center concept.
Come to where the action is
Authors: James Glenna
Published: February 2006

When Eliza Doolittle sang (My Fair Lady) of being sick of words, she claimed there wasn't one she hadn't heard. Well, Eliza, there is one I've heard (read) for too often: 'utilize'.
The ¶ key
Authors: Sachs Jonathan
Published: February 2006

Last year I wrote an article in with this title. To summarize it for those of you with short memories or recent memberships: text formatting people are used to text formatting programs which do everything in response to commands like  /p .s 3; and they think such commands merely natural.
Supplementing IBM manuals
Authors: Bergeron Tom
Published: February 2006

I like IBM manuals. I think they take some unfair criticism from people, particularly those in Tech Writing seminars, who don't understand the problems their authors are up against (and often enough, have never written a full-size tech manual).
Prefatory material
Authors: Patterson Diana
Published: February 2006

People use books in vastly different ways. Some start at the front, some at the back, and some open to a random place and begin to read. I have noticed that very few people ever read anything before "Chapter I." This was brought home to me recently when I read a book which had1. a dedication,2. an advertisement,3. a table of contents,4. a preface,5. appendices (A & B) to the Preface,6. a preface to the Third Edition, and 7. an Introduction.
The challenges of documenting everything
Authors: Patterson Diana
Published: February 2006

About a week ago, I had a nightmare that a DP manager was talking to me on the telephone telling me his problems: He had some old system, and some new system in the works; the analysts were using all of the latest structured techniques, and yet somehow everything in both maintenance and design was in chaos. The nightmarish part of the dream was that I was promising that I could write him some reports for upper management on his problems and that I could pin down his new design in another document for user approval; but he would have none of it. He had serious problems and he wanted them solved. All I could offer was documentation, and that just wasn't what he wanted. I felt so helpless, and yet I felt that I had the right solution!
Educating the DP technical writer
Authors: Brantley Daniel
Published: February 2006

A skilled DP specialist with equally developed writing ability is not found around just any corner. Yet the need to communicate effectively will not go away.
More on errors, or, moron errors
Authors: Kuch T. D. C.
Published: February 2006

Diana Patterson (January, page 5) discussed "The index horror", or the results of trying to simulate alphabetical order by means of ordinary character-by-character computer sorting. Her example was "Workspaces" preceding "WAIT". Her diagnosis was the failure to equate upper and lower case forms of the same letter. But hold on, it gets worse.
Making programmers pro-grammar
Authors: Rowlett Frank B.
Published: February 2006

The most distasteful job that can be given a programmer is requiring him to document his program. When he finally completes the documentation, it usually is unsatisfactory. Why?
Documentation in the college environment
Authors: Burghard Edward M.
Published: February 2006

It is an unfortunate, but true fact, that many student programs possess the same quality of vagueness as the book in the above quote. It could take years to decipher exactly what the code means. I say this is unfortunate because these same students are the source for future business programmers.
Notes on hiring
Authors: Patterson Diana
Published: February 2006

This is not the sort of stuff Joe Rigo thinks is "hard core" technical writing, but when you see a bungled job you know it will have a telling effect on a long line of documents. In the last three weeks I have watched a nouveau publications department manager and a personnel officer hire two writers and a repro typist/terminal operator. They did it totally without consultation and without writing or typing samples. The terminal operator was chosen because she was a "good looker", one technical writer on his interview handling abilities, the second because her father is an author. None of them has any functional idea about what the job he has been hired to do entails.
Naming data items
Authors: James Douglas E.
Published: February 2006

Naming data items is the art of converting well-defining descriptions of data items into meaningful names. The data name is made meaningful by including essential elements of the description in the data name and by a consistent ordering of those elements.
AUTO-MA-TIC WORD DI-VI-SION
Authors: Huyser Steven L.
Published: February 2006

In a computerized word processing environment it is common to find the software performing pseudo-editorial tasks, the most prevalent of which is the automatic division of words at the end of justified lines. The purpose of such automatic word division is the minimization of white space in the copy while still maintaining a high degree of readability.
Formatters/editors
Authors: Patterson Diana
Published: February 2006

I've been using a text composer from the University of British Columbia for the last six months or so, and I'm quite pleased with it. It is called FMT, and is very similar to John Ehrman's FORMAT, but is a complete rewrite (in System/360 Assembler Language not FORTRAN) and is much more powerful. Among its more interesting features are a "macro" facility something like the Generalized Markup Language in ATMS; a facility for numbering and composing footnotes; and sets of functions that can be used to generate indices and tables of contents.
In the beginning...
Authors: Farber Andrew R.
Published: February 2006

This is, hopefully, the first article of a series that will explore different techniques of documentation. Rather than discussing the multitude of textbook methods, I intend to stay with the practical ways that I have either used myself, or seen work firsthand. Aas usual, any response from you will be more than welcome--my immediate experience is by no means all-encompassing.
A documentation format for fortran programs
Authors: Jackson Gordon D. D.
Published: February 2006

This article reports one aspect of work I performed (1) while undertaking research for a PhD at Imperial College, University of London.
Documentation for the user
Authors: Swanson Trevor , Arheart Kristopher L.
Published: February 2006

Providing information for users is an omnipresent problem in most computer service organizations. Documentation is continually produced to fill the information gap. There is a constant attempt to keep "old hands" aware of new systems as well as changes to vintage systems. At the same time, computer services must communicate with potential users to make them aware of how the computer might aid them. Quite often the result of this effort is a kaleidoscopic communication situation. The computer user is baffled by the bewildering array of information from computer services.To help solve some of the documentation problems, the Kansas State University (KSU) Computing Center implemented a three-level documentation system. Under this arrangement, a confusing array of material was organized into a manageable set of documents. First, let's take a look at some of the documentation problems; then we'll discuss the three-level approach.
An approach towards detailed documentation
Authors: Farber Andrew R.
Published: February 2006

In a previous article, I described how one starts documenting a large computer system for maintenance programmers. We were left at the end of the January issue with a set of index cards and structure charts. Each card represented a separate program or subroutine (called a module), color coded by source language. The structure charts showed the different subroutines a main program called, and the I/O activity of the individual modules. Now we must tackle the problem of converting the cards and rough draft structure charts to documentation that can be understood by others.
A FAMULUS post-processor
Authors: Conrow Kenneth
Published: February 2006

The FAMULUS documentation system is a very capable system for preparing and manipulating a set of records which constitutes a bibliography, a teaching aids list, or any other list of items with relatively static descriptors. The system was developed in 1969 by the Pacific Southwest Forest and Range Experiment Station, Berkeley, California and refined in 1972 at University College London. FAMULUS consists of a number of separate programs which can be used to create, edit, sort, index, and search a file of records. Each record can have up to ten fields and a total length of up to 4000 characters.
Working as an "only writer" (3)
Authors: Leder Ellen
Published: February 2006

I was hired as the documentation writer for a computer-based market research company of 30 employees, and I would like to share some of my thoughts, now that I have another job.
Automated documentation in systems analysis and design
Authors: Rose Lois A.
Published: February 2006

It seems that proper documentation of systems analysis and systems design is the most tedious, time-consuming portion of systems development. Yet few people would challenge its importance.
The ¶ key
Authors: Sachs Jonathan
Published: February 2006

I am a freelance technical writer and programmer with a long-standing interest in text processing systems. Right now I'm helping to write a phototypesetting system that will run on a large, time-shared computer. It will be used by many different kinds of people in many (its seller hopes) installations.
Project initiation and control
Authors: Watkins Otis T.
Published: February 2006

This article describes some of the forms and standards used to initiate and keep track of development projects at the Citizens Fidelity Bank & Trust Company in Louisville. These procedures provide the measure of control that we find necessary to form a more responsible user and ensure domestic tranquility.
Using a theory of human behavior to analyze the effects of documentation
Authors: Brooks Ruven
Published: February 2006

While this example has mentioned five modeling domains, these same five would not necessarily be present in every task or for all parts of a task. If the task is to implement a particular algorithm for a general purpose algorithm, say, a matrix inversion routine, there will be no domain corresponding to the original domain of cargoes and routes in the example. On the other hand, use of a primitive operation of searching a tree at one level might require use of an intermediate domain, containing methods of tree traversal, before the knowledge could be represented at the programming language level.
Standards rehashed
Authors: Patterson Dianna
Published: February 2006

To readers who do not live in the English speaking part of North America, I should explain that the title of this essay is meant to have a certain gastronomique relevance. This is because my intention is to eat some words that I wrote a while ago.
BIG D attracts record breaking crowd of technical writers & illustrators
Authors: Patterson Diana
Published: February 2006

This was the Silver Jubilee of the International Technical Communication Conference (ITTC 25), and the largest crowd ever gathered in Dallas, Texas in May for the occasion. Since most registrants only signed up at the last minute, the conference overflowed into not one, but two hotels, with the odd person at still others.
Whatever happened to adverbs?
Authors: Bergeron Tom
Published: February 2006

Are you treating your readers badly? Do you deliberately annoy them with a simpler than thou approach to documentation? Are you treating every level of expertise with a patronizing style as if levels didn't exist? If so, don't bother to read this; it will confuse you too much.
A neophyte's guide to reentrant usability with enchiridion
Authors: Phule A. P. ril
Published: February 2006

Reusable systems will require reusable documents to ensure the best possible efficiency. Improved efficiency means improved productivity per unit; although it cannot be considered a parallel indicator.
Literature from the software tarpit or the how, where and why of software documentation
Authors: Warman Alex
Published: February 2006

John Lees' "Reaction from the Trenches" (SIGDOC Vol. 7, No. 2) has raised some interesting points on the relationship between documentation and a concept of "good" programs. I have worked on some large projects for both systems programming and applications programming jobs over the years. In recent years I have taught a few programming courses for beginners and more advanced programmers. This led me to explore firstly, the way that programs are developed - both good and bad, and then to try to discover how good people should be introduced and guided toward a notion of "good" programming practice. I shall describe how these concepts evolved and led to a view which requires most documentation to be produced before any code is written. Indeed, it becomes part of the preparation and planning for coding and then testing. Thus, documentation is no longer seen as something separate from the software and as an evil extra that prevents programmers from getting on with the next interesting and important program. Rather it is seen as an essential and integral part of a well organized approach to producing software products. Finally, I believe that it is a moot point as to whether it is worse to have software which is poorly documented or software that does not work.
Technical writing
Authors: Rigo Joe
Published: February 2006

This article does nothing to advance the leading edge of system documentation. With luck, however, it may be useful to a few people.
Doing it Manually
Authors: Rigo Joe
Published: February 2006

I have been making a good living from computers for 15 years now. I think they are great -- for other people. I don't want anything to do with them in my own work.
Documenting for software maintenance
Authors: Glass Robert L.
Published: February 2006

A curious phenomenon has occurred over the last several years in the field of software system documentation.
Cunning, plausible lies
Authors: Lillington R. C.
Published: February 2006

When asked to write this article (or perhaps I volunteered--the distinction was not very clear at the time) I was unable to obtain any clear instruc instructions as to what the subject matter should be. The thought struck me that this must be a familiar enough situation to most technical writers, and this, in turn, triggered a temporary feeling of forgiveness for those faceless people who have managed to create for me my most memorable periods of chaos.
A methodology for implementing structured flowcharting
Authors: Dewhurst Stephen C.
Published: February 2006

The need for a structured approach to flowcharting is well-established. As a design aid structured flowcharting helps to produce a structured product, and as a documentation tool structured flowcharts are invariably more readable (and hence, move useful) than unstructured ones.
The need for effective documentation
Authors: Jacquart J. F.
Published: February 2006

The main concept that I propose is based upon an ACCESSABLE ON-LINE DOCUMENTATION ELEMENT DICTIONARY consisting of document elements with its content items. This on line dictionary will be the paradigm for the development of effective documentation.
Teaching technical writing
Authors: Pelt D. Van
Published: February 2006

The rapid growth of the computer industry has created an increasing demand for technical writers who can address the specialized problems of computer documentation. Since information science is still a very young discipline, university and college writing programs have only begun to identify the needs of this new industry and develop courses that satisfy those needs. Two interrelated factors have severely aggravated the problem. First, writing for computer systems places the writer in a rigorously specialized context as different from writing for business, law, or medicine as those disciplines are from each other. Since most computer documentation instructs readers on how to use a specific system or set of procedures to perform a specialized task, writing instruction manuals and other supporting documentation for computers must be sharply distinguished from the more traditional forms of business writing, technical report writing, and scholarly journal articles written for publication. The second factor hindering the development of new courses in this area involves the rapid advance of computer technology itself: a bewildering array of new devices and systems appear every week, training documents and reference manuals are often outdated before they are even completed, and the increased complexity of the new technology frequently requires addressing several different audiences, each possessing a widely varying level of technical knowledge. These problems require specialized teaching approaches to create a situational context resembling that of the working world. Students need large conceptual guidelines for addressing different groups of readers, yet the learning environment must remain flexible enought to adapt to rapid technological change and multiple levels of specific information needs. This article describes a course developed at the University of California, Santa Cruz which addresses these problems.
MiniDoc
Authors: Schneider Gene
Published: February 2006

The Software Abstract is intended to tell its reader enough about the software to know where to find all the other information that exists about it, anywhere. A copy of the Abstract opens every document about the software. It has a fairly rigid format, so a sequence of Abstracts can be scanned swiftly, the same information always being found at the same place. The format of the Software Abstract is defined in Figure 1. Although most Software Abstracts are written to define individual programs, the format is also an effective tool for describing any software entity: subroutine, program, software system or subsystem, data file, or library. It has even been used successfully to document books and articles about documenting (Schneider, French, Lucas 77). The Abstract is constrained to fit on one side of one sheet of paper. This is the reason that certain sections of the Abstract are considered optional.An Example of Software Abstract is shown in Figure 2. The example demonstrates the considerable informational latitude that can be incorporated into a Software Abstract without violating the strict format guidelines.
Peer reviews improve your writing
Authors: Abshire Gary M.
Published: February 2006

So, you labored to meet all those unrealistic dates caused by an accelerated schedule. You sweated over that tough writing assignment. You may feel that your document is well written, but is it? Will a reader spot flaws that somehow you overlooked?
Why an algorithmic documentation language
Authors: Faulkner Robert
Published: February 2006

System designers have tried multiple techniques for documenting what a program does, from "Self Documenting" languages to Flow Charts. The difficulty is that "Self Documenting" languages aren't and flow charts are difficult to maintain, plus neither generally follows the way in which programs are really designed. An Algorithmic Documentation Language is a design tool which becomes part of the system documentation. It combines defined control structures with English language statements.This paper describes the development of the Algorithmic Documentation Language, ALDOC. It also gives a short definition of the language statements and control structures.
Manuals maintenance controls
Authors: Campbell Bob
Published: February 2006

Many companies are developing manuals documenting their various systems, but few have taken that next important step, the development of a Manuals Maintenance Control System.
Abstraction program aids to documentation
Authors: Perlman Gary , Erickson Thomas D.
Published: February 2006

We describe two programs to help writers get an overview of a document so they may judge how well it is organized and how sentences are structured. The HEADINGS program prints section headings in a variety of formats such that indentation shows nestedness. The PUNC program prints punctuation graphs of sentences that show sentence length and complexity. The two programs can be combined so that writers can make estimates of section lengths. Though simple, the programs provide a useful source of feedback telling writers some abstract summaries of their documents. The programs do not make judgements about how the outputs
should
look because they depend on the type of document, however we discuss some of the common trends to look for.
Improving the usability of programming publications
Authors: Bethke F. J. , Dean W. M. , Kaiser P. H. , Ort E. , Pessin F. H.
Published: February 2006

In mid-1979, a study group was convened at the IBM Santa Teresa Laboratory to find ways to improve the usability of publications supporting the Laboratory's programming products.
1
The group, called the System Information Ease-of-Use Study Group, consisted of technical writers, editors, and information planners---all members of the System Information (i.e., programming publications) Department at the Laboratory. The study group was asked to answer the question: "What can the planners, writers, and editors of programming publications do to make the books they work on more usable?"
Toward a more precise definition of task-sufficient information
Authors: Mirel Barbara
Published: February 2006

"Improving the usability of programming publications," by Bethke et al. was a pioneering effort to transform computer documentation from a system-oriented to task-oriented design. To increase users' satisfaction with their manuals and ensure consistency in libraries, the authors realized that instructional information could not merely explain the inner workings and principles of a system for their own sake but that writers needed to shape information around users' taskrelated purposes, goals, and operational needs. Today, Bethke et al.'s views on taskorientation and usability stand as well-established principles in the field of documentation.
A response to Bethke et al.
Authors: Prigge David
Published: February 2006

The ideas in the paper by Bethke, Dean, Kaiser, Ort, and Pessin parallel so closely what people in my documentation group have been learning lately, that I was first tempted to respond with something like, "There's nothing new here. Sure, it's accurate and perceptive, but we know just as much." Then I realized that the paper had been written 10 years ago, reflecting study that is now 12 years old, any my respect grew. While we have been thinking about these things, they have long since tied it all together and implemented it.
Studying document usability
Authors: Ramey Judith
Published: February 2006

I first read "Improving the usability of programming publications" by Bethke et al. ten years ago when I was writing hardware manuals for a computer company.
Comments on envisioning information and the visual display of quantitative information
Authors: White Jan V.
Published: February 2006

There was no way to measure earthquakes until 1935, when Charles F. Richter published his scale. Watt, Ohm, Ampère, Joule, Hertz, Volta, Gauss are names of the scientists as well as the electrical concepts they articulated. Another example: what are forsythias or fuchsias? You've got it: I'm not sure exactly what Messrs. Forsyth and Fuchs did with or to the original flowers (maybe they discovered them?), but it must have been unique. One more to drive in the point: good old Amerigo Vespucci.
"Governed by good ideas and executed with superb craft"
Authors: Boyarski Daniel
Published: February 2006

As a graphic designer and as an educator of graphic designers, I am often asked to recommend texts that shed light on what I do and teach. (By the way,
information design
suggests what I do better than
graphic design.
) Because so very few books stress the problem-solving aspect of information design and the appropriateness of given form, be it word or picture, there are only a handful of titles I ever mention. Happily, I can now add one more book to that short list.
Informing "envisioning" with data
Authors: Schriver Karen A.
Published: February 2006

Envisioning Information
, Tufte's most recent book, is dedicated to presenting strategies for enhancing the design of information. By drawing on a series of examples ranging from topological maps to train schedules, Tufte discusses five principles of information design: macro/micro readings; layering and separation; small multiples; color and information; and space and time. He devotes a chapter to each principle, using examples mainly designed to convey numerical, referential, or tabular data (e.g., a graph, a directory, or a chart).
"Colors are the deeds and sufferings of light"
Authors: Evenson S. , Wilkin L. , Wulff W.
Published: February 2006

There was a time when writers wrote texts, designers designed them, and printers printed them. Computers, of course, changed this scenario. Now, an individual can write, design, and publish documents (both paper and electronic documents) in vast quantities. On a small scale, this is called desktop publishing. On a large scale, this is called electronic publishing. The trouble is that very few individuals have the training and the experience to write, design, and print effective and attractive documents all by themselves. Just as there is more to writing than looking for words in a dictionary or the-saurus, so there is more to design than choosing a font from a menu or a color from a palette.
Color and communication
Authors: Marcus Aaron
Published: February 2006

A new decade in the history of computer graphics has brought lowered cost, higher technical quality, and faster color display equipment to screen images, slides, overheads, video, and paper. Alas, many users and an occasional vendor have acknowledged that very few people understand how to use color well for communicating information, for convincing persuasion, and for increasing aesthetic appeal. Several recent authors have attempted to fill in the lacunae of practical experience and theoretical knowledge that trouble many users of computer graphics equipment of designing user interfaces, electronic documents, and knowledge visualizations. The bibliography of this review lists several recent sources other than the book commented in this article, Jan V. White's
Color for the Electronic Age.
Technical communication and system analysis
Authors: Weiland Richard J.
Published: February 2006

Technical communicators tend to do most of their communicating about computer systems after the fact. That is, to a very large extent, we spend our time describing systems that have already been designed, often ones that are already in operation. The documentation we produce, if properly done, is clearly a useful part of the system environment. However, we generally do our work within a very narrow portion of the system life cycle.
A writer's reflections on product design
Authors: Talbott Stephen L.
Published: February 2006

The user of a computer-based product typically sits in front of his terminal with a job to perform. The simpler and more unified the world of capabilities he encounters through that terminal, the easier his life will be. The screen of his terminal should be a window upon his world of problems and tasks, not the world of the engineers who built the system.It is important to specify early in the product development what the user will see. This is where the user's manual enters the picture. For a user's manual is in fact a specification of the user's product---the product he will actually come to know and experience.The conventional view of a computer-based product and its manual is straightforward, and few would think to question it.• The product is designed by Engineering and built by Manufacturing. It typically includes a box and software.• The user's manual, prepared by writers, describes this product.• The product exist independently of the manual. The engineering and writing functions are related only as an object is related to its description.
Data processing documentation instruction books what's new and what's best
Authors: Brockmann R. John
Published: February 2006

These four new books can be divided into basically two groups; the Skees and Van Duyn books are reference handbooks that give the reader a generalized view of good documentation. These books claim to enable the data processing documentation writer to handle any and all problems that can arise in the area of writing. Such books usually begin with a section on the mechanics of writing and some considerations of general document development. They conclude with a quick overview of how to apply these general considerations in some specific documentation situations such as reports, procedures, manuals, proposals, or technical articles for publication.
Improving your effectiveness between covers
Authors: Gain Therese
Published: February 2006

Phew! We've just finished another manual. This one was a lot of fun. I wonder if the users will find it as enjoyable to read as it was to write.
Packaging
Authors: Won Pearl
Published: February 2006

In a room full of writers, you can usually distinguish the different types of writers by surveying their style of dress.
Rockcopy and squishycopy
Authors: Willoughby D. M.
Published: February 2006

As purveyors of the language, claiming to be communication experts, we need to heal ourselves of a growing disease. This disease, becoming prevalent with the spread of computer technology, is the dreaded "use of jargon." Fellow communicators, many of us are using the terms "hardcopy" and "softcopy" when we speak of computer documentation.
Breaking through writer's block
Authors: Lopeke Linda
Published: February 2006

I used to think writer's block affected only the very great or very near great writers of ages past. Then I extended my view to include the professional slacker; an individual bold enough to plead "writer's block" when confronted with yet another deadline missed.
Line editor to text editor conversion
Authors: Talburt John R.
Published: February 2006

I attended the Third International Conference on Systems Documentation held this past May in Mexico City. This conference was not only enjoyable and informative, but also inspirational. The following article describes an application that is an outgrowth of several ideas presented at the conference and tutorial session. I would like to thank all of the organizers of this meeting, especially Ms. Patterson and Senor Figueroa, for a job well done.
Interview with Nicholas Negroponte
Authors: Lee Newton , Negroponte Nicholas
Published: February 2006

Dr. Nicholas Negroponte, is the Wiesner Professor of Media
Technology at MIT and founding chairman of the MIT Media Lab. He is
also the chairman of the 2B1 Foundation and One Laptop per Child
(OLPC). My sister and colleague Ms. Gina Lee conducted a video
interview with Nicholas on December 19, 2005 at the Multimedia
Entertainment China conference in Beijing, China. In the video
interview, you will hear Nicholas' answers to the following
questions:1. How did you come up with the $100 laptop idea? 2. What
was the most challenging problem for the $100 laptop? 3. 20 years
ago in 1985, you created the MIT Media Lab. How do you see the MIT
Media Lab today and in the next 20 years? 4. 10 years ago in 1995,
you published The New York Times bestseller "Being Digital." Your
book offers insight on what "being digital" means for our future.
If you were to write a 2nd edition of your book today, what would
your new predictions be for our future? 5. You are the chairman of
the 2B1 Foundation and the One Laptop per Child nonprofit
organization. How do 2B1 and One Laptop per Child work hand in hand
to help the poor children?
Learning through game
modding
Authors: El-Nasr Magy Seif , Smith Brian K.
Published: February 2006

There has been a recent increase in the number of game environments or engines that allow users to customize their gaming experiences by building and expanding game behavior. This article describes the use of modifying, or
modding
, existing games as a means to learn computer science, mathematics, physics, and aesthetic principles. We describe two exploratory case studies of game modding in classroom settings to illustrate skills learned by students as a result of modding existing games. We also discuss the benefits of learning computer sciences skills (e.g., 3D graphics/mathematics, event-based programming, software engineering, etc.) through large design projects and how game design motivates students to acquire and apply these skills. We describe our use of multiple game modding environments in our classes. In addition, we describe how different engines can be used to focus students on the acquisition of particular skills and concepts.
Turing's test and believable AI in games
Authors: Livingstone Daniel
Published: February 2006

The Turing test is perhaps the most famous, most quoted, and probably most often misrepresented and misunderstood measure of machine intelligence. In this article we'll briefly review the Turing test and some of its key criticisms. In particular, we will try to answer whether the Turing test -- or something derived from it -- can be of use in developing and assessing game AI. We will also present a brief overview of a methodology for conducting believability testing for games and highlight some of the problems inherent in any attempt to categorically determine whether or not some AI behavior is capable of convincing, life-like behavior.
Dust to glory
Authors: Koppelman Charles
Published: February 2006

Dust to Glory, a Dana Brown film (IFC Films 2005) is an extraordinary work about one of the most acclaimed and dangerous races in the world, the 36th Annual Tecate SCORE Baja 1000.
4th European Interactive TV Conference: EuroITV 2006
Authors: Lee Newton
Published: February 2006

Following on from three previous EuroITV conferences, the steering committee of the EuroITV has decided to hold the 4th European Interactive TV Conference in Athens, Greece. After the successful organization of the Summer Olympics 2004, Athens enjoys a modern infrastructure that facilitates business and leisure activities. EuroITV brings together researchers and practitioners from diverse disciplines that include human-computer interaction, media studies, computer science, telecommunications, audiovisual design and management. The organizing committee invites you to submit original high quality papers addressing the special theme and the topics, for presentation at the conference and inclusion in the proceedings.
3rd International Workshop on Pervasive Gaming Applications
Authors: Lee Newton
Published: February 2006

The PerGames series of international workshops addresses the design and technical issues of bringing computer entertainment back to the real world with pervasive games. Previous PerGames events were held in Vienna (2004) and Munich (2005) and attracted researchers and practitioners from all over the world.With the PerGames 2006 workshop we bring together researchers who are interested in interactive entertainment and the chances and risks that pervasive computing might add to it. We will discuss results from this emerging field and share our experiences and visions to identify relevant research questions and future research directions.
Why dependent types matter
Authors: McKinna James
Published: February 2006

Language designers have in recent years proposed a wealth of richer type systems for programming which seek to extend the range of statically enforced guarantees on data and code. Most such proposals have been evolutionary extensions of ML or Haskell, offering programmers a balanced compromise between expressive strength and existing well-understood technology. Typically they revolve around type- or kind-indexed types such as GADTs, supported by limited equality reasoning at the type-checking level, thus separating the dynamic behaviour of programs from the (simpler) static behaviour of indexing information occurring in their types.I want to argue in this talk for a more radical departure from such practice by examining full spectrum type dependency, lifting such restrictions on the data upon which types may depend. Conor McBride and I designed the language EPIGRAM for experiments in programming with inductive families of data (of which GADTs are a special case). Using it for illustration, I will explore some of the possibilities and challenges afforded by full spectrum type dependency at the static and dynamic level:

types directly support modelling complex invariants in terms of other data (rather than their types), with a Curry-Howard flavour of data-as-evidence; such complexity is on a 'pay-as-you-go' basis, while keeping type annotations and other syntactic overheads to a minimum;

data decomposition steps, e.g. case analysis, furnish more informative interactions between types and values during typechecking; such steps may moreover be abstractly specified by their types, and thus user definable; this supports a style of programming embracing 'learning by testing', views, and Burstall's 'hand simulation plus a little induction';

the absence of a rigid phase distinction need not lead to type-passing or excessive run-time overhead; effectful computation, in particular partiality, can be incorporated via variations on existing ideas such as monads.

This talk is based on joint work with Conor McBride, Edwin Brady and Thorsten Altenkirch.
The next 700 data description languages
Authors: Fisher Kathleen , Mandelbaum Yitzhak , Walker David
Published: February 2006

In the spirit of Landin, we present a calculus of dependent types to serve as the semantic foundation for a family of languages called
data description languages
. Such languages, which include
pads
,
datascript
, and
packettypes
, are designed to facilitate programming with
ad hoc data, ie
, data not in well-behaved relational or
xml
formats. In the calculus, each type describes the physical layout and semantic properties of a data source. In the semantics, we interpret types simultaneously as the in-memory representation of the data described and as parsers for the data source. The parsing functions are robust, automatically detecting and recording errors in the data stream without halting parsing. We show the parsers are type-correct, returning data whose type matches the simple-type interpretation of the specification. We also prove the parsers are "error-correct," accurately reporting the number of physical and semantic errors that occur in the returned data. We use the calculus to describe the features of various data description languages, and we discuss how we have used the calculus to improve
PADS
.
A hierarchical model of data locality
Authors: Zhang Chengliang , Ding Chen , Ogihara Mitsunori , Zhong Yutao , Wu Youfeng
Published: February 2006

In POPL 2002, Petrank and Rawitz showed a universal result---finding optimal data placement is not only NP-hard but also impossible to approximate within a constant factor if
P
≠
NP
. Here we study a recently published concept called
reference affinity
, which characterizes a group of data that are always accessed together in computation. On the theoretical side, we give the complexity for finding reference affinity in program traces, using a novel reduction that converts the notion of distance into satisfiability. We also prove that reference affinity automatically captures the hierarchical locality in divide-and-conquer computations including matrix solvers and N-body simulation. The proof establishes formal links between computation patterns in time and locality relations in space.On the practical side, we show that efficient heuristics exist. In particular, we present a sampling method and show that it is more effective than the previously published technique, especially for data that are often but not always accessed together. We show the effect on generated and real traces. These theoretical and empirical results demonstrate that effective data placement is still attainable in general-purpose programs because common (albeit not all) locality patterns can be precisely modeled and efficiently analyzed.
Simplifying reductions
Authors: Gautam  , Rajopadhye S.
Published: February 2006

We present optimization techniques for high level equational programs that are generalizations of affine control loops (ACLs). Significant parts of the SpecFP and PerfectClub benchmarks are ACLs. They often contain reductions: associative and commutative operators applied to a collection of values. They also often exhibit reuse: intermediate values computed or used at different index points being identical. We develop various techniques to automatically exploit reuse to simplify the computational complexity of evaluating reductions. Finally, we present an algorithm for the optimal application of such simplifications resulting in an equivalent specification with minimum complexity.
Formal certification of a compiler back-end or
Authors: Leroy Xavier
Published: February 2006

This paper reports on the development and formal certification (proof of semantic preservation) of a compiler from Cminor (a C-like imperative language) to PowerPC assembly code, using the Coq proof assistant both for programming the compiler and for proving its correctness. Such a certified compiler is useful in the context of formal methods applied to the certification of critical software: the certification of the compiler guarantees that the safety properties proved on the source code hold for the executable compiled code as well.