Dear DDJ,
I'm not a regular of DDJ reader, and I may have missed the obvious answer. When trying to compile Al Stevens' PTL v2 source code from April 1998 installment of his "C Programming" column, I get lots of errors that appear to come from differences between Al's declarations in PTL.H and the Rogue Wave implementation of the STL included with the Borland compiler. I'm sure I can go through and weed these out one by one, but are there general or specific suggestions that might cut down on trial and error?
Wes Plouff
nwp@chrysler.com
Al responds: Wes, PTL is based on Standard C++ STL. I expect Borland will have a compliant STL in a future release. PTL does not compile with the original HP STL, either. So far, Microsoft's compiler is the only PC compiler I've found that is close enough (although not fully compliant). See my March 1998 column for details.
Dear DDJ,
Thanks for publishing the article "Algorithms for High-Precision Finite Differences," by Michael Herstine (DDJ, May 1998) on computation of finite differences. It is comforting to know that DDJ remains close the roots of computing and the reason for which digital computers were invented in the first place -- numerical computations. In some applications where derivatives are required, such as optimization over hundreds or thousands of variables, finite difference approximations are both too costly of computing time and too inaccurate for numerical stability. Alternative methods are based on the notion of automatic differentiation of algorithms (see Automatic Differentiation of Algorithms: Theory, Practice, and Application, by Griewank and Corliss. SIAM, 1991). These methods allow computation of derivatives of arbitrarily complex functions that are analytically correct and have the same precision as the function itself. Also, the computational cost is only about five times that of the function in comparison to some multiple of the number of variables times the computational cost of the function. A particularly elegant C++ implementation of automatic differentiation is available as the Autodif Library and as a high-level programming language for nonlinear optimization, AD Model Builder. Further information can be found at http://otter-rsch.com/.
John Sibert
jsibert@soest.hawaii.edu
Dear DDJ,
The article "Date Compression and Year 2000 Challenges," by Robert Moore and Gregory Foley (DDJ, May 1998) was interesting, but left out one possibility -- Julian day numbers. I recently reviewed some PL/1 code I wrote in 1975 that would still be fully Y2K compliant, yet stored its dates in only four bytes (as a 32-bit integer) when others were wasting space by using the MMDDYY format. I had a couple of standard PL/1 functions to convert to and from "conventional" dates. (C functions to do the same are simple.) Astronomers and chronologists use the Julian day number method and have done so for many years so that it is already a standard representation. (See the discussion by Peter Meyer at http://www.magnet.ch/serendipity/hermetic/cal_stud/jdn.htm.)
This technique was developed by Joseph Justus Scaliger (1540-1609) in the course of his work on ancient chronologies published in 1583, and probably named for its fit to the Julian year. January 1, 4713 b.c. is the date determined by Scaliger to have three different yearly counting schemes simultaneously at the start of their sequences and the Julian date of a day is the number of days since that date. This makes it easy to determine the number of days between two days (just subtract one Julian day number from the other). The system of Julian days should not be confused with the simpler system of the same name which associates a date with the number of days elapsed since January 1 of the same year.
A scheme based on Julian day numbers would fit well with systems that store data in six bytes as YYMMDD. For transition purposes, a simple flag value in the YY field would indicate that the MMDD bytes should be interpreted as a 32-bit integer Julian.
Ed Guy
Ed_Guy@compuserve.com
Dear DDJ
The article "Date Compression and Year 2000 Challenges," by Robert L. Moore and D. Gregory Foley (DDJ, May 1998), discusses several methods to allow additional dates to be stored in a date field without requiring additional space. However, none of the "compression" methods given have the advantage of being backward compatible (that is, allowing pre-2000 dates to be understood by legacy programs).
With some additional effort, it is possible to use date compression while still being backward compatible. For example, with the "MMDD 16-bit Year Format" date storage method, the YY field for a legacy date (assuming the ASCII character set is used) will always convert to an integer of 12336 (3030h) or greater. If dates beyond the year 12335 are not allowed, then code can be written that will detect whether the date is of the old or new format, and respond accordingly.
Some example code in C could look like Example 1.
Using a backward compatible compression scheme preserves a major advantage of Windowing, the ability to continue to use information stored in a legacy format (such as databases). Also, if each updated application is modified so it continues to use the legacy dating format for any dates before the year 2000, the ability to independently update multiple applications that act on the same data is also preserved.
Brant Thomsen
bthomsen@xmission.com
Dear DDJ,
Thanks for having a May 1998 Year 2000 issue of DDJ. I have a few comments: In their article "Date Compression and Year 2000 Challenges," Robert L. Moore and D. Gregory Foley say that, "The usable time span is no more than a century" is a drawback of the windowing method. While this is true, it is not a drawback for the problem at hand: If an application has been using a two-digit date (and hence a range of just one century) successfully for years, adding windowing to solve the Year 2000 problem will not effect the program.
As they concentrate on comparing dates, they fail to mention that date arithmetic may also pose a problem with windowing: Adding to, or subtracting from, two-digit years must wrap modulo 100. This means even more changes to the existing code.
None of the May articles mentioned a Year 2000 related problem that may also affect four-digit years -- using Zeller's Congruence to calculate the weekday. For small values of the last two digits (for instance, 1900, 2000), the sum term may become negative. If the modulo operator has a bug for negative values (a quite common "feature"), the weekday number may turn out negative. Accessing an array with weekday names will produce garbage or a range check. It is probably this that will cause embedded processors to fail (in air conditioning and heating systems that work on different schedules for weekends, for example).
The current Year 2000 debate almost exclusively focuses on two-digit years and 2000 being a leap year. I could not find anything useful on Zeller on the Internet (using Altavista). If we neglect the modulo bug, we are in for a surprise! There is a wealth of information on Zeller's Congruence in back issues of DDJ, including ways to fix this.
Jost Riedel
JRiedel@compuserve.com
Dear DDJ,
I am in general agreement with Jonathan Erickson's editorial "Banker, Can You Spare a Dime?" (DDJ, June 1998). During my university years (1964-68), summer jobs were easy to get, and a 70-hour week would net enough during a summer to pay all expenses for an academic year. Consequently, I didn't need student loans. These opportunities are much scarcer now.
Technical jobs were also easier to get. I was offered my first computing job in 1971 by someone who knew I had no experience or training, yet wasn't worried about it. I was expected to teach myself, which is exactly what I did.
In the '60s, much more of the world's work was visible to (nonworking) students. We saw people doing technical work -- enough to get me going to the public library for books years before I went to university.
I think that, in addition to student loans/subsidies, students need at least some understanding of what is done in technical jobs, beginning many years before they have to make choices. They also need an opportunity to take on jobs that are a little beyond their current skills/experience -- if they get these opportunities in part-time/summer work, so much the better.
Ian E. Gorman
ian@iosphere.net
Dear DDJ,
I enjoyed Jonathan Erickson's editorial "Banker, Can You Spare a Dime?" (DDJ, June 1998) and share his skepticism.
It may interest readers to know that, recently, the Ontario government offered to "deregulate" tuition for computer science/computer engineering if universities double their enrollment in these programs by the year 2000. (Deregulation generally means 50 percent per year increases in tuition until only the very well off can afford to attend.)
Never mind the logistics of more faculty, labs, and support staff to double enrollment -- but in two years? And the brass ring is you get to charge so much tuition that some of your best students will go elsewhere for lower tuition? Oh well, at least one brave soul at a recent meeting said, "Deregulate? That means we can lower tuitions too, right?"
Paul Lu
paullu@sys.toronto.edu
DDJ