LETTERS

Stereo Glasses

Dear DDJ,

My vote for best article of March 1993 goes to "Algorithms for Stereoscopic Imaging" by Duvanenko and Robbins. After seeing a stereo demonstration of a Tektronics display using a full-screen polarizer and passive-polarizing glasses a few years ago, I searched for a cheap alternative using glasses with liquid crystal shutters that could be used with a PC VGA display. I shortly discovered that Sega of America Inc. made such glasses for their Genesis video-game product, so I obtained a pair for about $45.00 at a local toy store.

After determining that 12 volts DC was sufficient to make a lens opaque, I built a converter to accept vertical sync or field signals sent to the display monitor and alternate the blanking voltage sent to the glasses lenses. An adapter cable tapped the VGA monitor sync signal. I used techniques similar to those described in the article to load two display pages and switch them in response to vertical interrupts. The method worked fine in noninterlaced modes using a Video 7 1012i adapter card with a Seiko CM-1440 monitor, and with a few interrupt-handler modifications, a Diamond Speedstar VGA adapter, and NEC Multisync 4-D monitor. I used the same converter to drive the glasses from a Silicon Graphics 4D80GT workstation equipped with a Genlock card, the card providing a vertical sync output.

Eventually I realized the converter box and monitor cable tap could be eliminated in the case of the PC, by utilizing a serial port RS-232 control-signal output. On my PC, the DTR signal level switches between about +-12 volts. This signal can be controlled by writing directly to the serial port. A simple circuit (Figure 1) consisting of two diodes and two resistors routes the +-12 volt level to one lens and about 0 volts to the other, unblanked lens. I built the circuit into the shell of a 25-pin connector along with a mini stereo jack into which the glasses plug. The result is a simple, easily removable interface which ensures that a given output signal polarity always blanks the same lens.

James R. Jones

Colorado Springs, Colorado

Another Curmudgeon Heard From

Dear DDJ,

After reading, "A Curmudgery on Programming Language Trends" by Scott Guthery (DDJ, December 1992), I feel I can add a few comments. I agree with Guthery that OOP brings nothing fundamentally new. I also agree that C++ is not a very good language. It's a large language with many semantic pitfalls. But I feel Guthery has not pointed out the weak points of OOP in general:

1. OOP languages often generate slower code. A common misconception is that with today's fast microcomputers and optimizing compilers, there is no need for low-level languages. Al Stevens remarked in a consecutive text box that throughout computer history there has been a trend to move further from machines; from plugging cables towards using high-level languages. Still, I use a lot of assembly language. Not because I like it, but because I need the speed. Buying a faster machine is not a solution because the software requirements grow too. I used to need assembler to speed up graphics programs for the CGA on a PC/XT. Now I use assembler for Super-VGA on a 486/33 MHz. Regrettably, I can't get below the assembler level (and change the microprocessors' microcode). If I could, I would probably reprogram it. But Abrash's book The Zen of Assembly Language (ISBN 0-673-38602-3) taught me that even if you cannot access the processor's internals, knowledge about it can make an enormous difference.
2. Systems do not always fit into hierarchies, so in OOP you often have to make them fit by changing the functional specifications or by adding extra support routines. I am referring to an example of OOP from Borland's Turbo Pascal 5.5 manual. In this example you create a location class with (x,y) coordinates, a point class derived from location and adding a color field, and a circle class derived from point and adding a radius field. As an exercise I tried to add a line class, and I asked a few of my colleagues to do the same. From what class do we derive it? A circle has a midpoint and a radius, but a line has two endpoints. How would you solve this problem? My solution was to take a "vector" approach. We derive line from point and add two fields, x_disp and y_disp, that give the relative position of the second endpoint. (The first endpoint is inherent from point.) But note that I have conveniently changed the functional specification of a line (two endpoints) to a vector (one point and a displacement). In this example, there is not really a problem because it is trivial to convert from line to vector, but this is not always the case.
3. OOP software is said to be reusable. OOP does have its merits here, but there are other methods for reusing software components without using OOP. Modularity is the key word. Creating abstract data types is a modular technique that can be used with most non-OOP languages.
4. When you derive one class from another, you can add new methods to the inherited ones, and you can modify (redefine) inherited methods. But you cannot delete inherited methods or data from the class. Normally, there should be no need to delete elements from a class. You just ignore them, and optimizing linkers should strip off any unused code or data. Still, I'd like some manual control.
5. Code and data are not the same in most compiled languages, so putting them into one data structure gives some difficulties when writing them to file. This is in essence the problem of persistent objects in C++. The OOP concept is much stronger in languages where code and data are exactly the same, such as LISP.
6. A few years back everybody told you that OOP was a new way of thinking. You were supposed to forget everything you knew about programming and restart from the ground up thinking objects. Wrong! We forget and restart too often. That's why history repeats itself.

Fuzzy Redux

Dear DDJ,

In the February 1993 article "Fuzzy Logic in C," Greg Viot attributes the invention of many-valued logic to Lotfi Zadeh in 1965. However, this kind of logical calculus was introduces in the '20s in the works of Emil L. Post, Jan Lukasiewicz, and Alfred Tarki. This by no means does not depreciate Lotfi Zadeh's merits. (Lukasiewicz is also a creator of the well-known Reverse Polish Notation.)

In the same issue, Stephen Wolfram said that: "The way you make progress in mathematics is that you think of a theorem and generate a proof for it. In every other field of science, experiment is the thing that originally drives what goes on. People don't make models and theories and work out their consequences."

I think he is wrong. I agree with Fred Hoyle's science fiction novel, The Black Cloud: "Bloody bad science...Correlations obtained after experiments done is bloody bad.... Only predictions really count in science.... It's no good doing a lot of experiments first and then discovering a lot of correlations afterwards, not unless the correlations can be used for making new predictions. Otherwise it's like betting on a race after it's been run."

Janusz Rudnicki

Ste.-Madeleine, Quebec

DCW Update

Dear DDJ,

A brief comment on John Russel's letter about the DCW (Digital Chart of the World): A 1:1,000,000 digitized map of the world is available on four CD-ROMs for $200.00.

The four governments that contribute to this effort are indeed to be congratulated and thanked for making this database available for geographic application developers at a very reasonable price. As Russel states, the VPF-VIEW software included with the DCW leaves a lot of room for improvement; I hope some DDJ reader puts a much more robust packaging of this spatial dataset on the market soon.

As a footnote, not all the participating governments are unanimous in their support of the DCW project. Specifically, the Director of Great Britain's Ordnance Survey apparently feels that selling this dataset for "only" $200.00 constitutes "dumping" and violates the GATT (General Agreement of Trade and Tariffs). I for one take notice that $11,000,000 of "my" (U.S. taxpayer) money was used to produce the DCW; I feel I am entitled to a copy for as little as $200.00--or less.

Developers of geographic applications should also note that a remarkable spatial dataset--TIGER--is available on CD for $250.00 per disk (42 disks for the entire country). TIGER is essentially a digital street map of the entire USA, including street names and house numbers required to link to and map any data file that contains street addresses. For more information contact the Data User Services Division of the Census Bureau: 301-763-4100.

Donald F. Cooke

Lyme, New Hampshire

Ada and Modula-3

Dear DDJ,

In regard to Spencer Roberts's reaction to Sam Harbison's October 1992 article "Safe Programming with Modula-3" (DDJ, March 1993), Spencer asks for "just the facts" but he himself has a few facts about Ada wrong. I have programmed in Ada, mostly on Ada compilers, for six years now, and I can testify that Ada is not as safe as Modula-3.

Ada's initialization of all pointers to null helps only with uninitialized pointers, not dangling pointers. Uninitialized pointers can cause as much havoc as dangling pointers but are much easier to find by reading code. Dangling pointers are pointers to objects which were once allocated but have since been deallocated.

Spencer states that Ada automatically sets pointers to null when the user exits the block they are declared in. This accomplishes nothing, since the pointers disappear altogether at this time and can never be used anyway.

If you read the Ada Language Reference Manual (LRM) carefully, it sort of implicitly invites implementors to write a garbage collector (LRM 4.8-7..11). I know of no implementation which has done this. If there is no garbage collector, then Ada requires that all dynamically allocated objects of a particular access type (i.e., pointer type) implicitly be kept around until the user exits the block which declares the access type. This is absolutely safe but is so extremely conservative that it precludes real dynamic deallocation.

Instead, in Ada, one must use the predefined generic procedure aptly named UncheckedDeallocation. This is an explicitly programmed deallocate, and can create dangling pointers. UncheckedDeallocation does set the pointer passed to it to null, but that is trivial. The real programmer's problem is all the now-dangling copies of the pointer which might be stored, who knows where, in a multilink data structure.

In my experience, eliminating dangling pointers in a complex data structure when using explicit programmed deallocation is more difficult than writing an Ada front end, minus the deallocation. I have worked on two Ada compilers that don't even try. They just abandon the garbage nodes and hope the storage loss will be tolerable until everything can be deallocated.

They even do this for a data structure which is stored long-term in files! When you need such a dynamic data structure, garbage collection is the only way to go.

I don't understand what Spencer means by "garbage collection is always machine dependent." It is no more, or less, machine dependent than any high-level language construct. In particular, it introduces no machine dependencies to the source code in Modula-3. The implementation of garbage collection is machine dependent, but so is the implementation of the whole runtime system and the code generator. All have to be different for different machines, regardless of the language.

Spencer contends that any runtime checking is less safe than static checking. I agree, but this doesn't compare Ada and Modula-3. Both have a lot of static checking as well as some things that are checked at run time. I don't know of any instance in which Ada is more aggressive than Modula-3 in enforcing static safety. On the other hand, garbage collection is a big example where Ada is less aggressive in enforcing dynamic safety.

Rodney M. Bates

Wichita, Kansas

Copyright © 1993, Dr. Dobb's Journal