Browse Prior Art Database

OPERATING THE LINEAR PROGRAMMING CODES

IP.com Disclosure Number: IPCOM000128844D
Original Publication Date: 1956-Aug-01
Included in the Prior Art Database: 2005-Sep-19
Document File: 10 page(s) / 40K

Publishing Venue

Software Patent Institute

Related People

Cutler, Leola: AUTHOR [+3]

Abstract

A general code for solving linear programming problems needs a standardized operating procedure. The current method of operation has evolved from the experience of running many problems. The checks used and the types of error that can be expected are explained. In addition, the way to resume computing after machine or problem error has occurred is discussed. It is shown that with adequate written instructions the problems can be run on the high-speed computer by any machine operator. Major decisions are left to the problem formulator.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 9% of the total text.

Page 1 of 10

THIS DOCUMENT IS AN APPROXIMATE REPRESENTATION OF THE ORIGINAL.

OPERATING THE LINEAR PROGRAMMING CODES

by

Leola Cutler
P-909
August 1, 1956

The RAND Corporation 1700 MAIN sr. . SANTA MONICA CALIFORNIA

SUMMARY

A general code for solving linear programming problems needs a standardized operating procedure. The current method of operation has evolved from the experience of running many problems. The checks used and the types of error that can be expected are explained. In addition, the way to resume computing after machine or problem error has occurred is discussed. It is shown that with adequate written instructions the problems can be run on the high-speed computer by any machine operator. Major decisions are left to the problem formulator. The method of linear programming finds the optimal solution to a problem. This idea of optimality carries over to the use of machine codes available. Perhaps it is a sign of laziness rather than efficiency, but there is a basic desire to run a job with a minimum of effort on the part of the operator. In cases where the programmer has acted as operator this interest has greatly increased.

In an ideal situation, the inputs to a problem are keypunched, converted and assembled by the data routine, then attached to the simplex program deck. All one has to do is put the cards into the reader, push a button and wait a few seconds for the results to come forth. Such a simple operation is the way the newspapers and motion picture industry have described the process.

Occasionally, things are as smooth as this. Fiction has forgotten to mention the element of error by both humans and machine. There is also a time element to be considered. Our current computers can do remarkable things such as performing arithmetic in microseconds, but time on a machine can be precious so that the amount allotted may not be sufficient to solve the problem. This leads to decisions on how to stop a run and how to resume computation from the stopping point. The current code is designed to record all pertinent information on cards and tape so that a job may be resumed at a future period. Experience has always been a great teacher. It has been true in the development of the general code for the simplex method. When dealing with a large system, a cycle of improvement evolves. First a code is written in what is believed to be an efficient manner, but no programmer or group of programmers can be clairvoyant. After the code has been in operation for a while some flaws become apparent. The internal machine operation is fine, accuracy is maintained and components are working well. However, the human partner to the machine finds some things that should be improved. Perhaps card handling becomes inconvenient, or if there is a stop in the program, it may be hard to figure what it is. It may take too long to decide what to do next or how to recover after a failure. It can now be seen that if the code were set a little differently, the act...