From: news.dead.person.stones@darjeeling.plus.com   
      
   On 30/01/2026 03:03, wij wrote:   
   > On Fri, 2026-01-30 at 02:20 +0000, Mike Terry wrote:   
   >> On 29/01/2026 21:40, wij wrote:   
   >>> On Thu, 2026-01-29 at 16:50 +0000, Mike Terry wrote:   
   >>>> On 24/01/2026 16:37, wij wrote:   
   >>>>> On Wed, 2025-12-24 at 20:05 +0800, wij wrote:   
   >>>>>   
   >>>>>   
   >>>>> I have just finished the script. Any defect,insufficiency, or typo?   
   >>>>>   
   >>>>> ------------------   
   >>>>> This file is intended a proof of Collatz Conjecture. The contents may be   
   >>>>> updated anytime.   
   >>>>> https://sourceforge.net/projects/cscall/files/MisFiles/Col   
   -proof-en.txt/download   
   >>>>>   
   >>>>> The text is converted by google translate with modest modification from   
   >>>>> https://sourceforge.net/projects/cscall/files/MisFiles/Col   
   -proof-zh.txt/download   
   >>>>> Reader might want to try different translator or different settings.   
   >>>>>   
   >>>>> ----------------------------------------------------------   
   ------------------   
   >>>>> Collatz function ::=   
   >>>>>   
   >>>>>          int cop(int n) {   
   >>>>>            if(n<=1) {   
   >>>>>              if(n<1) {   
   >>>>>                throw Error;   
   >>>>>              }   
   >>>>>              return 1;     // 1 is the iteration endpoint   
   >>>>>            }   
   >>>>>            if(n%2) {   
   >>>>>              return 3*n+1; // Odd number rule   
   >>>>>            } else {   
   >>>>>              return n/2;   // Even number rule   
   >>>>>            }   
   >>>>>          }   
   >>>>>   
   >>>>> Collatz number: If an integer n, n∈N<1,+1>, after the cop iteration   
   will   
   >>>>>        eventually calculate to 1 (i.e., cop(...cop(n))=1), then n   
   is a Collatz   
   >>>>>        number. Otherwise n is not a Collatz number.   
   >>>>>   
   >>>>> Collatz Problem: For each integer n, n∈N<1,+1>, is n a Collatz number?   
   IOW,   
   >>>>>        the question is equivalent to asking whether the following   
   procedure rcop   
   >>>>>        terminates or not.   
   >>>>>   
   >>>>>          void rcop(int n) {   
   >>>>>            for(;n!=1;) {   
   >>>>>              n=cop(n);   
   >>>>>            }   
   >>>>>          }   
   >>>>>   
   >>>>> Prop: cop(n) iteration contains no cycle (except for the '1-4-2-1'   
   cycle, since   
   >>>>>         1 is the termination condition).   
   >>>>   
   >>>> If you could prove just this much, you would become famous, at least   
   amongst mathematicians!   
   >>>>   
   >>>>>      Proof: n can be decomposed into n= a+b. rcop(n) can be rewritten   
   as rcop2(n):   
   >>>>>   
   >>>>>          void rcop2(int n) {   
   >>>>>            int a=n,b=0;   
   >>>>>            for(;a+b!=1;) { // a+b= n in the cop iterative   
   process.   
   >>>>>              if((a%2)!=0) {   
   >>>>>                --a; ++b;  // Adjust a and b so that a   
   remains even and the   
   >>>>>                           // following algorithm   
   can be performed and remains   
   >>>>>                           // equivalent to   
   cop(n) iteration.   
   >>>>>              }   
   >>>>>              if((b%2)!=0) { // Equivalent to (a+b)%2 (because   
   a is even).   
   >>>>>                a= 3*a;   
   >>>>>                b= 3*b+1;    // 3*(a+b)+1= (3*a) +(3*b+1)   
   >>>>>              } else {   
   >>>>>                a= a/2;   
   >>>>>                b= b/2;   
   >>>>>              }   
   >>>>>            }   
   >>>>>          }   
   >>>>>   
   >>>>>          Let nᵢ, aᵢ, bᵢ represent the values n,a, and b in   
   the iteration.   
   >>>>>          Assume that the cop(n) iteration is cyclic. The cycle is   
   a fixed-length   
   >>>>>          sequence, and the process must contain the operations   
   3x+1 and x/2 (and   
   >>>>>          the associated operations --a and ++b, unless n is a 2^x   
   number, but such   
   >>>>>          numbers do not cycle). Let the cyclic sequence of n be:   
   >>>>>            n₁, n₂, n₃, ..., nₓ (n=n₁).   
   >>>>>          Because --a and ++b are continuously interpolated during   
   the cycle, if   
   >>>>   
   >>>> I think "interpolated" is not the right word.  Not sure exactly what is   
   being claimed, but maybe   
   >>>> this doesn't matter - check my next comment...   
   >>>>   
   >>>>>          aᵢ≠0, then bᵢ and nᵢ=aᵢ+bᵢ will increase   
   infinitely, contradicting the   
   >>>>>          assumption that nᵢ is cyclic. Therefore, aᵢ=0 must   
   hold during the cycle,   
   >>>>   
   >>>> Regardless of your reasoning, it is clear (and easily proved) that as the   
   cycle repeats, aᵢ at   
   >>>> the   
   >>>> same point in the cycle must decrease until it becomes zero.  At this   
   point aᵢ remains zero for   
   >>>> all   
   >>>> further i, and no more --a,++b operations occur.  (So there can only be   
   finitely many such ops,   
   >>>> but   
   >>>> I agree aᵢ has to become zero, which seems to be what you want to   
   claim.)   
   >>>>   
   >>>>   
   >>>>>          but the condition of aᵢ=0 only exists in 1-4-2-1,   
   aᵢ=0 cannot cause the   
   >>>>>          non-1-4-2-1 cycle of n₁,n₂,n₃,...,nₓ.   
      
   That doesn't follow from anything you've said so far.  So this proof will not   
   make you famous. Maybe   
   you can work on this and fill in the gap.  You need an earlier "Prop: If   
   aᵢ=0 then bᵢ <= 4" or   
   equivalent".  Then you can be famous!   
      
   It does seem to be the case with numbers I've tried [n up to 30,000,000 ish],   
   that aᵢ only becomes   
   zero when we hit the final 1-4-2-1 cycle, so your claim is plausibly /true/,   
   but that's not a   
   /proof/ in any sense, of course.   
      
   >>>>   
   >>>> That doesn't follow from anything you've said so far.  So this proof   
   will not make you famous.   
   >>>> Maybe   
   >>>> you can work on this and fill in the gap.  You need an earlier "Prop: If   
   aᵢ=0 then bᵢ <= 4" or   
   >>>> equivalent".  Then you can be famous!   
   >>>>   
   >>>> It does seem to be the case with numbers I've tried [n up to 30,000,000   
   ish], that aᵢ only   
   >>>> becomes   
   >>>> zero when we hit the final 1-4-2-1 cycle, so your claim is plausibly   
   /true/, but that's not a   
   >>>> /proof/ in any sense, of course.   
   >>>>   
   >>>>>          Therefore, we can conclude that cop(n) iterations are   
   non-cyclic.   
      
   No, this doesn't follow because your 1-4-2-1 cycle claim is not proved.   
      
   >>>>>   
   >>>>> Prop: For any n∈N<1,+1>, the cop iteration operation terminates.   
   >>>>>      Proof: Since an odd number n will always become even immediately   
   after the   
   >>>>>          cop iteration, it must undergo n/2 iterations.   
   Therefore, we have an   
   >>>>>          equivalent rcop3:   
   >>>>>   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)