On Mon, 2003-10-27 at 03:10, Majorinc, Kazimir wrote:
>
> 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.
Well, I wasn't thinking of just writing them out, but having other
uses for the original values. However, you raise some interesting
points. From the code fragment I was assuming you were working in
3-space (since local_min seems to want that) and that this was
a central tenet of the program. But from your comments, I take
it you're really working in 1-space - hence the desire to
name the variables in X1,X2,X3,...Xn (name continuity). The fact
that local_min() happens to work on triples is an aside.
> (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.
I only used that many variables because I wanted to track where
final results were computed from, since that was something that
caused me problems when examining the original code.
> 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
Hmmm, now that it's clear you're operating in 1-space, there's another
approach:
local_min(X, 1,2,3)
local_min(X, 1,3,4)
...
Which satisfies the concerns 1 and 2, above (in fact, it's
the ultimate in name-continuity!); works in Unicon as it
exists now (requires no changes to the language); and is 'close'
to the Pascal version. It doesn't offer the advantage of protecting
old values, but that (as you note) can be handled other ways and
is apparently of lower priority than other concerns. (I dropped
the passing of function f, since that flexibility also doesn't seem
to be important here.)
This also has advantages not offered by the original 'Pascal' approach:
(1) If you want all permutations of N choose 3 variables, this is
easy to do since it's just a matter of playing with subscripts -
no need to hard-code in N choose 3 distinct calls to local_min().
(2) Since the 1-space variables are accessible through subscripts,
there are lots of other actions that can be taken more easily
than with N scalar variables. For example, to write all N
out:
every writes(" ",!X)
or force all negative values to some constant value:
mapNegative(X,-1)
Both of these, and countless other actions, are harder if
using scalar variables, since the problem is really manipulating
values in a 1-space.
Now, I'll readily admit that the above approach is quite similar
to the Pascal approach in that it's using the implicit reference
available through a structure. I don't see that as a bad thing.
> 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.
Of course. I wasn't trying to attack the procedural approach, just
point out that the approach of using separate scalar variables isn't
the only approach. And I agree that sometimes change 'in place'
can be handy. I'm just arguing that the number of places where
an explicit reference is 'vital' may be smaller than it appears
when looking at isolated examples.
And I'll concede that there are likely cases where it *is*
useful - I'm just not convinced that it's worth the effort
required to provide it in a safe, consistent manner, when
there are alternatives. (A functional purist would object to
the fact that Icon/Unicon structures are represented by references,
I don't.)
> > [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) ...
See - another reason to use a (subscriptable) structure - you can
generate the selections algorithmically and avoid programmer
error! :)
--
Steve Wampler -- [EMAIL PROTECTED]
Quantum materiae materietur marmota monax si marmota
monax materiam possit materiari?
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
