From: david.brown@hesbynett.no   
      
   On 26/01/2026 17:07, wij wrote:   
   > On Mon, 2026-01-26 at 23:51 +0800, wij wrote:   
   >   
   >   
   > The proof is pretty much finalized, only 122 lines.   
   > rcop3(int n) is provided with guidelines about how to prove it. But no one   
   can   
   > verify, because it is told and so believed IMPOSSIBLE! Funny! 15 lines of   
   codes   
   > with verification instructions, no one can test, and think they are expert C   
   > developer!   
   > Posting is just a procedure and must assume some can verify (don't make the   
   > mistake, the self-illusion that I need your 'professional' verification).   
   >   
   > https://sourceforge.net/projects/cscall/files/MisFiles/Coll-pr   
   of-en.txt/download   
   > ....[cut]   
   >        void rcop3(int n) {   
   >          int a=n,b=0;   
   >          for(; a+b!=1;) {   
   >            if((a%2)!=0) {   
   >              --a; ++b;   
   >            }   
   >            // a/b measure point A   
   >            if((b%2)!=0) {   
   >              a= 3*a;   
   >              b= 3*b+1;   
   >            }   
   >            a= a/2;   
   >            b= b/2;   
   >          }   
   >        }   
   >   
   >        // .....   
   >        This proof demonstrates:   
      
   You haven't given any kind of a proof.  You have given an algorithm,   
   written in a silly way (C is not appropriate for mathematical proofs).   
   Without the explanations, justifications, and logical steps forming a   
   coherent argument, there is no proof.   
      
   But let's take your code as it is.  It is correct that given a positive   
   "n", and ignoring the range limitation of "int" (that's one reason why C   
   is a silly way to write such things), then the algorithm will stop if   
   and only if successive applications of the Collatz function result in 1.   
      
   >          1. The ratio a/b is decreasing.   
      
   That is almost correct.  At the start of the algorithm, a/b is n/0,   
   which we can view here as positive infinity.  For each run through the   
   algorithm, a/b either decreases, or stays the same.  So the ratio is   
   non-increasing, rather than strictly decreasing.  But any sequence of   
   repeated runs without a decrease will be finite in length, so it will   
   always decrease after enough runs.   
      
   >          2. b has limit.   
      
   I see no justification for that claim.  (And you don't mention whether   
   that limit is dependent on n, or some absolute limit.)   
      
   >          3. a must decrease to below b because of the above reasons.   
      
   I see no justification for that claim.  Even if you are correct that b   
   has a limit (it may be true, even though you have done nothing to show   
   it), that would not justify this claim.   
      
   If b first exceeds a, then it will stay greater than a, but there is no   
   proof that that is guaranteed to happen.   
      
   >          4. Done, n=a+b has limit (cop(n) is known to terminate for n<2¹⁶   
   at   
   >             least.   
      
   We know it will terminate for n < 2 ** 71, because that has been tested   
   experimentally.   
      
   >   
   > Funny!!!!!!!!   
   >   
      
   Hilarious.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)