Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
There was a big flap recently over Fidelity's Magellan fund estimating in November that they would make a $4.32/share distribution at the end of year, and then not doing so. A letter of explanation was sent to the shareholders (including me) from J. Gary Burkhead, the President of Fidelity, including the following pertinent items: "During the estimating process, a tax accountant is required to transcribe the net realized gain or loss from the fund's financial records (which were correct at all times) to a separate spreadsheet, where additional calculations are performed. The error occurred when the accountant omitted the minus sign on a net capital loss of $1.3 billion and incorrectly treated it as a net capital gain on this separate spreadsheet. This meant that the dividend estimate spreadsheet was off by $2.6 billion.... "Some people have asked how, in this age of technology, such a mistake could be made. While many of our processes are computerized, the requirements of the tax code are complex and dictate that some steps be handled manually by our tax managers and accountants, and people can make mistakes. The error in this case was not caught in the initial review, but was detected in our normal process--which includes a review by outside auditors--as we prepared to make the actual distribution calculation. "We have taken several steps designed to ensure that this error should not happen again. We will subject initial estimates to the same rigorous verification process that we use in preparing the distributions that the funds actually pay. This will include a thorough review not only by our own fund accountants by also by the fund's treasurer and independent auditors. In addition, estimates will be reviewed by each fund's portfolio manager." I'm still not clear as to exactly why a spreadsheet or other program couldn't be developed to make the estimation calculation, since the problem seems to have been a transcription error and not a failure to understand the complexities of the tax code. It also occurred to me to wonder what sort of testing the software they do use undergoes, and whether those procedures will also be upgraded in the wake of this mistake. I see two RISKS: The implication that this mistake only happened because manual steps were involved, and the risk of having infrequent but highly important tasks that require non-standard procedures (like "manual" calculations in a largely computerized environment). <>Kathy Godfrey kgodfrey@bbn.com
[Arthur sent us an excerpt from the 5 Jan 1995 edition of the *Austin American Statesman*, p D8 (omitted here), with the following comment. PGN] Even after reading risks all these years, I am still amazed that these kind of errors can slip by. The last time I entered a $1.3 billion check as a deposit in my checkbook, it was only a short time before I was bouncing checks left and right. It also was quite apparent when I balanced my check book at the end of the month. Art flatau@cli.com Austin, Texas
>From the January 4, 1995 Albuquerque Tribune front page: Hello? Hello? Phones go haywire in Roundhouse Your state government has been disconnected. Please check the number and call again some other time. As if Gov. Gary Johnson's call for the mass resignation of about 350 state officials weren't enough to confuse citizens in search of bureaucrats, the state's phone system on Tuesday began to arbitrarily shifting many 827-prefix calls to an erroneous recording that declared the number was not in service. The 827 prefix is state government's main prefix in Santa Fe. "I'm quite uncomfortable about the current situation," John Dawson, deputy director of the state Office of Communications, said Tuesday. "It's manifesting itself very seriously today for some reason. But I'm hopeful that it will be over in the next 24 hours." Dawson said a glitch in the software that controls the state office phone system was at fault for the complications. He said it appeared to be affecting only Santa Fe offices with the 827 prefix. The state was aware of the computer problem a year ago, and removed the software because of it, he said. But two weeks ago the state allowed its contractor, Fijitsu Business Communication Systems, to reinstall the software because the glitch supposedly had been removed." The article went on to describe the confusion, and the fact that our new governor was not getting calls. As might be expected, this happened right when a new administration was moving in to Santa Fe. So, if it was broken once, try to break it again at the most critical time possible. Sigh... Bruce Wampler, Ph.D. Adjunct Professor, Department of Computer Science University of New Mexico wampler@cs.unm.edu
[A longer message from Tim is floating around the well. This one seems quite succinct, and helps to clarify further the situation discussed in RISKS-16.69 and .70. PGN] Because the RISKS list gets pretty wide distribution, I wanted you to know that the original posting contains some pretty serious misinterpretation of a messy situation. Briefly, - CompuServe is asserting no proprietary rights in the GIF spec, and couldn't even if we wanted to, since it has long been openly published. - The LZW algorithm was incorporated from an open publication, and without knowledge that Unisys was pursuing a patent. The patent was brought to our attention, much to our displeasure, after the GIF spec had been published and passed into wide use. - We found it necessary to take a license to the patent from Unisys, and since a number of our developers had used GIF in good faith, we also negotiated a pass-through license for their benefit. Clawson has distributed parts of this license, with a poor interpretation, outside of its original context, which was to developers of CompuServe-related products alone. GIF is included in this license because we are unable to pass through a general license to practice LZW. - It is not the intent of CompuServe to attempt to enforce proprietary rights in GIF against users or developers, including those of Web technology. We cannot and do not speak for Unisys' intent in this matter. - Having and transmitting GIF images is not an infringement of the patent, since 'practicing' LZW means running code which accomplishes the compression of the graphics. Tim Oren, Vice President, Future Technology CompuServe, Inc.
The recently announced patent restriction by UNISYS/COMPUSERVE on the use of GIF files poses a potentially serious problem. The Internet community needs to protect itself from such arbitrary constraints by establishing a new public domain standard for graphics interchange. This standard needs to: 1) Be compact 2) Decode fast 3) Be free from patent/copyright restrictions 4) Be rapidly available JPEG is certainly a candidate as it is a public standard. The only drawback is the slow decoding time. However there is an alternative based on existing 'standards' that should give similar performance to GIF files. We can do this by: a) Representing the picture using the Portable Bit Map (PBM) format b) Compressing using the Free Software Foundation GZIP method. I have being trying this idea out to see if the performance is OK. Unfortunately I do not have PBM support on my machine, but I have been testing the approach using the Windows bitmap format (BMP). The tests were done on an PC 386/DX33 machine using 8 bit (256 color) files. The GIF and JPEG measurements were based on the LVIEW 3.1 public domain graphics package. Standalone DOS GZIP and PKZIP v1.1 packages were used for the other measurements. Results: Test file Cathedra.bmp Format Size (bytes) Encode (secs) Decode (secs) BMP 307,994 - - ZIP 185,866 14 6 GZ 173,314 15 6 GIF 197,548 8 9 JPEG 56,167 25 30 Test file simba.bmp Format Size (bytes) Encode (secs) Decode (secs) BMP 265,398 - - ZIP 109,760 15 5 GZ 99,748 14 4 GIF 113,895 9 8 JPEG 34,638 21 20 Assuming that BMP and PBM formats are of similar size, it would seem that a compressed PBM file format (GZF?) has advantages over the equivalent GIF file since it is smaller and decodes faster. The encoding time is slower - but this is a 'one-off' operation so it is not too important. It is also interesting to note that GZIP gives better compression than my rather elderly V1.1 version of PKZIP, and I think that GZIP will stand up pretty well against current compression methods such as those in PKZIP 2.04. I hope this starts a useful debate on defining a 'rapid hack' to provide a substitute for GIF format files. Obviously it is important that we get something that people are happy with - but quickly. One option is to set up a forum of current GIF providers and users who would hammer out a new format. The other more direct (and rapid) approach is to nominate a volunteer to define the format and provide the C sources so that the new format can be readily incorporated into existing graphics tools. The obvious choice here is the Free Software Foundation. It is part of their remit to provide good quality free software, and they are the authors of GZIP, so they should be in a good position to define the format and publish it via the usual GNU distribution channels (together with a GIF to GZF converter). Peter Bishop, Adelard, 3 Coborn Rd, London E3 2DA, England Tel : +44-81-983-0219 p_bishop@adelard.demon.co.uk
Along with the historical-interest postings on hardware math errors, it may be interesting also to consider software math errors. Here's one: The built-in BASIC on the TI 99/4A computer uses a certain shortcut for boolean calculations: it uses * for and and + for or. Operations such as ">" return numeric values, and the IF statement tests for zero or non-zero. Here's the problem: the 'numeric values' mentioned above are 0 for false, and -1 for true. So `` 10 IF (((1 > 0) * (1 > 0)) + (1 > 0)) PRINT "It Works" '' won't print anything, since -1 * -1 is 1, and 1 + -1 is 0. Chris Phoenix chris@efi.com 415-286-8581
While resolving a problem involving interactions of multiple systems we found we had a set of failure conditions which had a very low probability of happening, lacked any work around or avoidance strategies, and had very unexpected results when one occurred. We gave the name "Rutherford Effect" to such situations. The reason for the name "Rutherford Effect" comes from the experiment Rutherford and two of his students, Geiger and Mardsen did. They made a beam of particles project onto a thin metal foil. Most particles when through with no problem. However, a few hit the nucleus in of a atom in the foil and bounced back. According to legend, Rutherford said, "I would not have been more surprised if I had shot a cannon ball at tissue paper and it bounced back." The similarity of a computer mostly working but having a very small number of unpredictable and unavoidable failures inspired us to say it suffered from a "Rutherford Effect". The Pentium also suffers from a Rutherford Effect. Bill Thomas billt@core.rose.hp.com
The excerpt from the _Wall Street Journal_ about this incident reproduced in RISKS-16.67 is inaccurate. This incident involved Michael Wolff posting nearly 150 virtually identical messages to different newsgroups. (Actions of this kind are called "spamming", where "spam" is defined as the posting of 20 or more substantially identical messages to Usenet. The content of these messages is irrelevant.) These messages were cancelled by Cancelmoose. After the cancellation, the issue of these messages was discussed at length in alt.current-events.net-abuse, and a vote was taken, which was overwhelmingly in favour of the cancellation. There was nothing special about the Wolff postings; all mass postings to Usenet that fit the criteria of spam are cancelled. Cancelmoose is not a "vigilante", as he does not act alone; there is substantial agreement amongst the Usenet administrators that have contributed to this debate that these actions are necessary. Wolff claims to be an expert on the Internet; if this were true he shouldn't have been "stunned and amazed" by the response. Andrew
Cellular phones, when powered up, periodically transmit to the nearest cell, even when someone is not talking on them. For soldiers, that represents a risk that enemy troops will be able to locate them using direction- finding equipment and attack them, or call in artillery fire or air strikes on their position. That, I presume, is why the Israeli command structure is concerned about their troops carrying cell phones - and should be - notwithstanding the issue of time being spent on non-military tasks. Linden B. (Lindy) Sisk sisklb@texaco.com
Try the "leave" command if you're a UNIX person. It not only warns you that the time to logout is coming up, but proceeds to nag you after the set time passes. I've been using this since about 1988, since I'm in a carpool. Mary Shafer, SR-71 Chief Engineer, NASA Dryden Flight Research Ctr, Edwards, CA shafer@dfrc.nasa.gov URL http://www.dfrc.nasa.gov/People/Shafer/mary.html
Actually, there was (and perhaps still is) such a product for the Apple Macintosh called LifeGuard. It was reviewed in the February 1991 issue of _MacUser_ magazine. According to the reviewer, the memory-resident program produced an audible and visual alarm on the Mac after a length of time that the user specifies. It then reminded the user to take a break: "You control the frequency of breaks as well as the interval allowed before it's time to resume work." It also provided the user with a "snooze" function to temporarily override the alarm. It even offers suggestions for exercises and basic information on ergonomics, according to the reviewer. LifeGuard's publisher was Visionary Software, Inc., P.O. Box 69447, Portland, OR 97201 (800-877-1832 or 503-246-6200). I have never actually seen the product, just read the review. I wonder if it caught on and whether it is still available today (version 1.0 was reviewed). John C. Rivard jcr@garnet.msen.com JCR Design and Consulting Copyright (c)1994 John C. Rivard (just in case) :^)
Such things already exist. Coffee Break, a program for the Mac by Thomas Reed, was written to help reduce repetitive stress injuries. It allows you to set how much time you want to work between breaks and how long your breaks should be. It will then come to the foreground when you have exhausted your work time and will not relinquish control of your computer until after the break time has passed. I haven't used the program myself and can't speak in any detail about its features. It is available from the typical Mac ftp sites (I downloaded it from the umich archives: /mac/util/organization/coffeebreak1.1.sit.hqx.) Steve Brewer <brewer@cs.wmich.edu> http://141.218.91.93/WWW/I_sbrewer.html Science Studies WMU Kalamazoo MI 49008
Jerry Leichter said Leslie Lamport published an algorithm a couple of years back - essentially the trick that others have mentioned, of reading high order, then low order, then high order again, and retrying if the high order bits changed - that can be proved to get the correct time without requiring interlocking. The proof is non-trivial. Despite the assortment of trivialities that have been published as "Lamport's bakery algorithm", I am still not inured to the defamation of my algorithms. Please inform the Risks list that my clock-reading algorithm, published in AUTHOR = "Leslie Lamport", TITLE = "The Concurrent Reading and Writing of Clocks", journal = tocs, volume = 8, Number = 4, Month = nov, Year = 1990, pages = "305--310" requires no retrying. Leslie
Please report problems with the web pages to the maintainer