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…
(Bruce Wampler)
To: RISKS@ucbvax@csl.sri.com
Subject: America's Cup: Left-over Digital Filter
This story is from the NOVA "Sail Wars" of 9 Dec 1986:
This NOVA was about the design of Stars & Stripes, one of our entries in the
current America's Cup event in Australia. There were two interesting
stories, both having to do with modelling and tank testing of scale models.
Apparently in the early 70's, Ted Turner had a boat built directly from a
tank model. The boat worked wonderfully in the tank, but was a total dog in
full size. This design disaster soured American designers on tank
modelling, ultimately resulting in the loss of the America's Cup 3 years ago
to the Australian boat, which had been designed using modelling. In the
70's, the models were apparently on a 1:13 scale.
The current entry was designed using tank modelling (1:3 Scale). Stars &
Stripes went through 3 versions. Much of the design was aided by computer
modelling, followed by building of scale models for tank testing. The tank
testing was closely measured, and the results again fed through
computer-analysis programs. The design was getting down to the wire for the
3rd version of the boat. Measurements fed through the analysis programs
indicated a serious problem with the stern of the boat. The designers were
visibly depressed. After some modifications, new measurements indicated the
problem got worse. At this point, they really were out of time - either
give up the 3rd version, or find the problem.
In a sort of "sanity test", the designers refused to believe the computer
output. This was apparently standard naval architecture software and well
trusted, given the reluctance shown to disbelieve the results. At any rate,
after a long all-night session, they discovered that "a digital filter used
previously for an oil platform test had inadvertly been left in the computer,"
thus causing the wrong results. With the filter removed, the measurements
showed better than expected performance. (Not good enough, apparently. The
yacht New Zealand seems to be cleaning up in the challenger races.)
[Moral: Don't forget to change the oil filter. PGN]
"mugs" — Trojan horses and other intentionally introduced anomalies
"plugs" — interface errors
"ugs" — a bug isolated to a small piece of code, the sort of thing you can
stare at for hours, and all of a sudden someone walks up to ask you
if you want to go to lunch, glances at your work, points to the
offending line of your CRT or listing, and says "you know, ..."
[ughs?]
And in the case of a large installation the back-up power is most impressive. I had a chance to visit Air France's computer center (somewhere near the Riveria) several years ago (pure boondoggle, I admit.) As I recall there were about three floors (basketball court size, maybe) of Univac 11xx's and disk farms (two approximately duplicate systems, each at least two processors) and comm gear etc. On the ground floor were at least two, maybe three diesel generators that would do a small city proud. Short of a nuclear attack that system was not going to be shut down by anything! (and yes, they made sure the fuel tanks were full and periodically tested the generators — I don't remember the mechanism used to keep power up while the generators were starting.)
It has been generally accepted that software for BMD must perform a variety of functions, including tracking targets, discriminating between decoys and RVs, and so on. As importantly, the software must be constructed in such a way that all the parties are confident that it will perform these functions when called upon to do so. This list of functions raises an interesting point. I agree with the list, but am troubled by its dependence on system architecture. Specifically, we could imagine a "BMD" system that consisted of thick orbiting shells of gravel at 500 km altitude. No ballistic missile now known could penetrate that, and we could have confidence that it would work. The software would not need to perform any of the functions that both critics and supporters of SDI agree must be performed. The sole issue is the cost of putting all that junk in space. The existence of this "alternative" BMD suggests that the "software" needed to control it need not be complex, extensive or unreliable; the system just proposed doesn't need it at all. However, no one thinks that an actual BMD will not require software. Thus, we conclude that for deviations that are "large enough" from "prototypical" architectures, the software problem can be made tractable. An interesting question arises: How can we develop more precise measures for the phrase "large enough deviations" and the word "prototypical"? The Eastport Study used such an approach; they said that an unconventional architecture would make the software problem tractable. The argument above suggests that for a sufficiently unconventional architecture, they are right. My problem with the Eastport study is that they have not made an argument that their preferred architecture is even in the right direction of "unconventionality", let alone "far enough"; indeed, I think they have gone in the wrong direction. But my problem with my own position on BMD software (i.e., very critical) is that I have constructed an existence proof that says that in some circumstances, I am wrong. What are those circumstances? I can't speak in general, but obviously one issue is cost. If you are willing to spend enough money (in the case above, on lift costs), the software problem is tractable. My intellectual question is "Where do I draw the line?"
I noticed in the paper recently that the former mayor of Syracuse (Lee Alexander??) was fighting a federal court order. The court, on prosecution request, had ordered him to instruct a foreign bank to tell the prosecution all about his bank transactions. The paper said that the ability of the feds to require this was a matter of "settled law"; Mr. Alexander was merely fighting for the privilege of adding the words "under protest" before signing. Seems like the same rules might apply to other forms of records, such as computer disks. The penalty would be contempt-of-court. garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu) Cornell Engineering & Flying Moose Graphics
Brian Randell writes: > The St. George's claim is particularly worrying because the school has a > better record on discrimination than most other colleges. > The computer selection programme was designed to mimic the decisions of > the school's panel which screened applicants to see who merited an interview. > It matched the panel's results so closely that the panel was scrapped and > for several years all St. George's applicants have been screened by computer. One is tempted to say that the two statements, (1) they were better than average on discrimination and (2) they were following a process that was well modelled by a discriminatory program, are contradictory. Of course, they aren't. Assuming the program was just based on assigning weights to a lot of factors typically used in admissions decisions, it's not hard to imagine that they hit on a set of weights which happened to work well on the training set but were not really reflective of the pre-existing judgment process. This is dangerous, though, in that it may appear to courts and other bodies that the inference can be drawn; that the existence of a biased model which would explain a behavior is proof that the behavior was biased. This would make the concept of de facto discrimination much more broadly applicable (though it is, in fact, the general basis of that concept). It does remind one that testing the results of an "expert" system should be coupled with review of its rules. scott preece, gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece
It's quite easy to damage an IBM Monochrome monitor by plugging it into an adapter (like an Enhanced Graphics Adapter) which is configured for a color monitor. Both types of monitors use the same D-connector. Admittedly, there is a warning in the manual about this, but, after setting up about fifteen other PC's, I had pretty much given up reading the manual in detail ..... Al Stangenberger, Forestry, Univ. of Calif., Berkeley
Please report problems with the web pages to the maintainer