August 21, 1964
The following is an effort to please ALGOL users, more than to please language designers. It is an answer to the undeniable fact that those, who should like to work extensively with complex numbers will find it hard to use ALGOL 60, and for two reasons: it is hard to express the computing process, and after having done so, it becomes equally hard for the computer. Those who are crying for the inclusion of complex arithmetic will therefore be helped greatly by any reasonable effort in this direction, even if it has some deficiencies and lack of elegance. Those who do not care, being happy with real numbers, should not protest on account of the deficiencies as long as their non-complex programs are processed as efficiently as before.
With the character " Remark. The complex variable will be declared with the single character "
They will be declared by "
They will be declared by "
Its value will be the complex number with the values of
The specification "
When used as a function designator they have the value of the real and imaginary part, respectively, of the value of the actual parameter. Due to the representation we can state for any complex variable z z = com(re(z), im(z)). A formal parameter specified " The more difficult decisions to take are concerned with - What transfer functions to invoke automatically
- The semantics of expression evaluation (control of types of intermediate results)
- Whether the special character
__i__should be introduced and if so, how.
My intention is to see to it that the complexity of all intermediate results is known. The restriction, that all complex expressions should be homogeneously of type complex is too strong, therefore I suggest automatic invoking of the transfer of arithmetic (i.e. integer or real) to complex If "
then the result will be of type complex, and "c The net effect of this rule will be that all non-complex sub-expressions will be evaluated in terms of integer and real arithmetic. A program, not using complex arithmetic at all will proceed at full speed, as desired. The definition of the powering operator will be extended to include the case with complex base and integer exponent. The result will then be of type complex. The unary + and - signs in front of a complex primary will have their usual meaning. I am inclined to restrict the automatic invoking of the transfer function to the cases stated above. For one thing, I feel that automatic invoking of the transfer function from complex to real
the assignment "arv:= re(c)" or "arv:= mod(c)", just as he wishes. The next question to decide is whether we admit an arithmetic actual parameter if the formal one is specified as complex. I think we should, although there are some dangers lurking! We consider two procedures
the difference being, that inside p1 only interest is shown in the right hand value of the formal parameter, whereas in p2 an assignment is made to it(as well). If we do not provide for automaticly invoking the transfer function, the call "p1(com(z,0))" would be OK, the call "p2(com(z,0))" would have to be rejected at some stage or another. The implementation of this rejection runs shortly as follows. At call side the actual parameter is specified in its so-called formal locations. Of these formal locations, one is reserved for the evaluation of the right hand value and one for the left hand If we decide, that the transfer function from arithmetic to complex should be involved automatically, then we can just write p1(x) and p2(x). We can achieve this by two stage definition of the formal locations. On account of the specification " Finally I have come to the conclusion that in a system like this there is no room for My dislike for All this mess is introduced at the moment one tries to include |

Transcription by Ken Dyck.
Last revised on |