Lockheed Aircraft -- California Division

We at first had an IBM CPC (Card-Programmed Calculator), while waiting for an IBM 701. Before Lockheed built a machine room specifically for us, we were housed in an upstairs nook, notable for having green rugs on the floor. Having not much previous experience (except for a tab room), the building people had no idea that lint from the rugs would play havoc with the card-feed mechanisms. Later they supplied us with our own vacuum cleaner.

More than that, the IBM CPC itself was notably unreliable. It would keep feeding cards and printing paper pretty well, but we began noticing that the answers were wrong! To attack that, I designed and built a plugboard system called "FLODESC", for "Floating Decimal Self-Checker". It was customary in those days of decimal computers to calculate with floating point numbers comprised of 8 digits of fixed-point part (often erroneously called a "mantissa" in a corruption of logarithms) and 2 digits for the associated power of 10.

My scheme was to do the same computation twice for each card -- once in normal floating decimal, and once in a mode where the operands were the normal operands modulo 99. Accountants experienced in the age-old technique of "casting out nines" will know what I mean.

The limited capacities of both computer and plugboard were such that 8 digits were out for the fixed-point part. All I could manage was 5. You can see that it wasn't all that great for regular work, but it was a diagnostic tool that surpassed anything that IBM could supply -- it worked in the real computational environment.

It was fun to watch. Normal and planned output for a CPC was 150 calculations, e.g., 150 print lines, per minute. I had it set so that upon failure the computation was done again until the main answer (modulo 99) was the same as the answer from the modulo 99 only calculation. Imagine standing there watching progress. Suddenly the printer skipped a line, like a faulty heart missing a beat. Then it would go on, and skip some more. Often it kept on skipping at an increasing rate. I know that Grace Hopper discovered the first "computer bug", but hers was a dead moth. Mine was live, and you could see it grow!

While in that green-carpeted room we had a courtesy visit from John McPherson, IBM's "scientific" Vice President. He was so fascinated by my system that he cancelled his flight out and stayed an extra day to study the significance. This good impression of me served me well when I went to work at IBM some years later.

The Tab Department

When I started at Lockheed, the IBM 604 Electronic Calculator had become common. There were some in the tab (tabulator) room of the Accounting Department. I remember them well because I had to go there one day to explain to them how they'd goofed on my paycheck. For income tax purposes I had 8 exemptions at $13 each, which makes $104. Demanding to see the wiring board, I showed them where only two wires were coming out for that value, giving my deduction as only $04! They were a little chagrined.

Two memorable people in that department were Norval Johnson and Bill Simonette. The latter went to Lockheed Georgia when Bob Bosak did.

Analog Computer People

Lockheed had done much work on analog equipment at that time, and had its own Passive Network Analyzer, designer Dr. G. D. McCann of CalTech. There at the time was Dr. Granino Korn, a distinguished expert (and author) on analog computers.

One day Dr. Korn apparently decided to test the efficacy of these newfangled digital computers, and sent down a problem. It was given to me. I worried that, by the time I programmed the problem and returned the answers, Dr. Korn would have found the elapsed time too long in comparison to using analog equipment.

So I did the cases on a Friden desk calculator, punched the answers into cards, ran them on the printer, and had a sheet of answers back to Dr. Korn within 20 minutes. He said not a word, and it was decades later until I acknowledged the trick I had played on him!

Flutter Analysis

Flutter calculations were going on at this same time (under the charge of Amaya, not me -- I had structures), and the wings fell off of some Electra II airplanes. In the air, that is, not on the ground. I had my own theory as to why this was so, and it affected the floating point arithmetic design for the IBM 1401. Later I told Dr. Cuthbert Hurd of IBM that I would have gone over his head to T. J. Watson, Sr. if they had refused my design.

The basic difference was that if two numbers, added or subtracted, yielded a zero result for the fixed point part, the computer hardware assigned the resulting power to be its equivalent of minus infinity. In other words, to be zero with the lowest negative power the machine could represent.

But if there had been more digits of precision in those floating point numbers, the extra digits would not likely be the same, and the result would not have been zero! So the proper way for the hardware to have been designed would be to yield a result of zero, with a power that was the original power minus the number of digits of precision. When that result was then used with some other value, its influence upon the answer would be proper.

Of course there are other ways of corrupting floating point computation, such as computing intermediate results up to and past the limits of internal representation. There is probably some advice about this in text books.

I've been told that Dr. Alston Householder, a famous mathematician and numerical analyst, refused to travel by airplane because he knew that they had been designed by computers.

And "The Bad Blacksmith Blames The Iron" was written by a PhD candidate who nearly did not win his degree until he tried his thesis again on a new computer that did not have this floating point flaw!

A funny aftermath was that Tom ?? who designed the original Hewlett-Packard hand calculator made the same mistake. I called him up and argued and explained at length. He later changed it, and had happier users.

Genius Bob Bosak

As stated, both Bosak and I came from the RAND Corporation. By the time we were working at Lockheed, both of us were in divorce actions. So we decided to room together, picking a place in Hollywood, at 2025 N. Argyle. The third sharer of expenses was Bruno Chiapinelli. A very strange place at the time, and even more so later. An issue of Playboy magazine mentioned it as one of the main "swinger" locations in California. Of course that was long after we had departed.

Not to be without a piano there, I rented one. As we were away in the daytime at Lockheed, a friend asked if his friend Stan Freberg could use the piano during the daytime. I was happy to, but never met him. Different shifts. And I was also happy that my generosity enabled him to eventually afford his own instrument, as everyone knows!

The Lockheed plant was clustered about the terminal building at the Burbank Airport. On occasion we would go to the restaurant there for a midmorning snack. We didn't destroy the tablecloth, as in the movies, but one day Bosak and I got a joint inspiration, and on return from breakfast we started to wire a CPC board.

The essence of CPC calculation was to put the addresses of two operands and result, with the operation code, on the punch card. Sometimes a constant value, instead of an operand address. The inspiration Bosak and I had (equal credit) was to put three different groups of address values and operands in different fields of the card. We then wired the plugboard so it would switch to a different instruction set (in a different set of columns on the card) depending upon the result of some decision.

You could not call this "Stored Programming", but it sure mimicked that in mighty useful ways. Handy when you did not have a stored-program computer!

Note that my heading says "Genius" for Bosak, and then ask yourself "where have I heard that name in the last 20 years?" Right. Jon Bosak, of XML fame, is Bob's son. Not all great programmers have children that also become such, too, but Bob Bosak (d. 1987) was one. So was Conway Berners-Lee, with son Tim of WWW fame.

Cozzone and Structural Calculations

I did the programming for the "Unit Method" of structural calculations, much favored by Frank Cozzone. I was surprised many year later, when my eldest son was in Graduate School at the University of Michigan, to find him very cognizant of that system. And he was surprised that I knew of it.

What I was happiest about was being able to use the lofting methods I learned at Douglas Aircraft for the benefit of their competitor Lockheed. A vertical-rising fighter was being designed. I refined "the lines" (exterior contour and structural parts) for that. The computer came in handy. As example, I computed the dimensions of a theoretical bulkhead every half inch along the entire fuselage. An engineer wishing to move a bulkhead location already had the new dimensions in the tables provided.

The 1952 Elections

1952 was the year when UNIVAC became famous for predicting results of the U.S. Presidential Elections. That was in New York. Out in California I built similar programs, on a more modest scale (i.e., without predictions). The NMAA newsletter said this:

"In New York, one of these units [CPC] was set up in ABC's mammoth Studio 1, while the calculator located in the Mathematical Analysis Department of the Lockheed Aircraft Corporation's Engineering Division at Burbank, Calif., furnished swift, accurate plotting of returns to viewers who were tuned to NBS from the west coast."

That election work exposure apparently triggered the bid from Marquardt Aircraft to start a computer section for them. I could not resist the opportunity to at last run an entire computer operation on my own, so I left Lockheed for Marquardt in that very November, right after those elections.