From: cr88192@gmail.com   
      
   On 2/21/2026 2:40 PM, Terje Mathisen wrote:   
   > BGB wrote:   
   >> On 2/15/2026 5:50 AM, David Brown wrote:   
   >>> On 14/02/2026 22:22, MitchAlsup wrote:   
   >>>>   
   >>>> David Brown  posted:   
   >>>>   
   >>>>> On 14/02/2026 19:48, MitchAlsup wrote:   
   >>>>>>   
   >>>>>> Thomas Koenig  posted:   
   >>>>>>   
   >>>>>>> Some people are throwing large amounts of computing power at trying   
   >>>>>>> to disprove the Collatz conjecture.  Graphics cards have sped this   
   >>>>>>> up enormously.   
   >>>>>>>   
   >>>>>>> (A reminder, if any is needed:  From a starting number n, the   
   >>>>>>> transformation, recursively applied,   
   >>>>>>>   
   >>>>>>>   
   >>>>>>>      f(n) = 3*n+1, if n is odd; =n/2 if n is even.   
   >>>>>>>   
   >>>>>>> is conjectured to always reach 1 for any positive integer 1).   
   >>>>>>   
   >>>>>> While n/2 remains even, n/2 is guaranteed to converge to 1.   
   >>>>>> So, only the odd cases are interesting.   
   >>>>>>   
   >>>>>> 3*n+1 is always even (since n was odd, and odd*odd is odd and   
   >>>>>> odd+1 is even). So, a double iteration is (3*n+1)/2.   
   >>>>>   
   >>>>> Yes, that is often a micro-optimisation used.   
   >>>>>   
   >>>>>>> All the work is done on general-purpose hardware, which has many   
   >>>>>>> capabilities that are not needed, and consume area and power that   
   >>>>>>> special-purpose hardware would not need.  Also, the hardware   
   >>>>>>> is limited to 64-bit integers, and the range of tested numbers   
   >>>>>>> is now up to 2^71, so   
   >>>>>>   
   >>>>>> Induction would say it has been proven by then.   
   >>>>>   
   >>>>> Would you like to re-think that?  "Induction" says nothing of the   
   >>>>> sort.   
   >>>>>   
   >>>>> The conjecture has been proven true for all numbers up to 2 ^ 71   
   >>>>> (assuming that is the current figure) - it has most definitely /not/   
   >>>>> been proven to be true for all numbers.  There are other things   
   >>>>> proven   
   >>>>> about it, such as the asymptotic rarity of numbers that are exceptions   
   >>>>> to the pattern, but no one has any notion of how to prove it in   
   >>>>> general.   
   >>>>   
   >>>> By proving up to 2^71, you simultaneously prove that it cannot be   
   >>>> proven   
   >>>> by computer-like arithmetic processes. What if the number was   
   >>>> 2^71,000,000   
   >>>> you still have not proven it? Thereby, it is not provable by simple   
   >>>> computer   
   >>>> arithmetic processes.   
   >>>>   
   >>>   
   >>> All that has been proven is that if the conjecture is not true, then   
   >>> the smallest exception to the pattern is greater than 2 ^ 71.  Maybe   
   >>> it is 2 ^ 71 + 1.  Current computer technology could take the search   
   >>> a lot further than just 2 ^ 71 - if someone wanted to pay for it!   
   >>> Future computer technology could perhaps greatly increase the   
   >>> bounds.  Maybe Thomas's "useless machine" could lead to far greater   
   >>> bounds without excessive costs - and maybe research into that could   
   >>> lead to useful new technology or techniques with applications beyond   
   >>> an interesting maths problem.   
   >>>   
   >>> There are lots of examples of conjectures where the first exception   
   >>> is a high number, and all testing of low numbers fitted the   
   >>> conjectures. Sometimes such counter-examples are far beyond the reach   
   >>> of any brute- force computational testing, but sometimes not.   
   >>>   
   >>> We have not proven that the Collatz Conjecture can be disproven by   
   >>> brute-force testing - we have merely shown that doing so would be   
   >>> difficult, and seems unlikely to be successful.  And we have known   
   >>> all along that computational methods can never prove a conjecture   
   >>> like this to be true - that much should be obvious.   
   >>>   
   >>> Testing conjectures like this can be helpful to mathematicians.   
   >>> Sometimes they can show patterns that can be used to get more   
   >>> insights - maybe there is a pattern in the numbers that lead to peaks   
   >>> of growth of the Collatz function before dropping towards 1.  Such   
   >>> patterns can inspire proofs - or more targeted searches for exceptions.   
   >>>   
   >>>> Ergo, you need a different means.   
   >>>   
   >>> You don't imagine that the only thing mathematicians have done with   
   >>> the Collatz Conjecture is test it to large numbers, do you?   
   >>>   
   >>   
   >> In theory, large numbers could disprove it, if an exception were found.   
   >> However, it fails to prove it either; and if no value is found (or   
   >> would be found) it doesn't prove anything.   
   >>   
   >>   
   >>>>> Being true up to 2 ^ 71 makes it reasonable to believe it is always   
   >>>>> true, but that is very different from being /proven/.  There are   
   >>>>> plenty   
   >>>>> of mathematical conjectures that are true up to very large numbers,   
   >>>>> but   
   >>>>> fail later on.   
   >>>>   
   >>>> You need cannot even /prove/ it using BigNum computer arithmetic in   
   >>>> finite   
   >>>> time.   
   >>>   
   >>> Surely everyone who has done high-school mathematics already realises   
   >>> that a conjecture like this cannot be proven by trail and error   
   >>> alone? Brute-force testing is about looking for exceptions to /   
   >>> disprove/ the conjecture, or gaining insights that can lead to its   
   >>> proof or disproof.   
   >>>   
   >>   
   >> Yeah, pretty much...   
   >>   
   >> My own thinking (mostly since looking at this thread, earlier today)   
   >> has led me to realize first that the probability of any number   
   >> containing a divergent path is less than the reciprocal of the value   
   >> (related to prior post in this thread).   
   >>   
   >> Then, further realized that, since one doesn't just need *one* number   
   >> with the probability of a divergent path, one needs an infinite series   
   >> (since any non-divergent path immediately collapses back into a   
   >> convergent path).   
   >   
   > You do have to detect an infinite loop, but that's easy to do:   
   > Even if you don't employ the classic one-step/two-step approach, simply   
   > stopping after 8k iterations and then let the supervisor check it   
   > properly would be fine.   
   >   
      
   Yeah, assuming it is being tested.   
      
   Another option could be to detect an overflow from whatever size of   
   integer, assuming the starting point is not within a region where   
   near-immediate overflow is likely.   
      
      
   Seemingly the definitions on Wikipedia don't appear to exclude n==0,   
   which could lead to an infinite loop: 0 is even, and 0/2==0. Can   
   probably assume 0 is excluded because that would make it pointlessly   
   trivial (even if they say, say, "positive integer" rather than "counting   
   number" or similar, where the set of positive integers includes 0, but   
   "counting numbers" do not).   
      
   But, yeah, it would be false if the input set included 0.   
      
      
      
      
   > Terje   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)