Steve wrote


    p := local_min(f, [x1,   x2,   x3])
    q := local_min(f, local_min(f, [p[1], p[3], x4])
    r := local_min(f, [p[2], q[2], q[3])
    write(q[1], r[1], r[2], r[3])

which, while not as terse as in Pascal, isn't that far off
and offers the advantage of making it easier to trace where
values are coming from!

It was my little trick, I forced definitions of new record/list variables p,q,r ... for variations of four variables x1,x2,x3,x4 - there can be sixty four different - but 3-4 in this program were not enough that you give up. In such approach, instead of one variable x3 you made stream of variables


x3->p[3]->q[2]->p[3] ...

I see two disadvantages over conventional/Pascal approach,

(1) Lack of continuity of names makes such program harder to understand and change. For example, last line, write(q[1],r[1],r[2],r[3]) cannot be understood until one read back through whole program and realize it is (x1,x2,x3,x4). If one want output of sub-results, in Pascal program he needs only to copy and paste write(x1,x2,x3,x4), with your approach he must find where are x1,..,x4 hidden in p,q,... structures now.

(2) There are about 13 values in that Unicon program, while only 4 in Pascal program. If this problem is generalized on x1,...,xn, Unicon program would require something between supraexponentially (n^n) and quadratically more memory (if you optimize, so you use p again when it doesn't carry last value of any of imaginary variables x1,..,xn). Quadratic memory requirements are not only computer memory problem, but programmers memory also.

Only alternative that removes (1,2) I can see now, is to and keep x1,..,x4 updated all the time

p:=local_min([x1,x2,x3]); x1:=p[1];x2:=p[2]; x3:=p[3]
p:=local_min([x1,x3,x4]); x1:=p[1];x3:=p[2]; x4:=p[4] # one can use q,r.. here if he want
......


It can be shorten further with some handy procedure, but again, it is obvious attempt to come close to Pascal solution....

With critical "I see no reason to force that local minimum back into the same variables as x,y,z" you are right on your money. That makes program cleaner. However, it is not limitation of procedural approach: local_min(x0,y0,z0,x,y,z). Sometimes change 'in place' is handy: the most popular example x+:=1 instead x:=x+1.


 [The duplicate 'local_min(x1,x3,x4)' in
Kazimir's example through me for a moment...though I think it's
redundant.]

Ouch. Perhaps I wanted something like (1,2,3), (1,2,4), (1,3,4), (2,3,4) ...



----
Kazimir Majorinc, Zagreb, Croatia

Reply via email to