Re: collatz proof algorithm reveals e

ronaldo wrote:
> You make a mistake in line 1. z(1) = 3.

Yes, I made the table by hand and screwed it up.
Nevertheless, it did not affect the totals and
does not alter the conclusion that sum(z)=count(p).

> I'll show you the full proof dump for n = 10.
> Maybe this will help you understand.
> To create such a dump do (prove c3 10 50 'prove)
> The proof starts with n = 0 and finds the cycles for n=0

That explains why I got 27338 instead of 27339.
0 is often excluded from Collatz because to include
it makes the conjecture false, as does using negative
numbers. I won't quibble about that. I only bring it
up to tie up the loose ends.

> and n=1,
> it was designed to handle more than one function and not
> for collatz exclusively.

Then you risk reaching conclusions that are not
applicable to Collatz and it would be wrong to
claim they are.

>
> ((0 0) (0 0 0 0 0 0 0) 0 () 0 () 0 ())
> ((1 4) (1 0 1 0 0 0 0) 1 (0) 0 () 0 ())
> ((1 2) (2 0 1 0 0 0 1) 1 (0) 0 () 1 (4))
> ((1 1) (3 0 1 0 0 0 2) 1 (0) 0 () 2 (2 4))
> ((2 1) (4 0 2 0 0 0 2) 2 (0 1) 2 (2 4) 0 ())
> ((3 10) (5 1 2 0 0 0 2) 2 (0 1) 1 (4) 0 ())
> ((3 5) (6 1 2 0 0 0 3) 2 (0 1) 1 (4) 1 (10))
> ((3 16) (7 1 2 0 0 0 4) 2 (0 1) 1 (4) 2 (5 10))
> ((3 8) (8 1 2 0 0 0 5) 2 (0 1) 1 (4) 3 (5 10 16))
> ((3 4) (9 1 2 0 0 0 6) 2 (0 1) 1 (4) 4 (5 8 10 16))
> ((4 2) (10 1 2 0 0 1 6) 2 (0 1) 5 (4 5 8 10 16) 0 ())
> ((5 16) (11 2 2 0 0 1 6) 2 (0 1) 4 (5 8 10 16) 0 ())
> ((6 3) (12 3 2 0 0 1 6) 2 (0 1) 3 (8 10 16) 0 ())
> ((7 22) (13 3 2 1 0 1 6) 2 (0 1) 3 (8 10 16) 0 ())
> ((7 11) (14 3 2 1 0 1 7) 2 (0 1) 3 (8 10 16) 1 (22))
> ((7 34) (15 3 2 1 0 1 8) 2 (0 1) 3 (8 10 16) 2 (11 22))
> ((7 17) (16 3 2 1 0 1 9) 2 (0 1) 3 (8 10 16) 3 (11 22 34))
> ((7 52) (17 3 2 1 0 1 10) 2 (0 1) 3 (8 10 16) 4 (11 17 22 34))
> ((7 26) (18 3 2 1 0 1 11) 2 (0 1) 3 (8 10 16) 5 (11 17 22 34 52))
> ((7 13) (19 3 2 1 0 1 12) 2 (0 1) 3 (8 10 16) 6 (11 17 22 26 34 52))
> ((7 40) (20 3 2 1 0 1 13) 2 (0 1) 3 (8 10 16) 7 (11 13 17 22 26 34 52))
> ((7 20) (21 3 2 1 0 1 14) 2 (0 1) 3 (8 10 16) 8 (11 13 17 22 26 34 40
> 52))
> ((7 10) (22 3 2 1 0 1 15) 2 (0 1) 3 (8 10 16) 9 (11 13 17 20 22 26 34
> 40 52))
> ((8 4) (23 3 2 1 0 2 15) 2 (0 1) 12 (8 10 11 13 16 17 20 22 26 34 40
> 52) 0 ())
> ((9 28) (24 4 2 1 0 2 15) 2 (0 1) 11 (10 11 13 16 17 20 22 26 34 40 52)
> 0 ())
> ((9 14) (25 4 2 1 0 2 16) 2 (0 1) 11 (10 11 13 16 17 20 22 26 34 40 52)
> 1 (28))
> ((9 7) (26 4 2 1 0 2 17) 2 (0 1) 11 (10 11 13 16 17 20 22 26 34 40 52)
> 2 (14 28))
> ((10 5) (27 4 2 2 0 2 17) 2 (0 1) 13 (10 11 13 14 16 17 20 22 26 28 34
> 40 52) 0 ())
> ((11 34) (28 5 2 2 0 2 17) 2 (0 1) 12 (11 13 14 16 17 20 22 26 28 34 40
> 52) 0 ())
>
> e.g.
> z(0..10) = 28 is the third number on the last line.
> z(7) = 23 - 13 = 10.
> z(1) = 4 - 1 = 3.
>
> This dump shows tour "flash of insight" is correct. But note that when
> proceeding from n to n+1 the prover is called with arguments
> (among others) n+1 and collatz(n+1). I do this to maintain the loop
> invariants of the algorithm so although this call to collatz may seem
> superfluous I count this as 1 not 0.

But you should not count it as it is not a proof step.
The number of steps needed to prove a number already
proved is 0, period. That is the math underlying your
algorithm and doesn't change no matter what hoops your
program has to jump through to realize it. You started
out saying you didn't want to count redundant proof
steps. But if you count the 0 length proofs as 1,
then you are selectively double counting some of the
proof steps.

For example, you proved 8 when you proved 3 and you
counted 8 -> 4 as a proof step. Now, when n=8 you add
another proof step to the the total even though you have
already counted the step from 8. You have thus proved
8 twice.

So your conclusions are a measure of your algorithm
and not Collatz. This, of course, makes your conclusions
although not wrong, worthless, i.e., of no value to anyone.

It is no wonder that no else has previously discovered this.
The claim that

prooflength(1..n)
lim(n -> oo) ----------------------- = e
n

is simply false.

.

Relevant Pages
Loading