An Interview with Bob Cralle

Bob Cralle


BC = Bob Cralle
GAM = George Michael



GAM: Today is July 7, 1995 and I'm interviewing Bob Cralle, who began at the Laboratory even earlier than I did. I'll just let him tell his story from the beginning.

BC: Well, I started at the Lab on April 7, 1953, six months after the Lab started, and retired October 1, 1991. My name, by the way, is spelled CRALLE, which is usually mispronounced "Crayle," even though there's no English word with "all" in it pronounced "ayle." The correct pronunciation of Cralle is KRAW-lee.

Anyway, on April 7, 1953, the Lab received a UNIVAC, which essentially was the first commercial computer (the one that predicted the 1952 presidential election winner-Eisenhower).

GAM: I'd like to say that when I got there on April 16, 1953, the UNIVAC had been delivered, but it still wasn't running! It took about six months to get it to work. Do you remember?

BC: Well, I've forgotten exactly. I know we were off in a room in the "cooler" solving math puzzles. Then we did get some sort of the C-10 code, which was the instruction manual for the UNIVAC, which was not very large. And we started to program things, not necessarily that were going to be used, but just to run something on the UNIVAC.

Before I forget it, one of the many things wrong in the Lab's 1992 glossy presentation of the early days was that the UNIVAC was a binary machine. It was a decimal machine. It had 12 decimal digits per word, and you programmed in decimal. That is, the op codes were letters, and the addresses were absolute decimal numbers. There was no assembler, although the glossy report said there was. Everything got into the UNIVAC through the talented fingers of Cecilia Larsen, who is now retired but still comes in. In fact, she would type your code in while she carried on a conversation with you! There were no IBM cards. So everything was typed by Cecilia onto a steel magnetic tape. We called it the "Input Tape".

That reminds me of the time somebody on the UNIVAC asked one of the technicians to unload a tape for her. And he said, "Unload it yourself." And so the person did. She tore the metal tape right in half where it was, and let go. Of course, it unwound a good portion of the 1,800 feet of tape onto the floor! The technician walked around with an armful of it and said his mother said there'd be times like this.

Anyway, the UNIVAC was, as I said, decimal, and there was no assembler. So if you made a mistake, you had to jump out of the middle of your code to some free memory, fix it, and jump back. Then, of course, the thing today that would cause programmers fits was the fact that there was no floating-point. Numbers were integers, and keeping the scaling correct was a very critical problem in your code. You kept the numbers shifted, so that when you did arithmetic you didn't get an overflow. It was a rather large problem, and it's the reason the floating point was invented, as well as the reason physical constants were changed in the physics codes, e.g., a "Shake" was 10-8seconds.

So, that was one of the early things, and the first code I worked on that the Lab cared about was a code on the UNIVAC that did two-dimensional hydrodynamics. Lewis Carroll had a story called "Hunting of the Snark - an Agony in Eight Fits." I think we called the code the latter. We had eight memory loads of the code from mag tape-we had only a thousand words, that is, 12 digits each, times a thousand-to get twice that many instructions in, because instructions were half a word or 5 decimal digits and a letter. And that was one of the largest codes in those days. I've forgotten the others that were running then.

GAM: You know, I had a big program, too. It filled memory many, many times while it was executing, and it had to run between 20 and 40 hours to get it to develop the entire simulation that we were after. And the overflows and underflows, and all that sort of stuff, were a continuing problem. You're just right.

BC: And there was another interesting thing-the machine, through the arithmetic registers, did things twice. Then it compared the two registers containing the results, and if they didn't agree, it stopped. If you were there, you got to choose which answer you liked. And it went on, or you did something else. Can you imagine doing that today?

GAM: Thank God we don't have to!

BC: By the way, in those early days we had a group of people, headed by Glen Culler, who were called Hand Calculators. And they calculated the first cycle or more, of codes by hand to compare with the computer results to see that it was correct. As far as I know, that's not done in any explicit way any more, other than people look at it and they know the physics, and they say, "Yeech, that can't be right." But lots of calculations at the Lab, in 40 years, have gone awry and were not caught for a long time. For instance, in one program, the atomic weight for Uranium was set incorrectly at 328 for a long time, I believe, until Peter Giles put out a note that said, "For those of you who look at your printouts, we'd like to tell you that [for however long it has been] the atomic weight of uranium has been in the code incorrectly."

So, we had a lot of fun on the UNIVAC. I remember, on somebody's Monte Carlo code, that Harold Brown-who was later the Lab Director and head of our Defense Department in the Carter Administration-used to come down and sit there and pick the starting random number, I believe from a phone book. And in those days, of course, we used a mid-square [1] to generate the random number, which turns out to be a very bad random number generator-for reasons I've forgotten.

So, I worked on the UNIVAC and, prior to that, on a CPC, a small machine that you ran IBM cards through over and over. It was an IBM machine, and Joe Brady did an awful lot of astronomy that way. And you sort of had to be dedicated to take a two-foot drawer of cards containing the program and data and keep running it through by hand. I also remember a bi-quinary machine of IBM's-what was it called?

GAM: The 650.

BC: The 650, right. And I did a little stuff there, but I've forgotten what it was. I even ran the CPC, too. I don't know why I did that, either. But it was fun for a little while. Then, the next machine I believe was an IBM 701. I did very little-it had no floating-point, and as George Michael will tell you, the Williams-tube memory was so flaky that you'd get any number of different answers if you repeated the runs.

GAM: Amen.

BC: So, it was a big headache. I believe the next machine was an IBM 704, which was our first floating-point machine, and it was much easier. And right in there was the beginning of FORTRAN, and one of us-Bob Hughes-worked on that project at IBM.

GAM: This is now vintage 1956 and '57.

BC: Yes, '56 I think, when we got one that ran, but I think it started back there in '54. But I don't really remember. An interesting sidelight is that Lukasiewicz, who asked the question, "can you write a logic statement down without any parentheses to separate the terms-that is, so you know what order to combine them in?" That's why we put parentheses around things that we were going to multiply and add. He proved that you could in 1951. And, of course, what he invented became Polish notation. ("Polish," by the way, is the only word I know that, when capitalized, changes its pronunciation-polish to Polish!) Anyway, the people who did the first FORTRAN were unaware of his work, which allowed one to easily do one pass through an algebraic statement and parse it into instructions with which the computer could compute. As I remember the first FORTRAN, it was 43 passes through the source, and when they came upon a parenthesis, they would simply wheel up the source code until they found the closing parenthesis, and then get inside and keep doing that, back and forth, until they had all the terms programmed. I don't remember if the 700-series IBM machines running FORTRAN ever used Polish notation, which immensely simplifies being able to compile algebraic statements.

GAM: Well, I think the later FORTRAN compilers did use it. I remember reading their logic manuals and I was really enchanted by the methodology and used it subsequently in all kinds of things that I did with this parentheses-free notation. It was great stuff.

BC: Well, I remember learning what it was all about by going over to Lee Krider, who was head of the compiler group, and in 15 minutes on a blackboard he showed me how slick all that was. I then wrote a subroutine that would do that because-probably it was an IBM 7090 or 7094 by then-I wanted to add two things together.

GAM: SCRAWLTRAN?

BC: SCRAWLTRAN let you write on a CRT face with a light pen. Then I would put that into a subroutine that I wrote to evaluate it, so that if you wrote 2 2+=, it would put 4 on the screen for you automatically.

GAM: Yes, and that was on the 7090.

BC: Did we have a DD80 there?

GAM: Yes.

BC: -which was a large and fast display device; 19-inch or 20-inch?

GAM: I don't know how big the console was.

BC: I had a lot of fun with that hand-printing recognizer, and did a setup to nail Norman Hardy, who printed a B by going straight down like a 1 and then coming back up like a 3 to complete the B. And then when he printed a 2, he would do it exactly backwards. He would start at the baseline and go back up. So, anyway, I put in a recognizer that noticed both his B and 2, and then we finagled Norman to go try this recognizer thing. He wrote A, B. And as soon as he put the B up, I put up on the screen, "You print like Norm Hardy!" He was somewhat bewildered. I said, "Well, go on!" And just as if we'd programmed him-he was going to put 1, 2, 3-and he put 1, 2. And so I put up, after his 2, "By God, you are Norman Hardy!" Norman got up and walked around the machine looking for how we'd done that. He was totally fooled! That was a lot of fun.

GAM: That was one of the great, all-time put-ons. No question.

BC: And I think we recreated it and made a movie of it.

GAM: Yes, we did. And it's around somewhere in our archives. Just for the record, the recognizer that you were using was something that Warren Teitleman first developed as a graduate student at MIT, and then was polished by Cliff Shaw, at the RAND Corporation. And I brought it to you in the form of a report, and-

BC: Yes, you did do that. I went down there to interview for a job, believe it or not, and when I was down there, I simplified their version. They used the 3x3 matrix-whereas, I used 2x3. You know, I looked at line crossings and things. And it was time-dependent, so that's how I knew how Norm printed his letters.

GAM: It's a beautiful piece of work.

BC: And I remember Keith Uncapher was the manager at RAND. By the way, it points out, in those days, what you could do without the large load of management the Laboratory now has, and has had for, oh, maybe half the time I was there. Most people in the technical fields, and certainly computing and physics, didn't have actual assignments by administrators. The group of technical people got together and decided what was needed and they did it.

I-being incredibly lazy and agreeing with George Bernard Shaw that circumvention is the mother of invention-I was on a large physics code, making sure that all the input got correctly installed. And this was a card per zone, and they had to be in order, because this was a two-dimensional calculation. And I decided, well, that's got to go. So I built a code called ZIG, for no particular reason and I have no idea why I called it that. The Z might have had to do with zoning, but I think I just liked the word ZIG. Later, Norbert Ludkey wrote a postprocessor called ZAG, so that was sort of fun. But nobody assigned me to do that. My laziness simply said that, "I ain't gonna do that anymore," because if your deck got out of order, you had to go sort it on an IBM card machine. And I decided I wanted all input independent, that is, the cards could be in any order. Every card (zone) also still had either a k and l; two numbers designating the zone, or it had a range, and it would fill in the ones you left out by using a relaxation scheme, mostly developed by Bill Schultz and with some modifications by me. It made the card decks much smaller, and it gave you a printout that was a visual picture of the zoning.

GAM: So that's what ZIG did?

BC: That's what ZIG did. It also checked for crossed zones (bow ties) and other bad input. It was the automated input to that big code. By then, instead of my doing it because of ZIG, the physicists did it themselves, which I liked immensely. And a lot more parameter studies therefore, could be set up to run. Remember, this program took something like 15 to 100 hours to run on the supermachines then, which by then were STRETCH and then the first of Control Data's 6600 series.

GAM: The STRETCH came in 1961 and the 6600 got to the Lab in 1964.

BC: Yes, and we started the time-sharing OCTOPUS in '66.

GAM: 1964.

BC: We started to program it?

GAM: Yes, well, Norman and Bob Abbott and his crew started programming that based on what was known about the Genie Project in Berkeley, and they started that in late '62 or early '63. So, when the 6600 got in to the Lab in '64, April '64 I think it was, they were ready to run.

BC: You know, I'm remembering '66, but I sure wouldn't swear to it. I know the 7600 was '69.

GAM: Yes.

BC: And I programmed all of those machines. One of the things I really enjoyed doing was plotting pictures, especially the zone layout of the design codes. I wrote a scan converter, which took the end-point data of the lines and turned it into drawing the line between the two points. I did a hand code of that, and that inner loop was extremely fast. By the time I put it on the CRAY, it was putting a dot on the screen every half a nanosecond. And that means "faster" than light goes, what is it, a foot in a billionth of a second?

GAM: Close to a foot a nanosecond.

BC: Right. Anyway, that was a very interesting thing to do. Back at the 709 or -90 or -94 time, I remember really enjoying discussing a code with John Fletcher that he wrote using a peculiarity of the FAP assembler program, and it had incredible ability for unwinding in a "macro sense" as we would say today. But it had things that most macro-generators don't have today. Anyway, he wrote an assembly program that solved the Pentomino problem. It was later published and an instance of it was on the cover of the CACM Monthly. I've forgotten the year.

GAM: Yes. I, too.

BC: Anyway, I then later, much later, made a translator of John's idea to run that program on a CRAY. And, of course, there are only two solutions to putting the 12 pentominoes into a 3x20 matrix. But in the 6 x 10 case, there are 2,500 solutions. John's code, of course, printed out all of them. I don't remember how long his code took to do that-it probably first ran on a 7090?

GAM: Yes.

BC: But on the CRAY, of course, it was done faster; it seemingly was instantaneous. And the interesting thing on the CRAY, since we had an online DD80 and we had TMDS-that is, Television displays in our offices connected to the supercomputers-because of the time-sharing, you could watch this actually solve the problem.

GAM: Yes, it was beautiful.

BC: And the nice thing about it is if you ran it, since it was small, you could see when you were running it, therefore, how accessible the computer was, at least for small codes at that time. So, from then, after the STRETCH, the 6600, and the 7600 in '69, then came-oh, in between there was a LARC machine. I put almost nothing on that, maybe one or two things. The LARC was also a decimal machine, largely because of the Lab's decimal experience with the UNIVAC; we specified decimal in our specifications. Actually, today we would call both machines a form of "binary coded" decimal system. I used to mistakenly believe that all machines should be decimal, which is simply dead wrong. They should be and are now binary, or these days, hex, which is still binary in a real sense. The LARC was late '50s.

GAM: The LARC got to us in about 1960.

BC: Very late.

GAM: Very late. It was about three years late in delivery.

BC: Did the STRETCH come about the same time?

GAM: No, the STRETCH came out a year and a half later-1961.

BC: So, after the CDC machines, 6600 and 7600, we began the era of the CRAYs-although the 6600 and 7600 were also, of course, designed by Seymour Cray while he was still at CDC. And we had lesser machines before the 6600. We had a 3600, which was done by Control Data (Cray) also.

GAM: The 1604?

BC: The 1604 was Cray's first machine.

GAM: First was a 160 machine.

BC: A first machine for Control Data. Didn't he have a little machine for somebody else? Maybe not.

GAM: I think the 160 that he also designed-one of the ones, the 160Z I think it was-he designed. But that was also a CDC product.

BC: Anyway, the era of the CRAYs started in the early '70s.

GAM: Well, for us it started late. In general, it started in '76 when Seymour delivered his first CRAY to Los Alamos. Remember, we were being punished because of the STAR.

BC: Oh yes, the dear old STAR.

GAM: But, a machine that formally introduced vectorization.

BC: Other than FORTRAN, on every other machine I did some assembly language programming. The STAR grudgingly did some FORTRAN programs. But that's an era I was not that much connected with, although I still serviced our big design code. I know in this that Charlie Springer programmed it for the 6600. And he did that in his assembly language, CREEP. Charlie Springer was an ace programmer. He programmed in assembly language on paper, in ink, with no blank lines, he just put down the instructions one after the other, and I always thought, "that's impossible." But Charlie, of course, was probably one of the best programmers I've ever known. It reminds me of a Seymour Cray story. When the first 6600 was being built, and Seymour wrote the operating system in absolute binary-you know, without an assembler-and people were bewildered and confronted him with that feat. When someone wanted an assembler he would say, "Well, what's the matter, don't you know what you're doing?" Which, of course was actually wrong, even though he didn't use an assembler. Being against assemblers really makes no sense-like people who argue now against computers and word processors-saying that they'd rather type. They have simply arrested their development, unfortunately, for God knows what reasons.

GAM: I agree.

BC: So, the era of the supercomputer really started with CRAYs for the Lab, and that's what it's been ever since. Then the MAC came along, and while it wasn't fast, it was remarkably pliable. And then, Sun Microsystems started to develop integrated computer graphics servers.

BC: I guess today, in 1995, there's less reason to have supercomputers for all computing because of other auxiliary, fast computers, including being able to network them together, like NeXts, where you can have 50 NeXts working on the same problem, say, factoring, and actually get something new done you couldn't get done with just one. I believe it was Richard Crandall who connected 50 NeXts together and actually showed, by some mathematical method, that Fermat's last theorem is true for exponents less than 4 million. And that's pretty incredible.

GAM: Well, I think that these successful interconnections of a whole bunch of little computers to do problems and so forth works okay when the thing is not I/O-intensive. But as our large design calculations at the Lab or at NASA or at other places show, any time you really want to do a large simulation, the people go, willy nilly, to a CRAY, mostly because the I/O is fast enough; it is a balanced computer.

BC: Well, remember Cralle's Theorem: If you have anything that depends on the fast floating-point multiplication, you don't really understand the problem.

GAM: Well, that may be true, but I'm not talking about depending on floating-point multiplication. I'm talking about being able to produce all the answers-an incredible number in times that are acceptable to the researcher. You know, over at NASA there are files for aircraft simulation, whole-body aircraft simulation-that occupy hundreds of gigabytes.

BC: Yes, too much multiplying!

GAM: Well, you're not gonna do that on 50 NeXts.

BC: Well, not yet.

GAM: I don't think you ever will. Those things are built by taking parts and putting them together. The CRAYs are built by designing parts that work harmoniously together and get the thing into a small space, and so forth. So the whole machine is fast and balanced. I'd like to suggest that the architecture of 50 NeXts isn't right for the kinds of big codes we run here.

BC: Except, Cray won't live forever.

GAM: That's unfortunately true.

BC: And it isn't obvious there's anybody else on the horizon. I remember an anecdote with physicists I used to work with. And it's a chiding of FORTRAN believers who, typically, since the beginning of FORTRAN, gave up half the speed of the machine to put things in FORTRAN.

GAM: At least.

BC: But if you grew up actually seeing the bits through assemblers, and so forth-I had a physicist come in my office once, and he had the following problem: He had three numbers, and he guaranteed me two of them were equal. And he wanted the third one. And I said, well, why don't you just exclusive OR the three numbers together? (And that's got a slight problem because CRAYs had all ones as a zero and also all zeroes as a zero. But it wasn't a major problem.)

GAM: Yes.

BC: You could solve that ahead of doing what I said. And this avoided testing, and of course it was one instruction long to get the answer. Something I claim, unless your a bits man or Boolean-orgyist-though you could fake it in FORTRAN. FORTRAN later got the logical connectives-but they never gave you an exclusive OR. And so, I think it takes a minimum of five ANDs and ORs to do an exclusive OR. So, you're almost back to the speed it would have taken if you'd done a test, except tests were bad on CRAYs, as far as time-it drained the instruction stack. Teller came to my office one day and he saw a sign on my door: "Boolean Orgy in Progress." He said, "I can see The New York Times now: 'Teller Involved in Boolean Orgy.'"

GAM: Let's nip back in your memory to the kind of stuff you were doing to develop some graphics programs.

BC: Well, I remember, now that you mention it, a program I wrote which nobody wanted. Ed Fredkin first described this in a talk, or he wrote it, and I forgot what we called it. Anyway, it involved taking a screen full of bits and forming the exclusive OR of the eight neighbors, of the bit that was in the middle of each 3 x 3 array. It turns out, I believe, you could put two circles on the screen, or two discs that were all filled in, and if you simply did this calculation over and over-the exclusive OR thing-one circle passed through the other over time!

GAM: Yes, we have slides of that.

BC: And I always thought, you know, that's just fantastic. Well, I made some color Polaroids off the screen.

GAM: Yes, right.

BC: I always thought that that was just phenomenal, because it meant the structure in any given moment remembered everything, because it ultimately ended back where it was. And experimentally, it was fun, at some time, to flip some of the bits, and see how it changed when it came back; but I've forgotten the details.

GAM: Well, I remember that after an iteration of some power of two times, it would multiply the figures around the screen, but each occupying a smaller area. For example, you started with one circle and it got to be two, then it got to be four, then it got to be eight, and so on.

BC: And the iteration right before where you saw the replication-

GAM: It looked like pure chaos.

BC: Well it appeared to be random.

GAM: Appeared random, yes.

BC: It always blew me away that you could do that. I thought it would be a great way to encrypt data, because it's not true that there are no unbreakable codes, as some people would have you believe. If they don't know what you're doing, there are unbreakable codes, and there's no way in hell you're going to decode it, since this would obliterate the content. And if you didn't know that you had to run it through this algorithm to get it back to clear text- It's as good as a trap door. I mean, as long as you don't know what was done.

GAM: Apropos of computer security and cryptography and so forth, why don't you talk about your adventuring with breaking into computers and stuff like that?

BC: Oh, yes. I forget the year of that. It must have been in the '70s.

GAM: The early '70s.

BC: The break-in was on the 7600, I think. Yes, it was, because it depended on there being two kinds of memory; it depended on the fact that, if you did a fetch out of memory, out of your memory space, you got the word anyway!

GAM: Well, the operating system essentially did this, right?

BC: Well, I don't know if they used it, but Al Ciplickas and I wrote a code to use it. In fact, it's interesting how this came about: We were there late one night and the machine was down. So, I was reading the 7600 manual, and it said if you fetch a word out of your memory space, you'll get an interrupt, but you also get the word! And so we decided that it might be fun to download the whole system because the passwords were in there-we thought. And so we did. And we made a little short loop that fetched from the beginning of system memory, which I think was the first 131,000 words of memory. And we'd take an interrupt, store that word that we fetched out of the machine, and do this in a loop till we had all of it, and then we printed it. I believe the passwords weren't in clear text, but somehow or other we knew which routine undid them. So we read that code and found out how they were encrypted, and I've even forgotten how they did it, but it wasn't hard to unwind. That was the gist of the first break-in, and the first fix I think really was that you bombed out if you fetched out of memory. The operating system made you go blotto. So we ran a controller-controllee system, where one code could run another code. We simply made a code that ran a code that took the bomb, got the word, and of course when that code bombed, restarted the first code. When this became known, the hardware was fixed in a hurry, so that you got zeroes, instead of the actual word you fetched outside of your space. And that was I think the only break-in on the 76s that we did. The others were on the PDP-10.

There, because of the encryption system John Fletcher used-and I remember where he multiplied two words together, and he kept the least significant part as the encryption. I had a Marchant mechanical calculator at the time reverse the encryption-but this is now rather hazy. Anyway, whatever the method was to decrypt, it involved an unknown word multiplied by your password to do the encryption. In any event, I wrote a code that was able to reverse things. It depended on something about arithmetic which also I can't remember. Anyway, that worked quite nicely.

And then we stole one programmer's password to get in originally to do this, and then those got changed. And so, since we had access to the console where the PDP-10 was-the hub of the OCTOPUS time-sharing system-we decided, since we were desperate, that if you used a TV set that was connected to the PDP-10's console-we knew where the passwords were kept, and so Al would type something-that would bring up a part of memory in the display. Although there's no reason that it was true with computer speeds, we decided that if we said, "Bring up that part of memory," that if you turned the freeze switch on the TV fast enough or at the right time, you could lock up on the screen, the encoded passwords. Since we already knew how to reverse the encryption, we were in! I remember using that, plus several other methods, to get in five times. And, of course, it was not considered nice, even though we were employees, and should have been paid to break in or at least asked to see if we could.

GAM: Do you remember the context of the term "paper sack programmers"?

BC: Oh, yes. We had an administrator who was in A Division, and then became Sid's assistant. He said that before he went in Comp, he thought the A Division programmers were really good, but after he got into Comp, he noticed they couldn't program their way out of a paper sack. We even took that as the name of our hole-in-the-wall gang-we became the paper sack programmers. Anyway, those were the days when you could have lots of fun, but you no longer can. At least, I don't know any comparable thing you can do now that's as much fun as we had then.

GAM: I think that's true, unfortunately. Well, there are lots of other adventures to cover, but they will have to be deferred to another time. For now, I'd like to thank you for taking the time to share some memories of the "good old days."


Editor's note, added Thursday, June 22, 2006

The Second Interview

I had intended that one of the topics in this second interview would be Bob's authorship of the "Computist's Corner", a charming collection of mathematical things that appeared in the Computation Department's publication "The Tentacle". There are two complete issues of The Tentacle on Page 4 of this site.

This publication was sent to a very large readership both within and outside the lab. It was gratifying to say the least, that Bob received many glowing comments from all over the world. There was even a technical publisher that wanted to publish the columns as a book. However, Bob never finished preparing them for publication.

Sadly, Bob passed away in 2004, before we managed to get together for a second interview. It was due to a continuing series of vacillations, procrastination, and inertia; when I was ready, he wasn't, and vice versa.

In lieu of an actual second interview, I'm including below one of his columns, and there are other samples of Bob's "Computist's Corner"Tentacle columns, on Page 2 of this site. They serve as examples of the strong eclectic flavor they exemplified. This column was something he loved writing.

In the fifty plus years that I knew him, I never saw him work harder than on the presentation of the material that appeared in his columns. The topics were always interesting, and their presentation was both light and tasteful. I know he saw these articles as a way to enlighten the department managers about some of the beauty, scope and power of mathematics; especially its computational expressions.

 




[1] Mid-square: An 11-digit number was squared yielding a 22-digit product. The random number was taken to be the middle 11 digits.