Career, Family And Living For The Lord
-
A Twenty-Five Year History

by James Thomas Lee, Jr. 12/25/97 Copyrighted 1995 by James Thomas Lee, Jr. Copyright Number: XXx xxx-xxx


Chapter Contents

               Chapter 7.  Becoming A Specialist For The Navy {1,476 words}

               a.  Geographical Mathematics (Great Circle and Rhumbline) {1,143 words}

               b.  June 1978 - Debbie's Coming Home {230 words}

               c.  August 1978 - Losing Pam {529 words}

               d.  September 1978 - Learning About Our First Grandchild (Michael Scott) {107 words}

               e.  April 1979 - Designing And Developing Positional Analysis Graphics {1,460 words}

               f.  June 1979 - Best Estimated Position (BEPOS) {702 words}


Part I: Early Development As A Christian Mathematician

Chapter 7. Becoming A Specialist For The Navy {1,476 words}

After the Route Generation program was put aside, I moved more into the unit tracking part of the Navy systems and worked on a program called UNITRACK, which stood for Unit Tracking. That program was actually a large system which did a number of things, including using the overlayed version of RTGEN to produce a shipping route between two points on the earth. I did not especially enjoy UNITRACK because it took me away from the mathematics and computer graphics which I had so much enjoyed. So, I did what I have often done when I needed to fill some extra hours. I wrote programs!

A lot of people in a professional working environment socialize with others in the office when they want or need to take a break. That happened in our office, too, and I did some of that. But mostly, I used those idle moments to experiment and write some fun-type, computer programs. Once during those years, I wrote a program which drew a very distinctive-looking beer bottle. Then, I used the graphics text writer to put the caption, "Weekends were NOT made for Michelob," on the screen beside the bottle. I had also learned how to use some of the graphic library switches and was able to make the picture and caption change size at the touch of a single control. I learned how to move the picture around the screen and even to rotate it so that it would display sideways or upside down. I know that working on that kind of program was not work-related, but I had fun doing it and learned a lot about the TEKTRONIX graphics terminal and its accompanying software library.

Another time, I wrote a program which played chess. I am not a master mathematician or even a chess master, but I thought that the task would be fun and challenging. I wrote graphics subroutines to draw all of the chess pieces. I designed my idea of an intense, analytical chess algorithm which would provide opposition to the person who wanted to play the game. My algorithm was not as good as what you would find in a commercial chess program. It also was not that fast. But it was logical, and it was fun to design and develop! Each time the program had to make a move, my algorithm would look at every possible move on the board. It would determine which move was best by counting the number of spaces which could be controlled by the computer's side both before and after the move. The program would then take the move which seemed to provide the greatest and most immediate control.

Of course, I understood that my algorithm was not truly good because it did not try to do any analysis on future contingencies. In other words, my program did not look four or five moves ahead to try to set up or implement any kind of special strategy. It simply tried to grab the greatest amount of control at the time of the current move. I added an additional feature which made the program even more cumbersome, yet the intent was to really make it smarter and better. Each time the player made a move, my algorithm would record the exact board conditions and the resulting move. Then, whenever the algorithm encountered that same situation again, most likely in another game, it would make the recorded move. The idea behind this feature was that the algorithm, over time, would gradually rise to the competence level of its opponents.

Fortunately, my chess game did not remain in operation for very long. Others in the office learned of what I had done, and soon, everyone wanted a copy. It was not that my chess program was so great. It was more that it gave all of us something to do during slack moments while we were waiting for our output. In our computer environment, a person might have to wait as much as a half-hour or more just to compile a program, depending on whether or not the system was busy or backed up. My program gave everyone something challenging to do during those moments. Besides that, a pretty good chess player could actually win against my system, so that made it even more appealing! However, as things like that often go, eventually the wrong person found out what was going on, and we all had to stop. But it was fun while it lasted, and my co-workers were learning that I was a production-oriented individual, even if not all of my productions were work-related.

In the short time that my chess program was in operation, however, one of my friends and co-workers discovered a very interesting anomaly. My algorithm, in desperately trying to find the best move, once used my friend's pawn to take my friend's queen. In chess lingo, my algorithm, which was playing black, had used a white pawn to take the white queen. Of course, that was not a valid move, but all of us got a good laugh at the ingenuity of my algorithm. I had not intentionally taught my program to cheat, but I suppose that by that time it had developed a mind of its own.

Another time, I wrote an accounting or bookkeeping program so that I could keep all of my personal financial data. I did not have a home computer, but I found that the one at work would do just fine. Not only that, but my efforts in that endeavor proved to not even be a waste of time! Every accounting program that I have ever developed, and I have done a few, have been based on that very first system which I had designed and developed at the Navy Yard. In 1996, when I finally got my first PC, I examined the Quicken program that had been included in the PC's software package, and I was very delighted to see that Quicken had used some techniques which were very similar to mine. Now, I use the Quicken system, first, because it really is better than what I had done, but also because none of my accounting programs were ever written for a PC. Until my PC purchase, though, I had always used one of my own accounting systems and done quite well with it.

With all of the extra program writing that I did, one might wonder how I ever found time to do my work. That, too, is an interesting story! I indicated above that we would sometimes have to wait a half-hour or more for our computer outputs because of our often heavy system activity. Sometimes, we would have to wait several hours. But I had found a way to get around that, and I had smartly kept it to myself. In the Honeywell computing system, we wrote programs and compiled them in a Time-Sharing System (TSS) environment. We then executed those programs in a TPAP Processing Environment (TPE). TSS ran at priority of five, and TPE ran at a priority which ranged from forty-one all the way up to the system high of sixty-two. The result was that TPE jobs ran almost instantly, whereas the TSS jobs, which were running at the lower priority, only ran when the system was freed up. After playing around with the system for a few days, I had figured out a way to run my TSS jobs, disguised as TPE jobs, at the higher priorities of the TPE work. Thus, while my co-workers were sitting around, waiting anxiously for their work to be done, sometimes waiting three or four hours for even a single compile, I had found a way to get my stuff in and out of the computer in a matter of moments. That gave me a lot of time to do my work and still be able to experiment on my other extracurricular activities.

RETURN TO TOP

a. Geographical Mathematics (Great Circle and Rhumbline) {1,143 words}

When I had worked at COMOCEANSYSLANT in Norfolk, I had acquired a strong interest in three-dimensional, geographical mathematics. I had been working with the very highly qualified engineers from Bell Laboratories, and I was totally fascinated by some of the algorithms which they had implemented in our system. One algorithm, called the Kalman Filter, was of special interest to me because I had watched our graphics display as the computer system would use historical localization information to determine a best estimated position for the particular target being tracked. I also had an interest in some more general mathematical functions, like how to compute great circle and rhumbline distance, course, and dead-reckoned points. In those days, I did not know the mathematical or even graphical differences between great circle and rhumbline, but I did at least know enough to know that there was a difference!

When I had worked on GADS, I had spent a lot of time trying to derive equations for our three different, map projections - mercator, gnomonic, and polar. I, first of all, could not be satisfied merely using the existing equations because they might be wrong. But secondly, I also did not want to use anything of a mathematical nature unless I fully understood all of the mathematics which were involved. My early exposure to this level of mathematical sophistocation, along with my determination to become an expert in those areas, had been an important key to the establishment of my whole career. I was not satisfied with just making a good living. I was much more interested in becoming a skilled Mathematician and computer applications technician, much like those whom I had known and worked with at Bell Laboratories.

My opinion is that I did eventually become an expert in those areas of interest, but it was not always fast or easy. One problem that I had encountered while still in the Navy involved finding where the tracks of two ships would intersect if they were both traveling different great circle routes. That single problem was almost like a defining point for my career, and it definitely demonstrated my zeal for solving problems. I carried a writeup of it wherever I went, whether around town from day-to-day or across country on a business trip. I would sometimes pull the piece of paper out and just sit and ponder the solution. That problem became my airport and general travel entertainment. It was not that I could not have found the answer elsewhere. If I had wanted to, I could have easily pulled the equation from the computer system at COMOCEANSYSLANT, but I never did because I had always wanted to be able to figure it out for myself. Some people work crossword puzzles or do wordfinds, but I always tried to solve complex, three-dimensional math problems!

At NAVELEX, I was often referred to as their resident math expert. I worked with a lot of other Math Majors, but I was the only one who actually called myself a mathematician. Perhaps part of my attitude was based on sheer determination, which was that of refusing to not be what I so much wanted to be. Another part was probably my genuine, natural love for the power and majesty of math. I am not sure why, but the Lord has taught me to see mathematics in just about everything! Even when I was working on UNITRACK, which was not even a mathematical type of system, I still found ways to be a mathematician.

For one thing, the same Route Generation system, on which I had already worked for a year or so, was embedded in UNITRACK. I was not authorized to make direct changes to RTGEN, but I was able to find other ways to get back into that program and do mathematical things without "offically" being considered in the program. When UNITRACK scripted a route request, for example, it did so by using the latitudes and longitudes for the starting and ending points of the track. Using these latitude and longitude points was not convenient for the typical user, though, because most of us do not normally know the geographical coordinates of the various locations on the earth. Therefore, under the direction of my immediate supervisor, Bob, and with the help of a co-worker, Nancy, I made a simple improvement to the route generation program which made the whole process of generating routes much easier.

Other computer applications at our facility used a port name lookup utility which automatically retrieved latitiude and longitude points for the locations of interest. Thus, with a few fairly simple modifications to our RTGEN program, I was able to sit up a similar port name lookup capability for the extraction of latitudes and longitudes of all registered ports. Then, if a user wanted a route to begin or end in Norfolk, Virginia, he or she could simply enter "Norfolk" for the appropriate location and automatically get "3651N 07618W," instead of having to find it and type it in.

Often, people do things which require great effort and sheer genius, but they are not given much recognition. Other times, people do things which only require minimal effort yet are given high recognition. My simple changes to RTGEN, to use port names instead of latitudes and longitudes, turned out to be an example of the latter. The changes which I had made were not complicated or extensive. They had not even taken that much time, but the users at the Pentagon really loved what had been done. About a year later, on the 27th of April, in 1979, Bob, Nancy, and I were recognized by the Director of Fleet Operations at the Readiness and Navy Command Center Division for our significant achievements within the UNITRACK system. On July 12th of the same year, we also received a Letter of Appreciation from the Commanding Officer of the Navy Regional Data Automation Center (NARDAC) to congratulate us for the same work. These two letters, both of which show that a person can sometimes be given recognition for little or nothing, have been included in Appendix E.

RETURN TO TOP

b. June 1978 - Debbie's Coming Home {230 words}

In April or May 1978, Linda and I got the telephone call for which we had long waited. Debbie called to see if she could come back home, and of course, we were very excited. Linda and I immediately started making plans to go to Florida and bring her home. Debbie's high school graduation would be in June, so we planned to attend that ceremony and then return home.

By 1978, finances were still tight but nothing like they had been during the early and middle seventies. We did not have much money, and we did not have a car which we felt could make the trip. However, one of Linda's relatives, an elderly lady whom we called Aunt Sally, wanted to go with us, and she was willing to let us use her car. So, we agreed and headed south. Everything went off without any significant hitches, and we were able to bring our daughter back home. After so many frustrations within our family, something finally seemed to be going good. However, those good times would not last for very long!

RETURN TO TOP

c. August 1978 - Losing Pam {529 words}

The blessing of June was very dramatic, but it was nothing when compared to the trauma which we had to face in August. I came home from work on a typical Friday. My work was going well, and my career was clearly on the rise. As a family, we had had to deal with Debbie's return, but from my perspective, we were doing that all right and staying pretty level-headed about the whole thing. There had not been any needless emotions, no uncontrolled outbursts, or even any hurtful comments. We were all coping and doing our best to get along. Then, right out of nowhere, Linda and I were hit with another very, very hard problem, and it was one which she and I would have probably most wanted to avoid. I came home from work on that day in August 1978 to learn that Pam had run away from home!

I can honestly say that Pam's running away was probably the hardest thing that I have ever had to work through. Not only was I completely devastated by her being gone, but I was also totally surprised! Neither Linda nor I had even known that she was so upset by anything which was happening in our home. With Debbie's finally coming home, we had begun to think that everything was going to be all right. We had actually begun to let ourselves think that we, as a family, could maybe handle just about anything. But there was absolutely no way that either of us could have avoided the obvious hurt which we were both feeling over Pam's disappearance.

When Pam left, a part of me as a parent died. Fortunately, that same part in Linda did not die! She continued to cope with that problem as well as with all the other future problems that would come our way. It has been almost twenty years since that awful weekend in August, but I can still remember the terrible emptiness which we both had of not knowing the whereabouts of our child. With Pam, I had thought that she was young enough when Linda and I were married that she would not be bothered by the stepparenting syndrome. I had also thought that our relationship had been pretty good. But apparently, I was not correct! As it turned out, Pam had left our home on that day in 1978 and hitchhiked to Florida to be with her "real" dad. Linda and I did not know where she was or anything about her safety until the following Sunday evening when she called from her dad's house. We were very hurt by the event of her leaving, but we were also very relieved that she was all right!

RETURN TO TOP

d. September 1978 - Learning About Our First Grandchild (Michael Scott) {107 words}

Our family had left Marumsco Baptist Church in early 1977. By the middle of 1978, we were firmly in place at Bethel Free Will Baptist Church, where we also had a bus route. I can still remember coming home that Monday night, in September 1978, from church visitation to find both Linda and Debbie on the upstairs couch crying. I did not know what had happened, but I could see that Linda was trying to comfort Debbie. So when I inquired, Linda smiled slightly and told me that we were going to have our first grandchild.

RETURN TO TOP

e. April 1979 - Designing And Developing Positional Analysis Graphics {1,460 words}

Back in late 1977 or early 1978, NAVELEX had started redesigning the massive NWSS (Navy WorldWide Military Command and Control System (WWMCCS) Subsystem) database, and I was closely involved with that project. For this special work, a significant part of our office had been sent to special training at the Honeywell facility in McLean where we had to learn how to work with a special integrated database management system. The UNITRACK system, for which I had been responsible, was one of the two larger systems that our office maintained. The other system, which was called NCAPS, had to do with the tracking of Naval and commercial cargo ships.

After the training, I returned to the Navy Yard and began making the UNITRACK code changes which would be necessary for my part of the database redesign. That went fairly quickly, so then I started writing the code that would actually read from the old database and rewrite the information to the new database in the new format. That part also went very quickly, so I was easily done by early 1979! Unfortunately, the rest of the office had not enjoyed the same measure of success. As I was getting wrapped up with my UNITRACK work, we had an office-wide meeting to discuss a possible "new" delivery date. Because the NCAPS conversion had not gone very well, the people in that group were saying that they needed more time.

At the meeting, each group reported their status. When I indicated that I was done and that everything had checked out, I was temporarily assigned to one of the other groups to provide assistance. I was given another assignment for that team, but I completed that new work very quickly, too. Thus, in April 1979, while the rest of the office was still trying to get their part of this major system conversion done, I found myself with a few months on my hands. I did not want to write another chess program, and I did not need to write another financial program. Therefore, I got the idea of trying to write a sort of super-sophistocated computer graphics, DOD-type system.

I had worked on several systems at the Navy Yard, and I thought that it would be neat to develop a slick, mapping system which would be able to interface with all of those other systems. I also thought it would be neat to develop a graphics system which could be run from a graphics terminal without requiring the aid of a nearby alphanumeric display terminal. I wanted to write a computer program which would be useful in our DOD environment, but more than that, I wanted to develop a system, a "my" system if you will, which would be commensurate with my abilities as a Mathematician and a Computer Graphics expert. In a way, I suppose that my objectives were not unlike those of someone who is seeking to leave their mark on a particular industry.

The first thing that I did was resurrect some of the rewrite work which I had done on GADS. I was especially interested in drawing fast maps, and I thought that with a little effort I could at least maximize what our Honeywell computer system would do. From looking at my earlier work and especially the equations, I noticed that some of the same values were being computed every time that a single geographical point was being converted to a graphics terminal display unit. I immediately grouped all of those "constant" calculations into a single program so that they would be executed only once during the initial map drawing process and thereby eliminate a lot of redundant processing. I knew that my earlier equations were acceptable for what I was wanting to do, so in a very real sense, my work was focused more on computer efficiency than on correct mathematics. As a result, I finished that first part of "my" personal system in only a couple of weeks. After that, I looked around the office and saw that most of my co-workers were still struggling with their conversion work. So, I moved on to the next step of "my" personal system.

My system, to be effective, had to be usable from a standalone graphics terminal. For years, our office had always built graphics transaction requests at an alphanumeric terminal and then had those transactions passed electronically to the graphics terminal. For "my" system, however, such an archaic implementation was not acceptable! I wanted to be able to use a function key orientation. Instead of building graphics transactions at a separate terminal, I wanted the users of "my" system to be able to press a function key at the graphics terminal and immediately get the results. However, satisfying my ambitious desire for function keys would require some new technology, and since it was new, that meant that I would have to develop it myself.

Developing the necessary routines for using function keys was fun, challenging, and interesting. It took me about a month, but when I was done, I could sit at the graphics terminal and enter all of the needed information for drawing maps. I had succeeded in eliminating the aggravating alphanumeric terminal, and that had never been done before! I was thrilled! After that, I again glanced around the office, and my co-workers were "still" working on their conversion stuff. So, I continued working on "my" system. I added function key links to the Route Generation system on which I had earlier worked. I also added a function link which would query our massive UNITRACK database and display historical tracking information. Neither of those geographical links had ever been established before by any system in our office, but I did not want to spare any level of effort to make "my" system a true mark of achievement.

When I finally finished, after about three months of very intense work, I wanted to give my program a truly special name, but I was not very good at that kind of thing. After giving it some thought, I finally decided on "Positional Analysis" and simply called it "PA." I then announced to the office that I wanted to present a new system which I had developed. I set a time and invited all who were interested to come. Since all of us worked in a wide-open terminal room, many of my co-workers had watched as I had been developing PA. Therefore, I had a very large turnout, probably about fifty to sixty of the seventy-five people in our office. My presentation went exceptionally well, and the leadership unanimously agreed to include what I had done with the upcoming worldwide release of the office's database conversion project. Their only objection was with the name which I had chosen. So, at their insistence, I changed the name to "PAT", for Positional Analysis TPAP. A few years later, it was renamed again, to "PAG", for Positional Analysis Graphics.

With the development of PAG, I had accomplished my objectives, and with my having done so much in such a short period of time, I had also turned some heads. My very close friend, John, who was assigned to test PAG and certify it for release, found very few problems. By the time that the office had finally gotten done with all their work for the conversion project, PAG was also well past done. In April of that year, I had just been given a special commendation for my earlier work on UNITRACK. On September 11, 1981, I would again be recognized, on that second occasion for my special work on PAG. This latter letter of recognition is included in Appendix F. PAG received very good acceptance in the international NWSS community. As of November 1989, which was when I finally broke ties with NAVELEX for good, PAG was still being used worldwide. In retrospect, I would have to say that developing PAG has been towards the top of my list of favorite professional acheivements. I had great fun doing it, and a fair amount of good has come from it.

RETURN TO TOP

f. June 1979 - Best Estimated Position (BEPOS) {702 words}

As I was wrapping up and putting my final touches on PAG, I got another idea about what ought to be included. I remembered back a few years earlier to my days at COMOCEANSYSLANT and thought that a good localization algorithm would be nice to have. In that Navy system in Norfolk, Bell Laboratories had used a Kalman Filter mathematical approach to process multiple ship fixes and provide an estimate of the ship's position at a given time. A fix was information about the ship's location, usually given in latitude and longitude, and it also included an eighty-six percent confidence interval ellipse given for a specific time. In our NWSS database, we processed this same kind of location data, too. So we were very much interested in having an algorithm which could compute an estimate of a ship's position at any given time. In June 1979, however, we did not have such an algorithm!

In trying to solve this new mathematical problem, I remembered back to the least squares analysis which I had done at the Newport News Shipyard. I felt that I could develop a reasonably good localization algorithm by using our "fix" information and the same kind of least squares computational methods that had been used before. In so doing, my objective was to establish a mathematical relationship among all the variables, one where the ship's latitude would be evaluated as a function of the other three variables - the ship's longitude, the associated time of the fix, and the confidence interval of the fix.

In thinking about the use of dependent and independent variables, I felt that the ship's longitude, the time of the fix, and the confidence ellipse information of the fix could all be treated as independent variables. With the exception of longitude, which I was already estimating in a separate least squares computation, I did not think that any of the three variables was dependent upon the value of any other variables. This, of course, is a critical necessity for assuming independence, so I was able to use each of the three in that capacity. Next, I thought that the ship's latitude, which I was treating as the dependent variable, would show a strong correlation to the three. If this assumption were correct, then it would mean that the estimated latitude could be predicted from the three respective values. My algorithm, which I called Best Estimated Position (BEPOS) was completed in June, the same month in which I had started it. It was added to PAG and also made a part of the offical delivery to the Fleet.

John was my friend as well as colleague, and he and I discussed and debated my idea for this BEPOS algorithm in great detail. He, as a tester, acknowledged that PAG was a computer system success, but he was somewhat bothered by some of the answers which were being generated by my BEPOS algorithm. In retrospect, I am not completely convinced that my algorithm was much more than just a pretty good mathematical predicter based on "time." But on paper and in graphical displays, the answers looked pretty good! Despite some reservations which both John and I had at the time, BEPOS was considered by most everyone to be a mathematical success. I am not sure that it was really that good. However, John and I had a lot of fun arguing over various aspects of it, and we shared many Chinese lunches discussing the merits of BEPOS. As creator of the algorithm, I will always defend my work to the hilt. But to be perfectly honest, I am not totally convinced that my arguments then or now are really sound. For the benefit of anyone who might be interested, I have included the mathematics of BEPOS in Appendix G.

RETURN TO TOP

Chapter 8. December 1979 - Getting A Special Assignment

Back To The Table Of Contents

Back To TLEE's Home Page

RETURN TO TOP

Send email to: tlee6040@aol.com 1