We know that the Collatz predecessor tree is an infinite tree. We know that the abstract predecessor tree contains an infinite number of l.d.a.s., and that each l.d.a. has an infinite number of instantiations. Feinstein has offered a proof that the infinite nature of these structures implies that the Collatz conjecture is unprovable. I argue elsewhere in these pages that the proper metric for infinity in discussion of the Collatz conjecture is density, i.e. the number of integers appearing in some set within its defined range divided by the capacity of that range were it completely filled. The summation of the density contributions of all the sets representing all the elements of all the instantiations of all the l.d.a.s in the abstract tree is 1. Since we are necessarily limited by the finite practicalities, we can surely say that the limit of the sum of all the densities approaches 1 as we include more and more larger and larger l.d.a.s in the abstract tree. While perhaps not a proof in itself, this is certainly a property required if the conjecture is true.

So some feeling needs to be developed about those very large l.d.a.s in the lower reaches of the abstract tree. What are they like? What order of magnitude are we talking about? Can we visualize the definition of an l.d.a. (or, by extension, some sort of elaboration of l.d.a.s, say sequence vectors) which provides a clear cut implication of an asymptotic approach toinfinity? Can we get a concrete picture of such a thing? We may not answer these questions, but it makes a very nice playground.

By virtue of its capability of producing any/all predecessor paths in the Collatz tree, nbigpath indicates that "custom" or "designer" paths should easily be generated. By specifying a particular path to be developed, the problems of dealing with the whole Collatz predecessor tree (an infinite object) are avoided by focusing entirely on any one particular trajectory at a time.

Makepath has an error or a cute device in it (depending on your viewpoint) which lets it build a path from some root integer through a series of (nominal, but usually strictly incorrect) Collatz predecessor calculations to follow (or create) a defined sequence of Collatz steps.

On the one hand, this is an impossible task. A path which follows a
prescribed arbitrary sequence of steps started at an arbitrary integer
high in the predecessor tree and working outwards through predecessors
cannot succeed. Evidence for this is seen in the sample of output
from **nbigpath** where it is quickly evident that only
every other digit appears in the available branches from any branch
point. When a path reaches a leaf node, there can be no further
predecessors, and for non-leaf nodes, the next step is fully specified
by its value mod 3, resulting in the existence of only one, not two, next
steps. Thus, only half (or 1/2^nth) of paths can exist.

On the other hand, **makepath** performs something very like that impossible
trick. It produces a large integer which, used as departure value for a Collatz
trajectory does produce the specified sequence of steps. The
value it arrives at after the requested trajectory is still a large integer
which will often take a large number of Collatz steps to reach 1.
The error (or cute device) derives from the fact that **makepath** takes no
pains to suppress a further step when a leaf node is encountered.
**Makepath** is also quite indifferent about the value of *oldcoeff* which is
employed in the calculation of the next stepsize, in no way insisting
that *oldcoeff* has a value appropriate to previous history or to the next
step. The program does enter the code fragment appropriate to the
requested step (reduced to either 1 (s-step) or 2 (b-step) at the key
point in the program), but it determines the size of the step to take by including
either one or two times the *oldcoeff* to achieve the appropriate value
mod 3.

The initial values of *d* and *c* of the *dn+c*
notation for the root of the subtree from which a path is to be found
are accepted as the first two parameters. The makepath program
also accepts a pattern given as a sequence vector and the number of
repetitions of that pattern for it to trace out. The program
proceeds with development of the consequent formulas (i.e. residue sets)
by the methods of the downward portion
of
l.d.a. formula development in the abstract tree. The last
integer value output gives an *n* value whose Collatz trajectory
will trace (now in the upward direction in
the predecessor tree) the entire requested l.d.a. path
(whose length is reps*length(pattern)) followed by whatever
additional steps are required to get to the root node (1) from
there. Characteristically, the requested path will represent
only a relatively small first portion of the path **makepath**
created, followed by a relatively long path to the root.

> makepath := proc(dstart,cstart,pattern,reps) local > alphabet,coeff,oldcoeff,const,i,j,currstep; > alphabet:=`123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz`; > fopen(`pathmade.lst`, WRITE,TEXT); > fopen(`madeskip.lst`,APPEND,TEXT); #instrumented > coeff := dstart; > const := cstart; > # oldcoeff := coeff/3; #original stmt. pos'n > for i from 1 to reps do; > for j from 1 to length(pattern) do; > currstep := SearchText(substring(pattern,j..j),alphabet); > while currstep>2 do; > coeff := 4* coeff; > const := 4* const; > currstep := currstep - 2; > end do; > oldcoeff := coeff/3; #corrected stmt. pos'n > sdid :=``; #instrumented > if const mod 3 = 0 then #instrumented > fprintf(`madeskip.lst`,`%20d %20d %20d %3d %3d`,#instrumented > coeff,const,oldcoeff,i,j); #instrumented > sdid := `??`; #instrumented > end if; #instrumented > #check for source of s-step first > if currstep=1 then > #look at children of const (i.e. c-value), itself > if const mod 3 = 2 then > show := `s0`; #instrumented > coeff := 2*coeff; const := 2/3*const - 1/3; > # and then its 2nd and 3rd opportunities > elif (const + oldcoeff) mod 3 = 2 then > show := `s1`; #instrumented > coeff := 2*coeff; const := 2/3*const + 2/3*oldcoeff - 1/3; > elif (const + 2*oldcoeff) mod 3 = 2 then > show := `s2`; #instrumented > coeff := 2*coeff; const := 2/3*const + 4/3*oldcoeff - 1/3; > end if; > #look for source of b-step now > elif currstep=2 then > # all 3 opportunities, again > if const mod 3 = 1 then > show := `b0`; #instrumented > coeff := 4*coeff; const := 4/3*const - 1/3; > elif (const + oldcoeff) mod 3 = 1 then > show := `b1`; #instrumented > coeff := 4*coeff; const := 4/3*const + 4/3*oldcoeff - 1/3; > elif (const + 2*oldcoeff) mod 3 = 1 then > show := `b2`; #instrumented > coeff := 4*coeff; const := 4/3*const + 8/3*oldcoeff - 1/3; > end if; > end if; > if sdid<>`` then #instrumented > fprintf(`madeskip.lst`,` %2s %20d\n`,show,const);#instrumented > end if; #instrumented > fprintf(`pathmade.lst`,`at %2d,%2d %s %80d \n`,i,j, > convert(ifactor(coeff),string),const); > end do; > end do; > fclose(`pathmade.lst`); > fclose(`madeskip.lst`); #instrumented > end proc;

The above rendition of the source code for **makepath** was
consciously chosen to make it evident that the program reached its
current state after some false steps. Serious readers wishing to
reproduce results mentioned here, or to pursue these threads to
greater lengths, may need to explore a bit to encounter the exact
program variation which exhibits a particular behavior.

The use of (24,5) as the first two arguments to
**makepath** seems generally useful. This parameter pair
effectively starts at 5 with 8 as *coeff* due to the early *oldcoeff :=
coeff/3;* statement. (The use of (8,5) results in
abnormal termination because 8/3 is not an integer.) One special
case uses (3,1) for the first 2 arguments.
This (d,c) pair serves when the requested path is one of the
output lines from **nbigpath** which produces paths rooted at 1.

I'll make a brief diversion here to illustrate both the proper
behavior from the root and the impropieties rapidly encountered.
**Nbigpath**'s output includes a line giving the integer 153547 from
`43211422142132242124421`.

Running npathtrk with n=153547 results in `43211422142132242124421`.

Running makepath(3,1,`43211422142132242124421`,1) gives the
correct integer sequence ending with 153547. Thus, running
**npathtrk** against that integer does indeed reproduce the path to
it discovered by **nbigpath**, validating both programs in a
simple case. But the coefficients *d* produced are extremely
large, but harmlessly so, in that first and only rep.
No output to *madeskip.lst* occurred in this run.

However, asking for more reps gives extremely bloated integers
in all larger reps. Notably, the instrumentation with output
to *madeskip.lst* produced a large file indicating frequent encounters of
leaf nodes, including all four types of leaf nodes, in the second and subsequent reps.
Nevertheless, the pattern of the path is faithfully reproduced.
So even in a case where rational behavior might be most expected,
unexpected things arise. The following is the path reported by **npathtrk**
after editing to divide the path string into chunks the size of the pattern.

root at 1<--- 2153 43211422142132242124421 43211422142132242124421 43211422142132242124421 43211422142132242124421 43211422142132242124421 <-- start at large intgeger produced by makepath

Despite the small number of those few rational guidelines for choice of its first 2 parameters, the program is remarkably flexible, operating successfully for current purposes from many (24*2^i,5) or even (24*2^i,m) (m large odd integer) values for the first two arguments. The results of runs which might seem closely related don't always result in identical pathways.

It quickly proved necessary to have a program useful to
assess the output from **makepath**. Recall that even though
**makepath** produces many lines of output, it is only the final
large integer which is of interest, as it is that integer which is
to be run through the Collatz iteration to observe the details of the
trajectory. Although leaving the details of **npathtrk** for
the next page of this site, we will refer to
some aspects of its output in the following because **makepath**'s
output is really only understandable through **npathtrk**.

Specifically, the use of **npathtrk** allows rapid production of
graphs representing paths of interest whose locations in the Collatz
tree have been produced by makepath.

The earliest application
of **makepath** was to explore l.d.a.s (in which only 1 or 2
divisions by 2 are admitted). In the following two paragraphs the
s- and b- step notations are used. Once the program was altered to
handle "sequence vectors" instead of only l.d.a.s., the steps
would be denoted as 1 or 2. Two such examples (using the (24,5)
arguments) are recorded here, that for a path segment
consisting solely of s-steps,
and that for a path segment consisting solely of
b-steps.

These plots may serve to clarify the individual steps in graphs where
s- and b-steps are intermixed. Note that the vertical lines in the
s-step case extend from a line to a line immediately below it,
while in the b-stepcase, the vertical line crosses two
intervals. This pictorially represents the origin of the s- and
b-nomenclature to indicate **s**mall and **b**ig steps. A
real example (i.e. one with
intermixed s- and b-steps) is also provided.

The program was quickly upgraded to allow for trajectories in which
other than s- and/or b- steps occur. This was accomplished by
using an "extended hexadecimal" notation to represent the number of
divisions by 2 between the successive odd integers in the
trajectory. (See the program above for the detailed
alphabet.) Since the extended alphabet includes the letters "b"
and "s" to represent the digits 35 and 52, respectively, in
paths containing those numbers of consecutive divisions by 2, it
was necessary to use "1" and "2" to represent what we have
previously called s- and b- steps. It proved easy to develop
uncomplicated graphs extending over a huge number of orders of magnitude
using these notations, e.g. one
produced from a long series of '6s6' path segments. This is
but one of several examples where the first (in predecessor
order) instance of the path requested is produced with an error in
it. Although many instances of this error were repaired by moving
the *oldcoeff := coeff/3;* statement down 9 lines from its original
location (see the listing above), not all such errors were
corrected.

**Makepath** has the remarkable capability of finding a correct
path when the path it is requested to generate cannot be achieved
following the Collatz predecessor rules. It accomplishes this by
making the usual increments (in the statements #B through
#C) in the d value of the {c[d]} expression which it carries along
to calculate the next predecessor from, whether or not the *
const * value (in statement #A) indicates the encounter
of a leaf node. This creation of a larger playground at each such
encounter apparently allows correct selection of a suitable
predecessor. Of course, this unwarranted increment in the
*d* values causes the magnitude of the values in the reported path
to be quite large, often many fold larger than the smallest
instance of the requested path segment occurs at. [If the
smallest
possible example of a Collatz path with any given specified sequence
vector is desired, the method used to determine
the descent to 27 is recommended.]

The statements marked as " #instrumented" were inserted to trace the
instances in which this process was applied by **makepath**.
This instrumentation may help resolve any further misbehavior,
some of which are thought to remain even in the current version of the
code.

Several examples of much more complicated paths intended to reach deeply into larger magnitudes of numbers produced graphs of an artistic cast, but of little use for development of insight into the Collatz conjecture.

As to the contribution to the total density of the predecessor tree
contributed by the examples, simply bear in mind that each odd
point reached contributes something a little less than 2/2^*y*,
where *y* is the coordinate on the y-axis of each **npathtrk**
plot (because the *d* value of *c[d]* is always greater
than the plotted *c* value). Thus those density contributions
are very small indeed.

My Collatz HomePage Index of Terms Used