Re: hardcode.pgm anomaly--methodology

["Patricia M. Godfrey" priscamg@xxxxxxxx]

Harry Binswanger wrote:
> Yes, but why would that be a problem (given your 2.1.3.1 . . . numbering
> system)? I probably just don't appreciate the problem.
Because it isn't enough to increment and CI a given set of
counters (C3, say). You have to watch for and trap any change of
C2, because that will automatically change the value of C3. And
of C1, because that automatically changed the value of C2.
Here's what a properly constructed set of decimal counters would
look like:
C1	1
C2	1.1
C2	1.2
C1	2
C2	2.1
You see? Every time the previous-higher-level counter changes,
the first digit of the counter in question changes. Every time a
new counter of that level is inserted, the digit after the period
changes. And so on.
What Wally was saying yesterday about the buffers in a wp program
 seems relevant: you have to keep three or four counters in
sync, incrementing each at different moments, to keep track of
autocounters.
But a spanner in my suggested method of yesterday is that
high-order ASCII/Speedos chars aren't enclosed in ≪≫. Could one
make a substitution table in one's hc.prn file that simply
repeated them all? For example:

[264]=[264]
using the real Speedos chars?
> Gosh, it seems simple to do the kind of program I'm suggesting. But what
> about using Carl's HARDCODE.PGM that someone mentioned having?
Carl's program doesn't make allowance for multilevel counters; it
only works on the simple 1., 2., 3., type. I suppose I'm the only
one who uses multilevel counters, but I love them and use them a lot.
Harry, read pp. 4-92-96, esp. the charts on 4-94 to 95. for a
clearer explanation of what's involved.

--
Patricia M. Godfrey
priscamg@xxxxxxxx