Moshe Sniedovich
Department of Mathematics, The University of Melbourne
Parkville, VIC 3010, Australia

The purpose of this letter is to announce the establishment of a new OR/MS oriented society to be known as the International Society for the Prevention of Cruelty to Indices (ISPCI). I shall first explain why I decided to establish this society and then tell you what it will do. I hope that some of you out there will decide to join in. A Membership Application Form is available.

What do we need indices for?
Recall that broadly speaking, indices are supposed to help us select item(s) from a collection. The collection can be an array, say a vector or a matrix; a set, etc. Thus, we write something like

to describe an operation involving, among other things, selection of two items from a collection, in this case a vector called x. This application constitutes a legitimate use of indices because indices are doing here the job they are supposed to do: they facilitate selection of items from a collection. Similarly, in the expression

we use indices to select the first n elements of a vector consisting of k>n elements. Although I think that this expression offers a very clumsy description of what we want to do, I nevertheless regard it a legitimate application of indices. They are used here to select items from a collection, hence do what they are supposed to do.

Crimes and misdemeanours
From all the crimes, transgressions, misdemeanours, insults, and other abuses that I have witnessed over the last thirty odd years in the OR/MS literature and elsewhere, the following represents perhaps the most common offence against indices:

Note that to describe the intended operation under consideration here, there is no need for any selection, hence no need for indices. As all the elements of the collection are processed and the result is independent of the order in which the items of the collection are processed, no selection is necessary. When we describe the intended operation in plain English we say

We do not have to use indices here because in thinking about the intended operation we do not describe it in our mind as

Compute the sum obtained by adding the first element of x, the second element of x, the third element of x, and so on, up to the n-th element of n.

In other words, instead of (3) we should write something like this

Actually, in many applications when such an expression is under consideration, the shape (dimensions) of x is already known. Thus, it would be more appropriate to rewrite this expression as follows:

The interpretation would read something like this:

Compute the sum of all the elements of the object x and store the result in z .

This interpretation is valid regardless of what shape x happens to have: it can be a vector, a matrix, a set, etc.

The situation is deteriorating very rapidly as the objects being indexed become more complex. For instance, in the OR/MS literature, and elsewhere for that matter, we find expressions such as

where x is a three dimensional array of shape (m,n,p).

Future generations of OR/MSer may judge these as mathematical pornography. Be it as it may, there is no excuse for using (6) in cases where x is an n by m by p array. We can use (5) instead.

Who cares?
Obviously I do. I also know a number of other OR/MS people who care. What I would like to do now, though, is tell all of you who do not care, why you should. And as a starter, let us consider the following hypothetical situation.

Suppose that you want to solve a linear programming problem whose coefficient matrix is of the form:

where B, C, and D are some given matrices, stored somewhere on files. Situations like this are very common in LP modelling. For the purpose of this exercise you can assume that the front end to your favourite LP solver knows where to find the matrices B, C, and D.

The question is this: how do you tell the front end of your favourite LP solver to use this particular coefficient matrix when solving the next LP problem ?

Well, to the best of my knowledge, the OR/MS technologies available at present for dealing with this type of modelling tasks rely on cheap labour involving exploitation and torture of indices. I will not attempt to describe in detail this gruesome process except saying that it involves sending these dear old chaps running all over the place carrying elements of B, C, and D. And while the little buggers are doing this, we humans, have to worry about a number of book- keeping operations taking care of the shapes of the three matrices in relation to the shape of matrix A.

"So what?" you may argue. "What's wrong with this? We have been doing this type of things for years and never heard any complaint from these indices fellows".

My reaction to this is to introduce you to an eight letters word, namely

The point is that in less than six years time we shall celebrate the end of the 20th century and it is only natural to reflect on what we do, how we do things and whether or not we still use technologies whose time has passed.

So look around you! Examine how your favourite word processor and spread-sheet use cut and paste technologies to construct objects such as A on the screen and then on paper. Why do not you check how these types of operations are taken care of in packages such as MATHEMATICA and MATLAB, and languages such as APL and J? Maybe when you experiment with the new technologies available for this type of tasks you will discover that doing it the old way is not very exciting after all.

So you see, I have initiated the crusade to protect the defenceless indices not because I have a soft spot in my heart for this cute little things. In fact, I do not like them at all, and whenever possible I use other tools. But I realise that as long as we keep exploiting these poor delicate creatures we shall never experiment with much better and humane technologies for doing things in OR/MS modelling. In short, my crusade to protect indices is in fact a crusade whose goal is to reexamine our OR/MS modelling technologies. As such it has nothing to do with indices, except that modern modelling technologies are much more humane towards these little fellows.

The bottom line is this: if you are frustrated by the manner in which existing OR/MS modelling technologies do things and/or are interested in new exciting mathematical modelling technologies, join ISPCI and help us move towards the 21st Century with a big smile on our face.

What are the alternatives?
It is not easy to answer this question in this forum because we simply cannot possibly examine here all the exciting technologies that are waiting out there for us to be exploited in our OR/MS modelling work.

What I shall do is focus on one important aspect OR/MS modelling and give a very brief indication as to the alternatives available for dealing with this aspect. As you might have guessed, this aspect has to do with the important role that arrays play in OR/MS modelling.

When you examine what is actually taking place in OR/MS modelling in general and LP modelling in particular, you immediately notice that we spent most of our time manipulating arrays. Take for example Linear Programming, OR/MS' flag ship: all we do in LP modelling is manipulate a relatively small number of arrays, typically a couple of vectors and one matrix.

No wonder then that in our classrooms, books, journals, and more recently videos, we tend to discuss LP modelling using a specialised notation that was deliberately invented for manipulating arrays. In addition, we also use a lot of ad-hoc conventions that were introduced over the years and have become an integral part of applied mathematics. In fact, we are so used to these tools of thought that we simply take them for granted. So this is how we typically define LP problems in print:

Note that not even one single index is used in this formulation !!!

How come then, I ask, that no sooner do we begin our LP modelling activities of the type described in (8) on computers, we immediately engage ourselves in gross index- rights violations? Why is it that we take it for granted that when we communicate with computers we are not supposed to use the same concepts that we use in the OR/MS classroom?

The answer is obvious, over the years we have been brainwashed to believe that when we do our LP modelling on computers we cannot use the mathematical concepts that we commonly use when we do our LP modelling on paper, blackboards, sand, match boxes, envelopes, brain-cells, etc.

Note that I highlighted the word "concepts". I have done this to make sure that you observe that I am not using the word notation. For, as all of us know all too well, our conventional mathematical notation cannot be easily used on computers.

By now you probably have guessed what I am going to say next, but I shall say it anyway. There is no reason why we should not use mathematical concepts such as inner products, outer products, matrix products, matrix transpose, scalar functions, etc in our OR/MS modelling just because we do it with the aid of computers. These concepts have been successfully implemented by many computer packages as well as computer programming languages. In fact, I shall go even one step further at the risk of being accused of heresy by some.

In an attempt to deal with practical, modern, modelling issues that arise when modelling is done on computers, a number of new, interesting, exciting, mathematical concepts associated with arrays have been developed and implemented. They have not yet been incorporated in conventional mathematics. Nevertheless, they do offer invaluable tools for OR/MS modelling. I shall mention one simple example, namely nested arrays. These are arrays whose cells can also be arrays. For example, we can have a vector whose first element is a vector, its second element is a matrix, whose third element is a scalar, etc. My experience over the past ten years has been that these type of arrays are extremely useful in OR/MS modelling, especially when modelling is done on computers.

In short, in the case of arrays, there is a lot of things that we can do to simplify the way we use them in OR/MS modelling, especially when this is done on computers. So it is extremely disappointing to see that our leading mathematical modelling languages do not support basic array oriented concepts that all of us use routinely when we do not use computers.

What I propose then is an alternative type of languages for OR/MS modelling, namely languages that are based on all the mathematical concepts that we routinely use in the OR/MS classroom. These languages should also incorporate new concepts that have already proved themselves useful and effective in OR/MS modelling, eg nested arrays.

But this is not enough. It is necessary to ensure that these new languages will be supported by a friendly OR/MS User Interfaces, namely a user friendly environment, where such utilities as word processing, spreadsheet, data base, graphics, problem library, bibliography, and so on, are all incorporated into a integrated system.

I know that this can be done, and I also know that we are far behind schedule if we are to have a system like this ready before the commencement of Olympic Games in Sydney in 2000. So we better do something about it immediately. Instead of bragging about all the nice things that we can do to improve the decision making capabilities of other people, let us practice what we preach first, and build for ourselves, not other people, a respectable OR/MS User Interfaces.

But as I indicated already, we cannot do this while we are engaged on a daily basis with cruelty against indices. The question is then, how can we convince the OR/MS software developers that the time has come to take a fresh look at the way we use computers in OR/MS modelling? On a more personal level, the question is: what can you, the reader, do about this important issue? Naturally, I cannot answer this question on your behalf. I can tell you, though, one of the things that I decided to do about the this matter, namely I can tell you about my decision to establish ISPCI.

About The Society
To ensure that the message gets across, I propose the immediate establishment of an International Society for the Prevention of Cruelty to Indices (ISPCI). Upon joining ISPCI, members are expected to immediately refrain from abusing indices in their OR work and will endeavour to promote the use of mathematical concept in OR modelling on computers. Also, ISPCI will immediately establish a Committee whose task will be to formulate an index-rights abuse index to be used for computing the level of index rights abuse by journals, books, software packages, individuals, organisations, societies and countries all over the world, and beyond. We shall soon also establish a program to help individuals get rid of this bad habit, including an emergency hot line, perhaps even rehabilitation clinics.

We are particularly interested in attracting persons who are actively involved in the design and development of OR/MS software.

Needless to say, the Society will have a journal dedicated to all aspects of mathematical languages, array theory, as well as computing technologies pertaining to the modelling of OR/MS problems on computers. Although it is perhaps a bit too early to mention The 1st International ISPCI Conference , we do want you to know that it is already on the planning board.

And to demonstrate ISPCI's long term commitment to this just cause, let us declare the year 2000 the

Long live the indices!