From Newsgroup: comp.lang.c

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/Coll-proof-en.txt/download
The text is converted by google translate with modest modification from https://sourceforge.net/projects/cscall/files/MisFiles/Coll-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, nreeN<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, nreeN<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).
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 nb|o, ab|o, bb|o 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:
nreU, nree, nrea, ..., nreo (n=nreU).
Because --a and ++b are continuously interpolated during the cycle, if
ab|orea0, then bb|o and nb|o=ab|o+bb|o will increase infinitely, contradicting the
assumption that nb|o is cyclic. Therefore, ab|o=0 must hold during the cycle,
but the condition of ab|o=0 only exists in 1-4-2-1, ab|o=0 cannot cause the
non-1-4-2-1 cycle of nreU,nree,nrea,...,nreo.
Therefore, we can conclude that cop(n) iterations are non-cyclic.
Prop: For any nreeN<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:
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;
}
}
Let n be odd and there be no `--a`, `++b` process. Assume that each odd
operation is paired with only one even operation (the actual ratio is 1.5
even operations, but 1.5 is a statistical value; the decisive inference
can only take the guaranteed value of 1). Then, at measurement point A,
we have:
areU = n-1
areo = (3*areoreireU)/2 = ... = (n-1)*(3/2)-urU+-|
breU = 1
breo = (3*breoreireU+1)/2 = ... = 2*(3/2)-urU+-| -1
areo/breo = (areoreireU)/(breoreireU) = ((n-1)*(3/2)-urU+-|)/(2*(3/2)-urU+-| -1)
= ... = (n-1)/(2-1/(3/2)-urU+-|)
Interim summary: areo/breo < areoreireU/breoreireU and lim{x->reR} areo/breo = (n-1)/2.
(After eight iterations, areo/breo is approximately 0.51. Actual iterations
may also include --a and ++b operations, so the actual value of areo/breo
will converge faster than the formula)
Let r = a/b, then n/b = (a+b)/b = a/b+1 = r+1
=> b = (a+b)/(r+1)
Assuming the cop(n) iteration does not terminate, and m is one of the
number in the iteration sequence. Therefore, we can derive the
following:
=> b = m/(r+1)
=> The limit of r+1 = (m-1)/2 + 1 = (m+1)/2
=> b = (2*m)/(m+1) = 2/(1+1/m)
=> b = 2 (the limit of b. At least it is known that m will be a large
number)
Since there is a limit (the numerical value is not important), the
iteration involves an infinite number of iterations of --a, a will
inevitably become zero, so the iteration cannot fail to meet the
iteration termination contion.
If n is even, then repeating the even operation (a finite number of times)
cop(n) will yield an odd number without affecting the termination result
as stated above. Therefore, the proposition is proved.
[Reference] Real number and infinity. Recurring decimals are irrational numbers.
https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 25 Jan 2026 00:37:38 +0800, wij wrote:

[Reference] Real number and infinity. Recurring decimals are
irrational numbers.

No they are not. rCLIrrationalrCY means rCLnot expressible as a ratiorCY. The rCLratiorCY in question means that of two integers. Recurring decimals are always expressible as a ratio of two integers, and the proof of this
is pretty trivial.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 25 Jan 2026 00:37:38 +0800, wij wrote:

[Reference] Real number and infinity. Recurring decimals are
irrational numbers.

So x = 0.1212.... is irrational?
100x = 12.1212...
- x = -0.1212...
=== ==========
99x = 12
x = 4/33

This generalizes to work with any recurring decimal. When the recurrence
is n digits long (in the above example, n=2), just multiply by 10^n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sat, 2026-01-24 at 23:06 -0500, James Kuyper wrote:

On Sun, 25 Jan 2026 00:37:38 +0800, wij wrote:

[Reference] Real number and infinity. Recurring decimals are
irrational numbers.

So x = 0.1212.... is irrational?
100x = 12.1212...
--a x = -0.1212...
-a===-a-a ==========
-a99x = 12
x = 4/33

This generalizes to work with any recurring decimal. When the recurrence
is n digits long (in the above example, n=2), just multiply by 10^n.

Such arithmetic is called approximation, or magic proof simply because
no such axiom/theorem exists (it will cause contradiction).
Take Prop2 for example: "0.1212..." should mean 12/100 +12/10000 +12/1000000 +....
Infinite addition of rational numbers cannot be rational number the same reason as infinite addition of natural numbers cannot be a natural number.
Bunches of reasons are there.
----------------- https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
.....[cut]
Prop 1: The statement rao+rao=rao (or, let a,breerao (natural numbers), then a+breerao) holds
only for a finite number of addition steps.
Proof: Non-zero natural numbers are strictly increasing when added together.
Adding with an infinite number of steps will yield a number of
infinite length. By Axiom 1, such a number is not a natural number. Prop 2: raU+raU=raU (the sum of a rational number and a rational number is still a
rational number) The statement holds only for a finite number of
addition steps.
Proof: If the positive rational number q is strictly increasing by
accumulation, and the infinite term q = a/b = qreU+qree+qrea..., then either
a or b must be infinitely large.
The above propositions raise a question:
a+b = (a+b) ... leads to the dubious conclusion a,breeN => a+breeN (or the
question of the number of applications requires explanation).
a/b+c/d = (ad+cb)/bd ... leads to the dubious conclusion a,breeraU => a+breeraU (not
always true).
Thus, formal logic cannot handle propositions involving the concept of
infinite procedures.
Prop 3: Recurring decimals are irrational numbers.
Proof: Let x be a recurring decimal, 0<x<1, x has a recurring period S, and is
written in the base system as x=0.SreUSreeSrea...SreR. Then by definition x= SreU/b
+Sree/b-# +Srea/b-| +... +SreR/b^reR = qreU +qree +qrea +...+qreR (breerao).
That is, recurring decimals are a special case of "raU+raU". According to Prop 2,
when adding terms infinitely, x is not a rational number (i.e., irrational).

Note: By the way, a brief explanation of common algebraic magic:
(1) x= 0.999...
(2{ 10x= 9.999... // may implicitly define 0.999... in (1)
(3) 10x= 9+x
(4) 9x=9
(5) x=1
Answer: There is no axiom or theorem to prove that (1) <=> (3).
(3) is one of the infinite interpretations of (1), or (3) is the
'introduction' definition of 0.999..., etc. In short, there is no
necessary relationship between (3) and (1), or it still needs to be
proved. For example, 0.999... formed by 1/2+1/4+1/8+... does not have the
property of (3).
There are actually many other examples, for example:
1. If 0.999... = 1 holds, then it can be proved that the unique prime
factorization theorem of positive integers does not hold:
0.999... = 999.../1000... = 9*(111...)/(5*2)*... =1
<=> 3*3*(111...) = (5*2)*...
The integer to the left of the equal sign contains the prime number
3, but the integer to the right cannot contain 3... Prime
factorization is not unique.
2. Are the intervals [0,1) and [0,1] equal? 0.999...ree[0,1)? What number
is to the left of 1 (infinitely close)? Can we define a number x
that can be infinitely close to c but not equal to c (e.g.,
0.999...*c)?...
3. 1/3 = 0.333... + non-zero-remainder (True identity. How to deny?) .... [cut]
------------------
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 25 Jan 2026 13:28:31 +0800, wij wrote:

On Sat, 2026-01-24 at 23:06 -0500, James Kuyper wrote:

This generalizes to work with any recurring decimal. When the
recurrence is n digits long (in the above example, n=2), just
multiply by 10^n.

Such arithmetic is called approximation ...

No, itrCOs exact.

I think your problem is you are trying to think about maths using a
specific low-level programming language (C or C++) which only supports finite-precision integers.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 2026-01-25 at 08:15 +0000, Lawrence DrCOOliveiro wrote:

On Sun, 25 Jan 2026 13:28:31 +0800, wij wrote:

On Sat, 2026-01-24 at 23:06 -0500, James Kuyper wrote:

This generalizes to work with any recurring decimal. When the
recurrence is n digits long (in the above example, n=2), just
multiply by 10^n.

Such arithmetic is called approximation ...

No, itrCOs exact.

Prove it. No one wants blind belief.

I think your problem is you are trying to think about maths using a
specific low-level programming language (C or C++) which only supports finite-precision integers.

Your problem is just repeating what you are told to repeat, no meaning.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 25/01/2026 09:46, wij wrote:

On Sun, 2026-01-25 at 08:15 +0000, Lawrence DrCOOliveiro wrote:

On Sun, 25 Jan 2026 13:28:31 +0800, wij wrote:

On Sat, 2026-01-24 at 23:06 -0500, James Kuyper wrote:

This generalizes to work with any recurring decimal. When the
recurrence is n digits long (in the above example, n=2), just
multiply by 10^n.

Such arithmetic is called approximation ...

No, itrCOs exact.

Prove it. No one wants blind belief.

I think your problem is you are trying to think about maths using a
specific low-level programming language (C or C++) which only supports
finite-precision integers.

Your problem is just repeating what you are told to repeat, no meaning.

It's a long time since I did proofs of the properties and arithmetic of rational numbers, but I certainly did them at university. I also
derived the real numbers from Peano axioms. It is not "blind belief",
it is easily within the capabilities of maths undergraduates. I am not
going to go through such a derivation of rational numbers and decimal expansions here - if you don't accept the simple, clear proof given by
James, a long one working directly from the ZF axioms is going to be far
over your head, and a lot of effort for no gain. I am confident,
however, that both James and Lawrence could also do such proofs themselves.

What you seem to be doing is inventing your own "axioms" (without any justification, or proof of either consistency or necessity), inventing
your own definitions for well-established mathematical objects (like the rational numbers) without any proofs, derivations, or explanations, and
then making wild claims that aren't even justified within your own system.

It's a complete mess, and there is little point in anyone trying to pull
it apart to help correct your errors. As the meme goes, it's not even
wrong. You have a lot of work ahead of you to "unlearn" the
misconceptions that drive you here, before you can begin to learn some mathematics.

And it is totally off-topic for C and C++. The last thing these groups
need is another Olcott. You also post sometimes on C and C++ - please
stick to those topics in this group.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 2026-01-25 at 10:38 +0100, David Brown wrote:

On 25/01/2026 09:46, wij wrote:

On Sun, 2026-01-25 at 08:15 +0000, Lawrence DrCOOliveiro wrote:

On Sun, 25 Jan 2026 13:28:31 +0800, wij wrote:

On Sat, 2026-01-24 at 23:06 -0500, James Kuyper wrote:

This generalizes to work with any recurring decimal. When the recurrence is n digits long (in the above example, n=2), just multiply by 10^n.

Such arithmetic is called approximation ...

No, itrCOs exact.

Prove it. No one wants blind belief.

I think your problem is you are trying to think about maths using a specific low-level programming language (C or C++) which only supports finite-precision integers.

Your problem is just repeating what you are told to repeat, no meaning.

It's a long time since I did proofs of the properties and arithmetic of rational numbers, but I certainly did them at university.-a I also
derived the real numbers from Peano axioms.-a It is not "blind belief",
it is easily within the capabilities of maths undergraduates.-a I am not going to go through such a derivation of rational numbers and decimal expansions here - if you don't accept the simple, clear proof given by James, a long one working directly from the ZF axioms is going to be far over your head, and a lot of effort for no gain.-a I am confident,
however, that both James and Lawrence could also do such proofs themselves.

What you seem to be doing is inventing your own "axioms" (without any justification, or proof of either consistency or necessity), inventing
your own definitions for well-established mathematical objects (like the rational numbers) without any proofs, derivations, or explanations, and
then making wild claims that aren't even justified within your own system.

It's a complete mess, and there is little point in anyone trying to pull
it apart to help correct your errors.-a As the meme goes, it's not even wrong.-a You have a lot of work ahead of you to "unlearn" the
misconceptions that drive you here, before you can begin to learn some mathematics.

And it is totally off-topic for C and C++.-a The last thing these groups need is another Olcott.-a You also post sometimes on C and C++ - please stick to those topics in this group.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 2026-01-25 at 10:38 +0100, David Brown wrote:

On 25/01/2026 09:46, wij wrote:

On Sun, 2026-01-25 at 08:15 +0000, Lawrence DrCOOliveiro wrote:

On Sun, 25 Jan 2026 13:28:31 +0800, wij wrote:

On Sat, 2026-01-24 at 23:06 -0500, James Kuyper wrote:

This generalizes to work with any recurring decimal. When the recurrence is n digits long (in the above example, n=2), just multiply by 10^n.

Such arithmetic is called approximation ...

No, itrCOs exact.

Prove it. No one wants blind belief.

I think your problem is you are trying to think about maths using a specific low-level programming language (C or C++) which only supports finite-precision integers.

Your problem is just repeating what you are told to repeat, no meaning.

It's a long time since I did proofs of the properties and arithmetic of rational numbers, but I certainly did them at university.-a I also
derived the real numbers from Peano axioms.-a It is not "blind belief",
it is easily within the capabilities of maths undergraduates.-a I am not going to go through such a derivation of rational numbers and decimal expansions here - if you don't accept the simple, clear proof given by James, a long one working directly from the ZF axioms is going to be far over your head, and a lot of effort for no gain.-a I am confident,
however, that both James and Lawrence could also do such proofs themselves.

I see no proof, just opinion, 'blind belief', repeating. I was expecting
more like copy-paste.... Just cannot prove anything yourself.

What you seem to be doing is inventing your own "axioms" (without any justification, or proof of either consistency or necessity), inventing
your own definitions for well-established mathematical objects (like the rational numbers) without any proofs, derivations, or explanations, and
then making wild claims that aren't even justified within your own system.

It's a complete mess, and there is little point in anyone trying to pull
it apart to help correct your errors.-a As the meme goes, it's not even wrong.-a You have a lot of work ahead of you to "unlearn" the
misconceptions that drive you here, before you can begin to learn some mathematics.

Said a lot, but I am afraid soon you will find you are accusing yourself.
That is embarrassing, but I know people will forget, and at most find-a
excuse for themselves.

And it is totally off-topic for C and C++.-a The last thing these groups need is another Olcott.-a You also post sometimes on C and C++ - please stick to those topics in this group.

I agree such repeating decimal is rational or not things may be off-topic,-a but who brought it up?
Please stick to the topic. There are many C/C++ stuff in my post, why you people always choose to pick non-topic to post???-a
You know the truth in subconscious?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

wij <wyniijj5@gmail.com> writes:

On Sun, 2026-01-25 at 08:15 +0000, Lawrence DrCOOliveiro wrote:

On Sun, 25 Jan 2026 13:28:31 +0800, wij wrote:

On Sat, 2026-01-24 at 23:06 -0500, James Kuyper wrote:

This generalizes to work with any recurring decimal. When the
recurrence is n digits long (in the above example, n=2), just
multiply by 10^n.

Such arithmetic is called approximation ...

No, itrCOs exact.

Prove it.

To be clear, you mean "prove it to me" but that, I suspect is
impossible. If you go somewhere where proofs are on-topic (like
sci.maths) you will get many proofs of varying degrees of rigour. None
will persuade you, but at least there will be some real maths on that
group.
--
Ben.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 25/01/2026 12:06, wij wrote:

On Sun, 2026-01-25 at 10:38 +0100, David Brown wrote:

On 25/01/2026 09:46, wij wrote:

And it is totally off-topic for C and C++.-a The last thing these groups
need is another Olcott.-a You also post sometimes on C and C++ - please
stick to those topics in this group.

I agree such repeating decimal is rational or not things may be off-topic, but who brought it up?

/You/ brought it up - in your references for your off-topic post. I
can't say why James picked that particular part to focus on - perhaps it
is because it was clear what you had written, and obviously totally
false and a complete misunderstanding of rational numbers, limits, and
decimal representations, as well as demonstrating that you don't
understand how mathematics works. It is much harder to criticise the
Collatz Conjecture stuff, because what you have written is gobbledegook.
Perhaps it made some sense in your original language (I may be wrong,
but I think it is Chinese), but has been mangled beyond recognition by
machine translation.

Please stick to the topic. There are many C/C++ stuff in my post, why you people always choose to pick non-topic to post???
You know the truth in subconscious?

The Collatz conjecture is totally off-topic here. Writing a function
for it in C does not make it on-topic.

Now, if you want to talk purely about a C implementation of the Collatz function, perhaps looking at ways to handle it efficiently for large
numbers, that might be an interesting and on-topic here.

If you really had proof of the Collatz conjecture, especially one this
short, it would be sensational - Abel prize or Fields medal level stuff.
We should be hearing about it in the mainstream news. It is an
example of a problem that is easy to explain, but extraordinarily
difficult to proof. You should be talking about it in mathematics
arenas, not a C newsgroup - and I strongly recommend you do so in a
group in your native language.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

In article <877bt6sz8j.fsf_-_@bsb.me.uk>, Ben Bacarisse <ben@bsb.me.uk> wrote:

To be clear, you mean "prove it to me" but that, I suspect is
impossible. If you go somewhere where proofs are on-topic (like
sci.maths) you will get many proofs of varying degrees of rigour. None
will persuade you, but at least there will be some real maths on that
group.

If he goes to sci.math he will find the same endless nonsense that he
believes in.

-- Richard
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 2026-01-25 at 12:47 +0100, David Brown wrote:

On 25/01/2026 12:06, wij wrote:

On Sun, 2026-01-25 at 10:38 +0100, David Brown wrote:

On 25/01/2026 09:46, wij wrote:

And it is totally off-topic for C and C++.-a The last thing these groups need is another Olcott.-a You also post sometimes on C and C++ - please stick to those topics in this group.

I agree such repeating decimal is rational or not things may be off-topic, but who brought it up?

/You/ brought it up - in your references for your off-topic post.-a I
can't say why James picked that particular part to focus on - perhaps it
is because it was clear what you had written, and obviously totally
false and a complete misunderstanding of rational numbers, limits, and decimal representations, as well as demonstrating that you don't
understand how mathematics works.-a It is much harder to criticise the Collatz Conjecture stuff, because what you have written is gobbledegook.
-a Perhaps it made some sense in your original language (I may be wrong,
but I think it is Chinese), but has been mangled beyond recognition by machine translation.

Please stick to the topic. There are many C/C++ stuff in my post, why you people always choose to pick non-topic to post???
You know the truth in subconscious?

The Collatz conjecture is totally off-topic here.-a Writing a function
for it in C does not make it on-topic.

Do posters have to write a C function for sales of tissue paper to be-a on-topic? It is because you believe you know C (but shallow).

Now, if you want to talk purely about a C implementation of the Collatz function, perhaps looking at ways to handle it efficiently for large numbers, that might be an interesting and on-topic here.

Why did I often heard you guys arguing about wild 'philosophy' of C-a
language (hardly C related) all day long. You are not the king.

If you really had proof of the Collatz conjecture, especially one this short, it would be sensational - Abel prize or Fields medal level stuff.
-a We should be hearing about it in the mainstream news.-a It is an
example of a problem that is easy to explain, but extraordinarily
difficult to proof.-a You should be talking about it in mathematics
arenas, not a C newsgroup - and I strongly recommend you do so in a
group in your native language.

Sounds to confirm what I thought: All is simply because you are not there
but 'believe' you are. You like to mimic the TV-professional style excuse.
You cannot evaluate the simple proof of Collatz problem (even in short C/C++).-a
But choose to wait to be told to believe and think you understand.
The same as "N+N=N infinitely is false", you cannot see it yourself but wait to be told, and think you understand the basic.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 25 Jan 2026 13:28:31 +0800, wij wrote:

On Sat, 2026-01-24 at 23:06 -0500, James Kuyper wrote:

This generalizes to work with any recurring decimal. When the
recurrence is n digits long (in the above example, n=2), just
multiply by 10^n.

Such arithmetic is called approximation ...

So what is, in your opinion, the exact representation of 4/33 as a
decimal fraction? Marking it as infinitely repeating means that it is
not in any sense an approximation - it is exact. If it were an
approximation, there would be a finite difference between 4/33 and
0.1212.... How big is that difference? No matter how small of a finite difference you might think it has, going to infinitely many decimal
digits makes the actual difference smaller than that.
Keep in mind that, in the absence of specification to the contrary,
we're talking about the standard real number system, not one of those alternatives that extends the real number system by adding
infinitesimals, such as the surreals or the hyperreals.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 2026-01-25 at 11:25 -0500, James Kuyper wrote:

On Sun, 25 Jan 2026 13:28:31 +0800, wij wrote:

On Sat, 2026-01-24 at 23:06 -0500, James Kuyper wrote:

This generalizes to work with any recurring decimal. When the
recurrence is n digits long (in the above example, n=2), just
multiply by 10^n.

Such arithmetic is called approximation ...

So what is, in your opinion, the exact representation of 4/33 as a
decimal fraction? Marking it as infinitely repeating means that it is
not in any sense an approximation - it is exact.

You need to prove 4/33 exactly equal to 0.1212..., not approximation.
But,...

If it were an
approximation, there would be a finite difference between 4/33 and
0.1212.... How big is that difference? No matter how small of a finite difference you might think it has, going to infinitely many decimal
digits makes the actual difference smaller than that.

Yes, the same as infinity/infinitesimal.

Keep in mind that, in the absence of specification to the contrary,
we're talking about the standard real number system, not one of those alternatives that extends the real number system by adding
infinitesimals, such as the surreals or the hyperreals.

True-aif you are not referring to the current 'standard real number system'. What else? (doesn't sound to contain much information)
The standard real number system is not a constant thing, it will correct itself. Not even religion is constant.
To be explicitly 'C' related, I remember people talking about what INF-a
should mean (an option may be merely for signifying overflow), I would
suggest reserve the bit, not mixing with other meaning.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-01-25 06:47, David Brown wrote:

On 25/01/2026 12:06, wij wrote:

...

I agree such repeating decimal is rational or not things may be
off-topic,
but who brought it up?

/You/ brought it up - in your references for your off-topic post. I
can't say why James picked that particular part to focus on - perhaps
it is because it was clear what you had written, and obviously totally
false and a complete misunderstanding of rational numbers, limits, and decimal representations, as well as demonstrating that you don't
understand how mathematics works.

I've got wij filtered out, so I didn't see his original post. I did see Laurence's response, which contained only the part I responded to. But
what you're saying is why I decided to respond to it.
My killfile is not intended as a punishment, nor as a promise that I
will ignore all messages posted by someone, it's just meant to reduce my annoyance by protecting me from having to pay even minimal attention to
the people in the list. When it fails, I sometimes feel a desire to respond.
In Thunderbird, I was able to take Laurence's response, select "Edit as
New Message", delete Laurence's text, and create a new message that had
headers marking it as a direct response to wij's post, not Laurence's.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 25 Jan 2026 16:46:43 +0800, wij wrote:

On Sun, 2026-01-25 at 08:15 +0000, Lawrence DrCOOliveiro wrote:

On Sun, 25 Jan 2026 13:28:31 +0800, wij wrote:

On Sat, 2026-01-24 at 23:06 -0500, James Kuyper wrote:

This generalizes to work with any recurring decimal. When the
recurrence is n digits long (in the above example, n=2), just
multiply by 10^n.

Such arithmetic is called approximation ...

No, itrCOs exact.

Prove it. No one wants blind belief.

Sure. Consider the general case of a fractional number X which can be represented by a repeating decimal:

X = 0.areUaree...areybreUbree...breObreUbree...breO...

where the arCOs and brCOs are decimal digits, such that areUaree...arey represents the initial non-repeating part, consisting of m digits,
where m reN 0, and breUbree...breO represents the repeating part, consisting
of n digits, where n > 0. First, separate out the non-repeating part:

X * 10 ** m = areUaree...arey.breUbree...breObreUbree...breO...

from which

X * 10 ** m - areUaree...arey = 0.breUbree...breObreUbree...breO...
= (breUbree...breO |+ 10 ** n) + (breUbree...breO |+ 10 ** n-#) + ...
= (breUbree...breO |+ (10 ** n - 1))

Notice thatrCOs a closed-form expression: no more indefinitely-repeating
parts at all. The right-hand side is a ratio of two integers, which is
what makes it rCLrationalrCY. If itrCOs not already in its lowest terms, it
can be made so, by cancelling out common factors. Since there are only
a finite number of integers between those values and 1, those lowest
terms exist somewhere along the point between the two, and can always
be found in a finite number of steps. QED.

I think your problem is you are trying to think about maths using a
specific low-level programming language (C or C++) which only
supports finite-precision integers.

Your problem is just repeating what you are told to repeat, no
meaning.

YourCOre not familiar with languages that support infinite-precision
integers, are you?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Sun, 2026-01-25 at 18:52 +0000, Lawrence DrCOOliveiro wrote:

On Sun, 25 Jan 2026 16:46:43 +0800, wij wrote:

On Sun, 2026-01-25 at 08:15 +0000, Lawrence DrCOOliveiro wrote:

On Sun, 25 Jan 2026 13:28:31 +0800, wij wrote:

On Sat, 2026-01-24 at 23:06 -0500, James Kuyper wrote:

This generalizes to work with any recurring decimal. When the recurrence is n digits long (in the above example, n=2), just multiply by 10^n.

Such arithmetic is called approximation ...

No, itrCOs exact.

Prove it. No one wants blind belief.

Sure. Consider the general case of a fractional number X which can be represented by a repeating decimal:

-a-a-a X = 0.areUaree...areybreUbree...breObreUbree...breO...

where the arCOs and brCOs are decimal digits, such that areUaree...arey represents the initial non-repeating part, consisting of m digits,
where m reN 0, and breUbree...breO represents the repeating part, consisting of n digits, where n > 0. First, separate out the non-repeating part:

-a-a-a X * 10 ** m = areUaree...arey.breUbree...breObreUbree...breO...

from which

-a-a-a X * 10 ** m - areUaree...arey = 0.breUbree...breObreUbree...breO... -a-a-a-a-a-a-a = (breUbree...breO |+ 10 ** n) + (breUbree...breO |+ 10 ** n-#) + ...
-a-a-a-a-a-a-a = (breUbree...breO |+ (10 ** n - 1))

Notice thatrCOs a closed-form expression: no more indefinitely-repeating parts at all. The right-hand side is a ratio of two integers, which is
what makes it rCLrationalrCY. If itrCOs not already in its lowest terms, it can be made so, by cancelling out common factors. Since there are only
a finite number of integers between those values and 1, those lowest
terms exist somewhere along the point between the two, and can always
be found in a finite number of steps. QED.

Not different from the popular 0.999...=1 magic, but 'rewrote' in more ugly form (I just thought real experts like simple proof, semi-experts like to complicated proof and believe it, even though they don't really understand it!).

X * 10 ** m - areUaree...arey = 0.breUbree...breObreUbree...breO...
= (breUbree...breO |+ 10 ** n) + (breUbree...breO |+ 10 ** n-#) + ...
= (breUbree...breO |+ (10 ** n - 1)) // what rule makes this valid derivation
// from the above line?

https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
...[cut]
(1) x= 0.999...
(2{ 10x= 9.999... // may have implicitly defined 0.999... is 1
(3) 10x= 9+x
(4) 9x=9
(5) x=1
Answer: There is no axiom or theorem to prove that (1) <=> (3).
(3) is one of the infinite interpretations of (1), or (3) is the
'introduction' definition of 0.999..., etc. In short, there is no
necessary relationship between (3) and (1), or it still needs to be
proved. For example, 0.999... formed by 1/2+1/4+1/8+... does not have the
property of (3).
----------
You might be using infinite series, see the link.

Anyway, whatever the specific proof is, you still need to refute the proof shown in the previous post, Prop1,Prop2,Prop3. You cannot pretending blind to escape it.

I think your problem is you are trying to think about maths using a specific low-level programming language (C or C++) which only
supports finite-precision integers.

Your problem is just repeating what you are told to repeat, no
meaning.

YourCOre not familiar with languages that support infinite-precision integers, are you?

No, I don't believe 'infinite-precision integer' is representable.
See the link.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

(I probably regret answering to your post.)

On 2026-01-25 18:20, wij wrote:

You need to prove 4/33 exactly equal to 0.1212..., not approximation.

Is that all you want proven; a specific example?

This appears to be as trivial as the more general approach that James
gave and that you (for reasons beyond me) don't accept (or don't see).

First
__
0.12 or 0.1212...

are just finite representations of real numbers; conventions. And 4/33
is an expression representing an operation, the division. You can just
do that computation (as you've certainly learned at school decades ago)
in individual steps, continuing each step with the remainder

4/33 = 0 => 0
40/33 = 1 => 0.1
remainder 7
70/33 = 2 => 0.12
remainder 4
40/33 = 1 and at this point you see that the _operations_ *repeat*

so the calculated decimals (1 and 2) will also repeat. And sensibly we
need a finite representation (see above) to express that.

Albert Einstein (for example) said: rCRDie Definition von Wahnsinn ist,
immer wieder das Gleiche zu tun und andere Ergebnisse zu erwartenrCL.

Are you expecting the sequence of decimals differing at some point?

If not you see that the number represented by the convention "0.1212..."
equals to the number calculated or expressed by "4/33".

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Mon, 2026-01-26 at 01:25 +0100, Janis Papanagnou wrote:

(I probably regret answering to your post.)

On 2026-01-25 18:20, wij wrote:

You need to prove 4/33 exactly equal to 0.1212..., not approximation.

Is that all you want proven; a specific example?

This appears to be as trivial as the more general approach that James
gave and that you (for reasons beyond me) don't accept (or don't see).

First
-a-a-a-a __
-a-a 0.12-a-a or-a-a 0.1212...

are just finite representations of real numbers; conventions. And 4/33
is an expression representing an operation, the division. You can just
do that computation (as you've certainly learned at school decades ago)
in individual steps, continuing each step with the remainder

-a-a 4/33 = 0-a-a-a-a => 0
-a-a 40/33 = 1-a-a-a => 0.1
-a-a remainder 7
-a-a 70/33 = 2-a-a-a => 0.12
-a-a remainder 4
-a-a 40/33 = 1-a-a-a and at this point you see that the _operations_ *repeat*

so the calculated decimals (1 and 2) will also repeat. And sensibly we
need a finite representation (see above) to express that.

-a-a Albert Einstein (for example) said: rCRDie Definition von Wahnsinn ist, -a-a immer wieder das Gleiche zu tun und andere Ergebnisse zu erwartenrCL.

Are you expecting the sequence of decimals differing at some point?

If not you see that the number represented by the convention "0.1212..." equals to the number calculated or expressed by "4/33".

Janis

Not quite sure what you mean. https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
3. 1/3 = 0.333... + non-zero-remainder (True identity. How to deny?) How would you deny it, and call the cut-off 'equation' identity?
You cut off non-zero-remainder to stop repeating, so yes, you see the part you want to see, i.e. the front part without "...", and forgot the definition "infinitely repeat" is invalidated.
Let n(i) be the repeating number 0.999... The range [n(i),1] remains 1-1 correspondence to [0,1] in each step, nothing changed except scale. Or you suggests every zooming of the small area of Mandelbrot set will be 'empty' or uniform or 'stop' for some mysterious reason.
I assume you disagee my point in the previous post that every denial must refute Prop 1= Repeating N+N infinitely does not yield natural number.
Prop 2= Repeating Q+Q infinitely does not yield rational number.
(precisely, positive rational number)
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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-proof-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:
1. The ratio a/b is decreasing.
2. b has limit.
3. a must decrease to below b because of the above reasons.
4. Done, n=a+b has limit (cop(n) is known to terminate for n<2-|rU| at
least.
---------------------------------
Funny!!!!!!!!
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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-proof-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-|rU| at
least.

We know it will terminate for n < 2 ** 71, because that has been tested experimentally.

Funny!!!!!!!!

Hilarious.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 26/01/2026 16:51, wij wrote:

On Mon, 2026-01-26 at 01:25 +0100, Janis Papanagnou wrote:

(I probably regret answering to your post.)

On 2026-01-25 18:20, wij wrote:

You need to prove 4/33 exactly equal to 0.1212..., not approximation.

Is that all you want proven; a specific example?

This appears to be as trivial as the more general approach that James
gave and that you (for reasons beyond me) don't accept (or don't see).

First
-a-a-a-a __
-a-a 0.12-a-a or-a-a 0.1212...

are just finite representations of real numbers; conventions. And 4/33
is an expression representing an operation, the division. You can just
do that computation (as you've certainly learned at school decades ago)
in individual steps, continuing each step with the remainder

-a-a 4/33 = 0-a-a-a-a => 0
-a-a 40/33 = 1-a-a-a => 0.1
-a-a remainder 7
-a-a 70/33 = 2-a-a-a => 0.12
-a-a remainder 4
-a-a 40/33 = 1-a-a-a and at this point you see that the _operations_ *repeat*

so the calculated decimals (1 and 2) will also repeat. And sensibly we
need a finite representation (see above) to express that.

-a-a Albert Einstein (for example) said: rCRDie Definition von Wahnsinn ist,
-a-a immer wieder das Gleiche zu tun und andere Ergebnisse zu erwartenrCL. >>
Are you expecting the sequence of decimals differing at some point?

If not you see that the number represented by the convention "0.1212..."
equals to the number calculated or expressed by "4/33".

Janis

Not quite sure what you mean.

https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
3. 1/3 = 0.333... + non-zero-remainder (True identity. How to deny?)

How would you deny it, and call the cut-off 'equation' identity?

Have you ever heard of the concept of "limits" ? You might want to
learn something about them before embarrassing yourself.

You cut off non-zero-remainder to stop repeating, so yes, you see the part you
want to see, i.e. the front part without "...", and forgot the definition "infinitely repeat" is invalidated.
Let n(i) be the repeating number 0.999... The range [n(i),1] remains 1-1 correspondence to [0,1] in each step, nothing changed except scale. Or you suggests every zooming of the small area of Mandelbrot set will be 'empty' or uniform or 'stop' for some mysterious reason.

I assume you disagee my point in the previous post that every denial must refute Prop 1= Repeating N+N infinitely does not yield natural number.
Prop 2= Repeating Q+Q infinitely does not yield rational number.
(precisely, positive rational number)

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Mon, 2026-01-26 at 21:07 +0100, David Brown wrote:

On 26/01/2026 16:51, wij wrote:

On Mon, 2026-01-26 at 01:25 +0100, Janis Papanagnou wrote:

(I probably regret answering to your post.)

On 2026-01-25 18:20, wij wrote:

You need to prove 4/33 exactly equal to 0.1212..., not approximation.

Is that all you want proven; a specific example?

This appears to be as trivial as the more general approach that James gave and that you (for reasons beyond me) don't accept (or don't see).

First
-a-a-a-a-a __
-a-a-a 0.12-a-a or-a-a 0.1212...

are just finite representations of real numbers; conventions. And 4/33
is an expression representing an operation, the division. You can just
do that computation (as you've certainly learned at school decades ago) in individual steps, continuing each step with the remainder

-a-a-a 4/33 = 0-a-a-a-a => 0
-a-a-a 40/33 = 1-a-a-a => 0.1
-a-a-a remainder 7
-a-a-a 70/33 = 2-a-a-a => 0.12
-a-a-a remainder 4
-a-a-a 40/33 = 1-a-a-a and at this point you see that the _operations_ *repeat*

so the calculated decimals (1 and 2) will also repeat. And sensibly we need a finite representation (see above) to express that.

-a-a-a Albert Einstein (for example) said: rCRDie Definition von Wahnsinn ist,
-a-a-a immer wieder das Gleiche zu tun und andere Ergebnisse zu erwartenrCL.

Are you expecting the sequence of decimals differing at some point?

If not you see that the number represented by the convention "0.1212..." equals to the number calculated or expressed by "4/33".

Janis

Not quite sure what you mean.

https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
-a-a-a-a-a-a-a-a-a 3. 1/3 = 0.333... + non-zero-remainder (True identity. How to deny?)

How would you deny it, and call the cut-off 'equation' identity?

Have you ever heard of the concept of "limits" ?-a You might want to
learn something about them before embarrassing yourself.

What do you know about the concept of "limits"? (You invented? Don't try to be the next one, again. I remember the other expert in this forum has humiliated himself
once, not sure which one, if I can safely predict. And I ignored the other reply,
because it is too-aobvious, I leave as record)

You cut off non-zero-remainder to stop repeating, so yes, you see the part you
want to see, i.e. the front part without "...", and forgot the definition "infinitely repeat" is invalidated.
Let n(i) be the repeating number 0.999... The range [n(i),1] remains 1-1 correspondence to [0,1] in each step, nothing changed except scale. Or you suggests every zooming of the small area of Mandelbrot set will be 'empty' or
uniform or 'stop' for some mysterious reason.

I assume you disagee my point in the previous post that every denial must refute Prop 1= Repeating N+N infinitely does not yield natural number. -a-a-a-a-a-a-a Prop 2= Repeating Q+Q infinitely does not yield rational number.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a (precisely, positive rational number)

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 26/01/2026 21:34, wij wrote:

On Mon, 2026-01-26 at 21:07 +0100, David Brown wrote:

On 26/01/2026 16:51, wij wrote:

On Mon, 2026-01-26 at 01:25 +0100, Janis Papanagnou wrote:

(I probably regret answering to your post.)

On 2026-01-25 18:20, wij wrote:

You need to prove 4/33 exactly equal to 0.1212..., not approximation. >>>>

Is that all you want proven; a specific example?

This appears to be as trivial as the more general approach that James
gave and that you (for reasons beyond me) don't accept (or don't see). >>>>
First
-a-a-a-a-a __
-a-a-a 0.12-a-a or-a-a 0.1212...

are just finite representations of real numbers; conventions. And 4/33 >>>> is an expression representing an operation, the division. You can just >>>> do that computation (as you've certainly learned at school decades ago) >>>> in individual steps, continuing each step with the remainder

-a-a-a 4/33 = 0-a-a-a-a => 0
-a-a-a 40/33 = 1-a-a-a => 0.1
-a-a-a remainder 7
-a-a-a 70/33 = 2-a-a-a => 0.12
-a-a-a remainder 4
-a-a-a 40/33 = 1-a-a-a and at this point you see that the _operations_ *repeat*

so the calculated decimals (1 and 2) will also repeat. And sensibly we >>>> need a finite representation (see above) to express that.

-a-a-a Albert Einstein (for example) said: rCRDie Definition von Wahnsinn ist,
-a-a-a immer wieder das Gleiche zu tun und andere Ergebnisse zu erwartenrCL.

Are you expecting the sequence of decimals differing at some point?

If not you see that the number represented by the convention "0.1212..." >>>> equals to the number calculated or expressed by "4/33".

Janis

Not quite sure what you mean.

https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
-a-a-a-a-a-a-a-a-a 3. 1/3 = 0.333... + non-zero-remainder (True identity. How to deny?)

How would you deny it, and call the cut-off 'equation' identity?

Have you ever heard of the concept of "limits" ?-a You might want to
learn something about them before embarrassing yourself.

What do you know about the concept of "limits"? (You invented? Don't try to be
the next one, again. I remember the other expert in this forum has humiliated himself
once, not sure which one, if I can safely predict. And I ignored the other reply,
because it is too-aobvious, I leave as record)

No, I did not invent the concept of limits. Newton and Leibnitz were
probably the first to use them, then Cauchy formalized them (if I
remember my history correctly). But I /learned/ about them - understood
them, understood proofs about them, understood how to use them.

And more importantly, I learned how mathematics works. I learned how to
read proofs, and how to write proofs. So I know writing down some
statement and claiming "True identity. How to deny?" does not
constitute a proof.

But I suspect any rational argument will fall on deaf ears here. You
don't understand mathematics, and instead think that you alone have
reinvented it and every other mathematician current and historical was
wrong. I would love to be able to help you and cure your delusions, but
I have no idea how to do that. So I will just have to do as others
have, and ignore you.



--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-01-27 17:31, Waldek Hebisch wrote:

Actually, part that is needed here is ancient, due to Eudoksos. Namely,
real numebers a and b are equal if and only if comparing them with
rational numbers gives the same result. In other words, a is different
from b if and only if there is a rational number c between a and b,
but not equal to either a or b. When computing something this
principle is clumsy, but for proofs it works quit well. Thanks
to this ancients we able compute (and prove) a bunch of transcendental equalities. Theory was finished by Dededking and Cantor who proved
that number produced by limiting process exist (earlier this was
consider true "by faith" or by invoking geometric intuition).

I think this needs some sorting. Speaking about "real numbers" in
context of Eudoksos gives a wrong impression. The ancient Greeks
expressed their mathematics in geometric properties and relations
of such entities. (Algebra, Real Numbers, etc., came much later.)

If you read modern articles you may find references to real numbers
in context of ancient Greek mathematics, but these are only used to
explain that old knowledge with modern methods.

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 27/01/2026 17:31, Waldek Hebisch wrote:

David Brown <david.brown@hesbynett.no> wrote:

On 26/01/2026 21:34, wij wrote:

On Mon, 2026-01-26 at 21:07 +0100, David Brown wrote:

On 26/01/2026 16:51, wij wrote:

On Mon, 2026-01-26 at 01:25 +0100, Janis Papanagnou wrote:

(I probably regret answering to your post.)

On 2026-01-25 18:20, wij wrote:

You need to prove 4/33 exactly equal to 0.1212..., not approximation. >>>>>>

Is that all you want proven; a specific example?

This appears to be as trivial as the more general approach that James >>>>>> gave and that you (for reasons beyond me) don't accept (or don't see). >>>>>>
First
-a-a-a-a-a __
-a-a-a 0.12-a-a or-a-a 0.1212...

are just finite representations of real numbers; conventions. And 4/33 >>>>>> is an expression representing an operation, the division. You can just >>>>>> do that computation (as you've certainly learned at school decades ago) >>>>>> in individual steps, continuing each step with the remainder

-a-a-a 4/33 = 0-a-a-a-a => 0
-a-a-a 40/33 = 1-a-a-a => 0.1
-a-a-a remainder 7
-a-a-a 70/33 = 2-a-a-a => 0.12
-a-a-a remainder 4
-a-a-a 40/33 = 1-a-a-a and at this point you see that the _operations_ *repeat*

so the calculated decimals (1 and 2) will also repeat. And sensibly we >>>>>> need a finite representation (see above) to express that.

-a-a-a Albert Einstein (for example) said: rCRDie Definition von Wahnsinn ist,
-a-a-a immer wieder das Gleiche zu tun und andere Ergebnisse zu erwartenrCL.

Are you expecting the sequence of decimals differing at some point? >>>>>>
If not you see that the number represented by the convention "0.1212..." >>>>>> equals to the number calculated or expressed by "4/33".

Janis

Not quite sure what you mean.

https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
-a-a-a-a-a-a-a-a-a 3. 1/3 = 0.333... + non-zero-remainder (True identity. How to deny?)

How would you deny it, and call the cut-off 'equation' identity?

Have you ever heard of the concept of "limits" ?-a You might want to
learn something about them before embarrassing yourself.

What do you know about the concept of "limits"? (You invented? Don't try to be
the next one, again. I remember the other expert in this forum has humiliated himself
once, not sure which one, if I can safely predict. And I ignored the other reply,
because it is too-aobvious, I leave as record)

No, I did not invent the concept of limits. Newton and Leibnitz were
probably the first to use them, then Cauchy formalized them (if I
remember my history correctly). But I /learned/ about them - understood
them, understood proofs about them, understood how to use them.

Actually, part that is needed here is ancient, due to Eudoksos. Namely,
real numebers a and b are equal if and only if comparing them with
rational numbers gives the same result. In other words, a is different
from b if and only if there is a rational number c between a and b,
but not equal to either a or b.

Thanks for that - I was not familiar with his work. (My knowledge of
the history of maths is mostly from whatever books, articles, Youtube
videos, Wikipedia pages, etc., that I have looked at - so it is quite sporadic, and is often missing many of the great names. I have never
done any kind of methodical study.) But of course mathematics is built
up in stages - it's very rare that new concepts appear completely out of
the blue. So it is natural that Newton and Leibnitz built on earlier
work, through many other mathematicians, back to Eudoksos. And
Eudoksos' work was an extension of earlier work on approximating pi, and
so on.

I always think it is fascinating that between any two distinct rationals
there is at least one real number, and between any two distinct real
numbers there is at least one ration number - and yet the cardinality of
the reals is the power-set of the cardinality of the rational numbers.

When computing something this
principle is clumsy, but for proofs it works quit well. Thanks
to this ancients we able compute (and prove) a bunch of transcendental equalities. Theory was finished by Dededking and Cantor who proved
that number produced by limiting process exist (earlier this was
consider true "by faith" or by invoking geometric intuition).

Dedekind cuts are one of the ways to construct the real numbers -
basically, filling in the gaps in the rationals by including the numbers produced by limiting processes in sets of rationals. So he did not
really prove that these limits exist - he defined the reals to be these limits, and then proved that this formal definition of the real numbers
worked the way everyone had assumed they worked.


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 26/01/2026 16:51, wij wrote:
...

https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
3. 1/3 = 0.333... + non-zero-remainder (True identity. How to deny?)
How would you deny it, and call the cut-off 'equation' identity?

I deny it easily - the remainder is exactly 0.

You cut off non-zero-remainder to stop repeating, so yes, you see the part you
want to see, i.e. the front part without "...", and forgot the definition "infinitely repeat" is invalidated.

There's no non-zero-remainder to cut off, nor is there any need to stop repeating. It repeats endlessly, and it is only because of the endless repetition that the remainder is 0. If it ever ended, the remainder
would be non-zero, as you claim.

The flaw is in your property 2, which claims that an infinite sum of
rational numbers is not a rational number. That's unambiguously not the
case in the standard real number system. Your proof of that claim is
based upon asserting that the numerator and denominator of each step in
the infinite series has a larger number of digits (which isn't
necessarily true - but that's unimportant), but ignores the fact that
the limit of an infinite sequence can have smaller numerators and
denominators than the terms that make up the sequence.

...

Prop 2= Repeating Q+Q infinitely does not yield rational number.
(precisely, positive rational number)

I dispute the validity of the proof of Prop 2.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Mon, 2026-01-26 at 21:18 -0500, James Kuyper wrote:

On 26/01/2026 16:51, wij wrote:
...

https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
-a-a-a-a-a-a-a-a-a 3. 1/3 = 0.333... + non-zero-remainder (True identity. How to deny?)
How would you deny it, and call the cut-off 'equation' identity?

I deny it easily - the remainder is exactly 0.

You cut off non-zero-remainder to stop repeating, so yes, you see the part you
want to see, i.e. the front part without "...", and forgot the definition "infinitely repeat" is invalidated.

There's no non-zero-remainder to cut off, nor is there any need to stop repeating. It repeats endlessly, and it is only because of the endless repetition that the remainder is 0. If it ever ended, the remainder
would be non-zero, as you claim.

Don't you see that you made a number of assertions beyond your standard allows. "... can have smaller numerators and denominators..." ... How? Prove it, not asserting it.

The flaw is in your property 2, which claims that an infinite sum of
rational numbers is not a rational number. That's unambiguously not the
case in the standard real number system. Your proof of that claim is
based upon asserting that the numerator and denominator of each step in
the infinite series has a larger number of digits (which isn't
necessarily true - but that's unimportant), but ignores the fact that
the limit of an infinite sequence can have smaller numerators and denominators than the terms that make up the sequence.

Accordingly, I suppose you deny this passage:
// ... [cut]
1. If 0.999... = 1 holds, then it can be proved that the unique prime
factorization theorem of positive integers does not hold:
0.999... = 999.../1000... = 9*(111...)/(5*2)*... =1
<=> 3*3*(111...) = (5*2)*...
The integer to the left of the equal sign contains the prime number
3, but the integer to the right cannot contain 3... Prime
factorization is not unique.

...

-a-a-a-a-a-a-a Prop 2= Repeating Q+Q infinitely does not yield rational number.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a (precisely, positive rational number)

I dispute the validity of the proof of Prop 2.

No problem, you just need to prove it yourself.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Tue, 2026-01-27 at 09:21 +0100, David Brown wrote:

On 26/01/2026 21:34, wij wrote:

On Mon, 2026-01-26 at 21:07 +0100, David Brown wrote:

On 26/01/2026 16:51, wij wrote:

On Mon, 2026-01-26 at 01:25 +0100, Janis Papanagnou wrote:

(I probably regret answering to your post.)

On 2026-01-25 18:20, wij wrote:

You need to prove 4/33 exactly equal to 0.1212..., not approximation.

Is that all you want proven; a specific example?

This appears to be as trivial as the more general approach that James gave and that you (for reasons beyond me) don't accept (or don't see).

First
-a-a-a-a-a-a __
-a-a-a-a 0.12-a-a or-a-a 0.1212...

are just finite representations of real numbers; conventions. And 4/33
is an expression representing an operation, the division. You can just
do that computation (as you've certainly learned at school decades ago)
in individual steps, continuing each step with the remainder

-a-a-a-a 4/33 = 0-a-a-a-a => 0
-a-a-a-a 40/33 = 1-a-a-a => 0.1
-a-a-a-a remainder 7
-a-a-a-a 70/33 = 2-a-a-a => 0.12
-a-a-a-a remainder 4
-a-a-a-a 40/33 = 1-a-a-a and at this point you see that the _operations_ *repeat*

so the calculated decimals (1 and 2) will also repeat. And sensibly we
need a finite representation (see above) to express that.

-a-a-a-a Albert Einstein (for example) said: rCRDie Definition von Wahnsinn ist,
-a-a-a-a immer wieder das Gleiche zu tun und andere Ergebnisse zu erwartenrCL.

Are you expecting the sequence of decimals differing at some point?

If not you see that the number represented by the convention "0.1212..."
equals to the number calculated or expressed by "4/33".

Janis

Not quite sure what you mean.

https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
-a-a-a-a-a-a-a-a-a-a 3. 1/3 = 0.333... + non-zero-remainder (True identity. How to deny?)

How would you deny it, and call the cut-off 'equation' identity?

Have you ever heard of the concept of "limits" ?-a You might want to learn something about them before embarrassing yourself.

What do you know about the concept of "limits"? (You invented? Don't try to be
the next one, again. I remember the other expert in this forum has humiliated himself
once, not sure which one, if I can safely predict. And I ignored the other reply,
because it is too-aobvious, I leave as record)

No, I did not invent the concept of limits.-a Newton and Leibnitz were probably the first to use them, then Cauchy formalized them (if I
remember my history correctly).-a But I /learned/ about them - understood them, understood proofs about them, understood how to use them.

And more importantly, I learned how mathematics works.-a I learned how to read proofs, and how to write proofs.-a So I know writing down some statement and claiming "True identity.-a How to deny?" does not
constitute a proof.

But I suspect any rational argument will fall on deaf ears here.-a You
don't understand mathematics, and instead think that you alone have reinvented it and every other mathematician current and historical was wrong.-a I would love to be able to help you and cure your delusions, but
I have no idea how to do that.-a So I will just have to do as others
have, and ignore you.

Again, lots of talks to avoid you can prove what you say.
You humiliated yourself again, sorry.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Tue, 27 Jan 2026 16:31:47 -0000 (UTC), Waldek Hebisch wrote:

Actually, part that is needed here is ancient, due to Eudoksos.
Namely, real numebers a and b are equal if and only if comparing
them with rational numbers gives the same result.

They didnrCOt know about rCLrealrCY numbers back then. He was talking about rCLirrationalrCY numbers.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

David Brown <david.brown@hesbynett.no> writes:
[...]

But I suspect any rational argument will fall on deaf ears here. You
don't understand mathematics, and instead think that you alone have reinvented it and every other mathematician current and historical was
wrong. I would love to be able to help you and cure your delusions,
but I have no idea how to do that. So I will just have to do as
others have, and ignore you.

And a good time to start would have been *before* posting a
lengthy response.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

wij <wyniijj5@gmail.com> writes:

Prop 3: Recurring decimals are irrational numbers.

This proposition is already known to be false from
elementary (high school or earlier) algebra.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Tue, 2026-01-27 at 19:46 -0800, Tim Rentsch wrote:

wij <wyniijj5@gmail.com> writes:

Prop 3:-a Recurring decimals are irrational numbers.

This proposition is already known to be false from
elementary (high school or earlier) algebra.

Agree, but elementary (high school or earlier) algebra told a false proposition if Prop1, Prop2, Prop3 are true.
In case another blind again, ignore what is there and still blindly repeating something who does not understand.
If so, please post your proof (particularly about Prop1,Prop2,Prop3) or shut up.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 27/01/2026 23:52, Lawrence DrCOOliveiro wrote:

On Tue, 27 Jan 2026 16:31:47 -0000 (UTC), Waldek Hebisch wrote:

Actually, part that is needed here is ancient, due to Eudoksos.
Namely, real numebers a and b are equal if and only if comparing
them with rational numbers gives the same result.

They didnrCOt know about rCLrealrCY numbers back then. He was talking about rCLirrationalrCY numbers.

Indeed. They certainly knew about irrational numbers - according to
legend, the first Greek to prove that the square root of 2 is not
rational was killed for the heresy! But knowing that there are numbers
that are not rational is not enough to complete the reals.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-01-28 08:29, David Brown wrote:

On 27/01/2026 23:52, Lawrence DrCOOliveiro wrote:

On Tue, 27 Jan 2026 16:31:47 -0000 (UTC), Waldek Hebisch wrote:

Actually, part that is needed here is ancient, due to Eudoksos.
Namely, real numebers a and b are equal if and only if comparing
them with rational numbers gives the same result.

They didnrCOt know about rCLrealrCY numbers back then. He was talking about >> rCLirrationalrCY numbers.

Indeed.-a They certainly knew about irrational numbers - [...]

Erm.., no; as hinted upthread, not about "irrational *numbers*".
(They worked with geometric entities, relations between these.)
Modern texts sadly give a wrong impression, because they're not
using the ancient methods to explain the Greek's mathematics but
try to explain it with modern formulas, number systems, algebra.

The sqrt(2) sample, as before for squares, pentagons, etc., they
were looking for "gemeinsame Ma|f-Teilstrecke", as we call it here.
If you see (modern) expressions like "AC^2 : AB^2 = a^2 : b^2"
be aware that these terms and "operators" are just the algebraic
counterparts of the respective geometric entities the Greeks had
worked with. The graphical square ('^2') or relations (':'). And
terms like even/odd in commensurability expressions were defined
by "common unit subsections of lines" (not sure about the correct
English term).

(Have a look into Euklid's "Elements" to understand how they did
their ancient mathematics.[*] Also a few modern books try to use
more authentic representations; e.g. Nikiforowski/Freiman in the
introductory "Predecessors" chapter. But the examples there are
taken from Euklid's "Elements", so no wonder that it's authentic.)

Janis

[*] You'll find historic translations scanned and made available
online (e.g. at archive.org).

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

David Brown <david.brown@hesbynett.no> writes:

On 26/01/2026 21:34, wij wrote:

On Mon, 2026-01-26 at 21:07 +0100, David Brown wrote:

On 26/01/2026 16:51, wij wrote:

...

Not quite sure what you mean.

https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
aaaaaaaaa 3. 1/3 = 0.333... + non-zero-remainder (True
identity. How to deny?)

How would you deny it, and call the cut-off 'equation' identity?

Have you ever heard of the concept of "limits" ?a You might want to
learn something about them before embarrassing yourself.

What do you know about the concept of "limits"? (You invented? Don't try
to be
the next one, again. I remember the other expert in this forum has
humiliated himself
once, not sure which one, if I can safely predict. And I ignored the
other reply,
because it is tooaobvious, I leave as record)

No, I did not invent the concept of limits. Newton and Leibnitz were probably the first to use them, then Cauchy formalized them (if I remember
my history correctly). But I /learned/ about them - understood them, understood proofs about them, understood how to use them.

This is a crank topic that annoys me so I will allow myself one more
post in this wildly off-topic thread.

Limits are not needed to show that 1/3 = 0.333... exactly. All that's
needed is to know what 0.333... means. It means that, for every n, the
nth fractional digit it 3. Obviously, if someone denies this you just
have to give up, but if it is agreed that that is what the ... means
then it's simple so show that there is no n (in N) for which the nth
digit of 1/3 is not 3.
--
Ben.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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/Coll-proof-en.txt/download

The text is converted by google translate with modest modification from https://sourceforge.net/projects/cscall/files/MisFiles/Coll-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, nreeN<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, nreeN<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 nb|o, ab|o, bb|o 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:
nreU, nree, nrea, ..., nreo (n=nreU).
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...

ab|orea0, then bb|o and nb|o=ab|o+bb|o will increase infinitely, contradicting the
assumption that nb|o is cyclic. Therefore, ab|o=0 must hold during the cycle,

Regardless of your reasoning, it is clear (and easily proved) that as the cycle repeats, ab|o at the
same point in the cycle must decrease until it becomes zero. At this point ab|o 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 ab|o has to become zero, which seems to be what you want to claim.)

but the condition of ab|o=0 only exists in 1-4-2-1, ab|o=0 cannot cause the
non-1-4-2-1 cycle of nreU,nree,nrea,...,nreo.

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 ab|o=0 then bb|o <= 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 ab|o 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.

Prop: For any nreeN<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:

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;
}
}

Let n be odd and there be no `--a`, `++b` process. Assume that each odd
operation is paired with only one even operation (the actual ratio is 1.5
even operations, but 1.5 is a statistical value; the decisive inference
can only take the guaranteed value of 1). Then, at measurement point A,
we have:

areU = n-1
areo = (3*areoreireU)/2 = ... = (n-1)*(3/2)-urU+-|
breU = 1
breo = (3*breoreireU+1)/2 = ... = 2*(3/2)-urU+-| -1

This is just an approximation, not exact. It is not hard to get the exact value, since you seem to
know about geometric series...

areo/breo = (areoreireU)/(breoreireU) = ((n-1)*(3/2)-urU+-|)/(2*(3/2)-urU+-| -1)
= ... = (n-1)/(2-1/(3/2)-urU+-|)

Interim summary: areo/breo < areoreireU/breoreireU and lim{x->reR} areo/breo = (n-1)/2.

I agree with this value (n-1)/2, /given your assumptions/ :
- n odd
- no --a operations
- every odd op is followed by exactly one even op.

But those assumptions are impossible in a real example, and real sequences will include multiple
even ops and/or --a ops.

OTOH all sequences have ab|o/bb|o as non-increasing, so ab|o/bb|o will reach zero (and stay there) or
converge to some other limit value >= 0. In the latter case, you have not shown that that limit
value will be (n-1)/2. (Hopefully your argument below does not depend on the particular value to
which it converges?)

(After eight iterations, areo/breo is approximately 0.51. Actual iterations
may also include --a and ++b operations, so the actual value of areo/breo
will converge faster than the formula)

It must converge, but not necessarily to (n-1)/2 ...

After this point your argument seems to lose focus, and the notation is wrong!

Let r = a/b, then n/b = (a+b)/b = a/b+1 = r+1
=> b = (a+b)/(r+1)

ok this is simple algebra for any /specific/ iteration value of n,a,b. These values are changing as
we iterate...

Assuming the cop(n) iteration does not terminate, and m is one of the
number in the iteration sequence. Therefore, we can derive the
following:
=> b = m/(r+1)

True for m,b,r for /that specific iteration/.

=> The limit of r+1 = (m-1)/2 + 1 = (m+1)/2
=> b = (2*m)/(m+1) = 2/(1+1/m)
=> b = 2 (the limit of b. At least it is known that m will be a large
number)

No that's not right - you're mixing values of m,b,r with those for later iterations of cop() and
with limits. Also you're assuming r-->(m-1)/2. That was a specific result given your (impossible)
assumptions listed above. In general r /does/ converge, but might converge to some other number, or
become zero (in which case it also converges to zero so it's still true r converges). That is,
unless you find a way to fix your proof to prove otherwise...

To avoid confusing m,b,r as you've defined them with later iterations of cop(), best to call the
values for later iterations mb|o,bb|o,rb|o or similar. And assume rb|o-->R (e.g.).

So:
The limit of r+1 = R+1 // with possibility R=0
bb|o = mb|o/(rb|o+1)
lim bb|o = lim mb|o / (R+1)
... EXCEPT that you have not shown that mb|o converges, so that last line is nonsense - we only use
'lim' symbol when we the limits are known to exist...

Since there is a limit (the numerical value is not important),

??? a limit to what? rb|o ---> R, but it seems you're trying to argue bb|o converges? That's not
plausible. You can see this must be wrong, just from your earlier (overly) simplified sequence for
which you originally calculated R = (n-1)/2. In that calculation you wrote:

breo = (3*breoreireU+1)/2 = ... = 2*(3/2)-urU+-| -1

and it is clear that bb|o is growing in an unbounded fashionry, not converging to b=2. You've just
got muddled... Note: I don't necessarily agree with this breo formula - it looks to be only an
approximation, but I do agree with your areo/breo limit [with your given assumptions].

the
iteration involves an infinite number of iterations of --a, a will
inevitably become zero, so the iteration cannot fail to meet the
iteration termination contion.

That is also not right - once ab|o becomes zero, there will be /no more --a operations, so there can't
be infinitely many of them!

Regardless:

1. IF there are infinitely many iterations of --a, they can be interspersed
with a *= 3 operations, so it does not follow (just from what you've said)
that a /must/ become zero.
2. If a does become zero, it does not follow that the 1-4-2-1 loop has been
encountered, unless you have some argument to prove that. [This is
the same problem as with your earlier "no cycles" proof.]

If n is even, then repeating the even operation (a finite number of times)
cop(n) will yield an odd number without affecting the termination result
as stated above. Therefore, the proposition is proved.

..aside from fixing the problems above.


Mike.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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/Coll-proof-en.txt/download

The text is converted by google translate with modest modification from https://sourceforge.net/projects/cscall/files/MisFiles/Coll-proof-zh.txt/download
Reader might want to try different translator or different settings.

-----------------------------------------------------------------------------
Collatz function ::=

-a-a-a-a-a-a int cop(int n) {
-a-a-a-a-a-a-a-a if(n<=1) {
-a-a-a-a-a-a-a-a-a-a if(n<1) {
-a-a-a-a-a-a-a-a-a-a-a-a throw Error;
-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a return 1;-a-a-a-a // 1 is the iteration endpoint -a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a if(n%2) {
-a-a-a-a-a-a-a-a-a-a return 3*n+1; // Odd number rule
-a-a-a-a-a-a-a-a } else {
-a-a-a-a-a-a-a-a-a-a return n/2;-a-a // Even number rule
-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a
Collatz number: If an integer n, nreeN<1,+1>, after the cop iteration will -a-a-a-a eventually calculate to 1 (i.e., cop(...cop(n))=1), then n is a Collatz
-a-a-a-a number. Otherwise n is not a Collatz number. -a-a-a-a-a-a-a-a-a-a-a-a
Collatz Problem: For each integer n, nreeN<1,+1>, is n a Collatz number? IOW,
-a-a-a-a the question is equivalent to asking whether the following procedure rcop
-a-a-a-a terminates or not.
-a-a-a-a-a-a
-a-a-a-a-a-a void rcop(int n) {
-a-a-a-a-a-a-a-a for(;n!=1;) {
-a-a-a-a-a-a-a-a-a-a n=cop(n);
-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a }
-a-a-a-a-a-a
Prop: cop(n) iteration contains no cycle (except for the '1-4-2-1' cycle, since
-a-a-a-a-a 1 is the termination condition).

If you could prove just this much, you would become famous, at least amongst mathematicians!

-a-a Proof: n can be decomposed into n= a+b. rcop(n) can be rewritten as rcop2(n):
-a-a-a-a-a-a
-a-a-a-a-a-a void rcop2(int n) {
-a-a-a-a-a-a-a-a int a=n,b=0;
-a-a-a-a-a-a-a-a for(;a+b!=1;) { // a+b= n in the cop iterative process. -a-a-a-a-a-a-a-a-a-a if((a%2)!=0) {
-a-a-a-a-a-a-a-a-a-a-a-a --a; ++b;-a // Adjust a and b so that a remains even and the
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // following algorithm can be performed and remains
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // equivalent to cop(n) iteration.
-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a if((b%2)!=0) { // Equivalent to (a+b)%2 (because a is even).
-a-a-a-a-a-a-a-a-a-a-a-a a= 3*a;
-a-a-a-a-a-a-a-a-a-a-a-a b= 3*b+1;-a-a-a // 3*(a+b)+1= (3*a) +(3*b+1) -a-a-a-a-a-a-a-a-a-a } else {
-a-a-a-a-a-a-a-a-a-a-a-a a= a/2;
-a-a-a-a-a-a-a-a-a-a-a-a b= b/2;
-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a }

-a-a-a-a-a-a Let nb|o, ab|o, bb|o represent the values n,a, and b in the iteration.
-a-a-a-a-a-a Assume that the cop(n) iteration is cyclic. The cycle is a fixed-length
-a-a-a-a-a-a sequence, and the process must contain the operations 3x+1 and x/2 (and
-a-a-a-a-a-a the associated operations --a and ++b, unless n is a 2^x number, but such
-a-a-a-a-a-a numbers do not cycle). Let the cyclic sequence of n be: -a-a-a-a-a-a-a-a nreU, nree, nrea, ..., nreo (n=nreU).
-a-a-a-a-a-a Because --a and ++b are continuously interpolated during the cycle, if

I think "interpolated" is not the right word.-a Not sure exactly what is being claimed, but maybe
this doesn't matter - check my next comment...

-a-a-a-a-a-a ab|orea0, then bb|o and nb|o=ab|o+bb|o will increase infinitely, contradicting the
-a-a-a-a-a-a assumption that nb|o is cyclic. Therefore, ab|o=0 must hold during the cycle,

Regardless of your reasoning, it is clear (and easily proved) that as the cycle repeats, ab|o at the
same point in the cycle must decrease until it becomes zero.-a At this point ab|o remains zero for all
further i, and no more --a,++b operations occur.-a (So there can only be finitely many such ops, but
I agree ab|o has to become zero, which seems to be what you want to claim.)

-a-a-a-a-a-a but the condition of ab|o=0 only exists in 1-4-2-1, ab|o=0 cannot cause the
-a-a-a-a-a-a non-1-4-2-1 cycle of nreU,nree,nrea,...,nreo.

That doesn't follow from anything you've said so far.-a So this proof will not make you famous. Maybe
you can work on this and fill in the gap.-a You need an earlier "Prop: If ab|o=0 then bb|o <= 4" or
equivalent".-a 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 ab|o 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.

-a-a-a-a-a-a Therefore, we can conclude that cop(n) iterations are non-cyclic.

Prop: For any nreeN<1,+1>, the cop iteration operation terminates.
-a-a Proof: Since an odd number n will always become even immediately after the
-a-a-a-a-a-a cop iteration, it must undergo n/2 iterations. Therefore, we have an
-a-a-a-a-a-a equivalent rcop3:

-a-a-a-a-a-a void rcop3(int n) {
-a-a-a-a-a-a-a-a int a=n,b=0;
-a-a-a-a-a-a-a-a for(; a+b!=1;) {
-a-a-a-a-a-a-a-a-a-a if((a%2)!=0) {
-a-a-a-a-a-a-a-a-a-a-a-a --a; ++b;
-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a // a/b measure point A
-a-a-a-a-a-a-a-a-a-a if((b%2)!=0) {
-a-a-a-a-a-a-a-a-a-a-a-a a= 3*a;
-a-a-a-a-a-a-a-a-a-a-a-a b= 3*b+1;
-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a a= a/2;
-a-a-a-a-a-a-a-a-a-a b= b/2;
-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a }

-a-a-a-a-a-a Let n be odd and there be no `--a`, `++b` process. Assume that each odd
-a-a-a-a-a-a operation is paired with only one even operation (the actual ratio is 1.5
-a-a-a-a-a-a even operations, but 1.5 is a statistical value; the decisive inference
-a-a-a-a-a-a can only take the guaranteed value of 1). Then, at measurement point A,
-a-a-a-a-a-a we have:

-a-a-a-a-a-a areU = n-1
-a-a-a-a-a-a areo = (3*areoreireU)/2 = ... = (n-1)*(3/2)-urU+-| -a-a-a-a-a-a breU = 1
-a-a-a-a-a-a breo = (3*breoreireU+1)/2 = ... = 2*(3/2)-urU+-| -1

This is just an approximation, not exact.-a It is not hard to get the exact value, since you seem to
know about geometric series...

-a-a-a-a-a-a areo/breo = (areoreireU)/(breoreireU) = ((n-1)*(3/2)-urU+-|)/(2*(3/2)-urU+-| -1)
-a-a-a-a-a-a-a-a-a-a-a-a = ... = (n-1)/(2-1/(3/2)-urU+-|)

-a-a-a-a-a-a Interim summary: areo/breo < areoreireU/breoreireU and lim{x->reR} areo/breo = (n-1)/2.

I agree with this value (n-1)/2, /given your assumptions/ :
--a-a n odd
--a-a no --a operations
--a-a every odd op is followed by exactly one even op.

But those assumptions are impossible in a real example, and real sequences will include multiple
even ops and/or --a ops.

OTOH all sequences have ab|o/bb|o as non-increasing, so ab|o/bb|o will reach zero (and stay there) or
converge to some other limit value >= 0.-a In the latter case, you have not shown that that limit
value will be (n-1)/2.-a (Hopefully your argument below does not depend on the particular value to
which it converges?)

-a-a-a-a-a-a-a-a (After eight iterations, areo/breo is approximately 0.51. Actual iterations
-a-a-a-a-a-a-a-a-a may also include --a and ++b operations, so the actual value of areo/breo
-a-a-a-a-a-a-a-a-a will converge faster than the formula)

It must converge, but not necessarily to (n-1)/2 ...

After this point your argument seems to lose focus, and the notation is wrong!

-a-a-a-a-a-a Let r = a/b, then n/b = (a+b)/b = a/b+1 = r+1
-a-a-a-a-a-a => b = (a+b)/(r+1)

ok this is simple algebra for any /specific/ iteration value of n,a,b.-a These values are changing as
we iterate...

-a-a-a-a-a-a Assuming the cop(n) iteration does not terminate, and m is one of the
-a-a-a-a-a-a number in the iteration sequence. Therefore, we can derive the -a-a-a-a-a-a following:
-a-a-a-a-a-a => b = m/(r+1)

True for m,b,r for /that specific iteration/.

-a-a-a-a-a-a => The limit of r+1 = (m-1)/2 + 1 = (m+1)/2
-a-a-a-a-a-a => b = (2*m)/(m+1) = 2/(1+1/m)
-a-a-a-a-a-a => b = 2 (the limit of b. At least it is known that m will be a large
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a number)

No that's not right - you're mixing values of m,b,r with those for later iterations of cop() and
with limits.-a Also you're assuming r-->(m-1)/2.-a That was a specific result given your (impossible)
assumptions listed above.-a In general r /does/ converge, but might converge to some other number, or
become zero (in which case it also converges to zero so it's still true r converges).-a That is,
unless you find a way to fix your proof to prove otherwise...

To avoid confusing m,b,r as you've defined them with later iterations of cop(), best to call the
values for later iterations mb|o,bb|o,rb|o or similar.-a And assume rb|o-->R (e.g.).

So:
-a-a-a The limit of r+1 = R+1-a-a-a-a-a-a // with possibility R=0
-a-a-a bb|o = mb|o/(rb|o+1)
-a-a-a lim bb|o = lim mb|o / (R+1)
... EXCEPT that you have not shown that mb|o converges, so that last line is nonsense - we only use
'lim' symbol when we the limits are known to exist...

-a-a-a-a-a-a Since there is a limit (the numerical value is not important),

??? a limit to what?-a rb|o ---> R, but it seems you're trying to argue bb|o converges?-a That's not
plausible.-a You can see this must be wrong, just from your earlier (overly) simplified sequence for
which you originally calculated R = (n-1)/2. In that calculation you wrote:

-a-a-a-a breo = (3*breoreireU+1)/2 = ... = 2*(3/2)-urU+-| -1

and it is clear that bb|o is growing in an unbounded fashionry, not converging to b=2.-a You've just
got muddled...-a Note: I don't necessarily agree with this breo formula - it looks to be only an
approximation, but I do agree with your areo/breo limit [with your given assumptions].

-a-a-a-a-a-a the
-a-a-a-a-a-a iteration involves an infinite number of iterations of --a, a will
-a-a-a-a-a-a inevitably become zero, so the iteration cannot fail to meet the
-a-a-a-a-a-a iteration termination contion.

That is also not right - once ab|o becomes zero, there will be /no more --a operations, so there can't
be infinitely many of them!

Regardless:

1.-a IF there are infinitely many iterations of --a, they can be interspersed -a-a-a-a with a *= 3 operations, so it does not follow (just from what you've said)
-a-a-a-a that a /must/ become zero.
2.-a If a does become zero, it does not follow that the 1-4-2-1 loop has been -a-a-a-a encountered, unless you have some argument to prove that.-a [This is -a-a-a-a the same problem as with your earlier "no cycles" proof.]

-a-a-a-a-a-a If n is even, then repeating the even operation (a finite number of times)
-a-a-a-a-a-a cop(n) will yield an odd number without affecting the termination result
-a-a-a-a-a-a as stated above. Therefore, the proposition is proved.

..aside from fixing the problems above.

Mike.

I agree with many point of your criticism, it is helpful.
Since your comments are on the original script, I will post the updated version to avoid
unnecessary reply.
--- [quote from the finalized version]
Prop: ....[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;
}
}
The following proof demonstrates:
1. The ratio a/b is decreasing.
2. b has limit.
3. a must decrease to below b because of the above reasons.
4. Done, n=a+b has limit (cop(n) is known to terminate for n<2-|rU| at
least).
Let n be odd and there be no `--a`, `++b` process. Assume that each odd
operation is paired with only one even operation, then, at measurement
point A, we have:
areU = n-1
areo = (3*areoreireU)/2 = ... = (n-1)*(3/2)-urU+-|
breU = 1
breo = (3*breoreireU+1)/2 = ... = 2*(3/2)-urU+-| -1
areo/breo = (areoreireU)/(breoreireU) = ((n-1)*(3/2)-urU+-|)/(2*(3/2)-urU+-| -1)
= ... = (n-1)/(2-1/(3/2)-urU+-|)
Interim summary: areo/breo < areoreireU/breoreireU and lim{x->reR} areo/breo = (n-1)/2.
(After eight iterations, areo/breo is approximately 0.51. Actual iterations
may also include --a and ++b operations, so the actual value of areo/breo
will converge faster than the formula)
Let r = a/b, then n/b = (a+b)/b = a/b+1 = r+1
=> b = (a+b)/(r+1) = n/(r+1)
After sufficient iterations:
=> The limit of r+1 = (n-1)/2 + 1 = (n+1)/2
=> b = (2*n)/(n+1) = 2/(1+1/n)
=> b = 2 (the limit of b. it is known that n is a large number)
Since b has limit (the numerical value is not important), the iteration
involves an infinite number of iterations of --a, a will inevitably become
zero, so the iteration cannot fail to meet the iteration termination
condition.
----------------------
1. a/b ratio (formula) is a lower bound estimate as stated. In the real cases,
it decreases faster.
2. In the iteration, even ops does not change a/b ratio. Ops --a,++b only makes-a
the ratio a/b-amore decreasing.
3. The proof only needs to show there is a limit. What value a/b converges does-a
not important.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Mon, 2026-01-26 at 01:20 +0800, wij wrote:

On Sun, 2026-01-25 at 11:25 -0500, James Kuyper wrote:

On Sun, 25 Jan 2026 13:28:31 +0800, wij wrote:

On Sat, 2026-01-24 at 23:06 -0500, James Kuyper wrote:

This generalizes to work with any recurring decimal. When the recurrence is n digits long (in the above example, n=2), just
multiply by 10^n.

Such arithmetic is called approximation ...

So what is, in your opinion, the exact representation of 4/33 as a
decimal fraction? Marking it as infinitely repeating means that it is
not in any sense an approximation - it is exact.

You need to prove 4/33 exactly equal to 0.1212..., not approximation.
But,...

-aIf it were an
approximation, there would be a finite difference between 4/33 and 0.1212.... How big is that difference? No matter how small of a finite difference you might think it has, going to infinitely many decimal
digits makes the actual difference smaller than that.

Yes, the same as infinity/infinitesimal.

Keep in mind that, in the absence of specification to the contrary,
we're talking about the standard real number system, not one of those alternatives that extends the real number system by adding
infinitesimals, such as the surreals or the hyperreals.

True-aif you are not referring to the current 'standard real number system'. What else? (doesn't sound to contain much information)

The standard real number system is not a constant thing, it will correct itself. Not even religion is constant.

To be explicitly 'C' related, I remember people talking about what INF-a should mean (an option may be merely for signifying overflow), I would suggest reserve the bit, not mixing with other meaning.

Prop2 had rewrote (easier for older high schools to understand). https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
....[cut]
Prop 2: raU+raU=raU (the sum of a rational number and a rational number is still a
rational number). The statement holds only for a finite number of
addition steps.
Proof: The addition of positive rational number q is strictly increasing. The
result is either 'divergent' or 'convergent'. Both contain infinitely
long 'natural number' (otherwise they cannot be called 'convergent' or
'divergent').
----------
Therefore, real number contains infinity (so infinitesimal).
So, INFINITY is another real number, don't mix it with something else.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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/Coll-proof-en.txt/download

The text is converted by google translate with modest modification from https://sourceforge.net/projects/cscall/files/MisFiles/Coll-proof-zh.txt/download
Reader might want to try different translator or different settings.

-----------------------------------------------------------------------------
Collatz function ::=

-a-a-a-a-a-a-a int cop(int n) {
-a-a-a-a-a-a-a-a-a if(n<=1) {
-a-a-a-a-a-a-a-a-a-a-a if(n<1) {
-a-a-a-a-a-a-a-a-a-a-a-a-a throw Error;
-a-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a-a return 1;-a-a-a-a // 1 is the iteration endpoint -a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a if(n%2) {
-a-a-a-a-a-a-a-a-a-a-a return 3*n+1; // Odd number rule -a-a-a-a-a-a-a-a-a } else {
-a-a-a-a-a-a-a-a-a-a-a return n/2;-a-a // Even number rule -a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a-a
Collatz number: If an integer n, nreeN<1,+1>, after the cop iteration will
-a-a-a-a-a eventually calculate to 1 (i.e., cop(...cop(n))=1), then n is a Collatz
-a-a-a-a-a number. Otherwise n is not a Collatz number. -a-a-a-a-a-a-a-a-a-a-a-a-a
Collatz Problem: For each integer n, nreeN<1,+1>, is n a Collatz number? IOW,
-a-a-a-a-a the question is equivalent to asking whether the following procedure rcop
-a-a-a-a-a terminates or not.
-a-a-a-a-a-a-a
-a-a-a-a-a-a-a void rcop(int n) {
-a-a-a-a-a-a-a-a-a for(;n!=1;) {
-a-a-a-a-a-a-a-a-a-a-a n=cop(n);
-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a
Prop: cop(n) iteration contains no cycle (except for the '1-4-2-1' cycle, since
-a-a-a-a-a-a 1 is the termination condition).

If you could prove just this much, you would become famous, at least amongst mathematicians!

-a-a-a Proof: n can be decomposed into n= a+b. rcop(n) can be rewritten as rcop2(n):
-a-a-a-a-a-a-a
-a-a-a-a-a-a-a void rcop2(int n) {
-a-a-a-a-a-a-a-a-a int a=n,b=0;
-a-a-a-a-a-a-a-a-a for(;a+b!=1;) { // a+b= n in the cop iterative process.
-a-a-a-a-a-a-a-a-a-a-a if((a%2)!=0) {
-a-a-a-a-a-a-a-a-a-a-a-a-a --a; ++b;-a // Adjust a and b so that a remains even and the
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // following algorithm can be performed and remains
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // equivalent to cop(n) iteration.
-a-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a-a if((b%2)!=0) { // Equivalent to (a+b)%2 (because a is even).
-a-a-a-a-a-a-a-a-a-a-a-a-a a= 3*a;
-a-a-a-a-a-a-a-a-a-a-a-a-a b= 3*b+1;-a-a-a // 3*(a+b)+1= (3*a) +(3*b+1) -a-a-a-a-a-a-a-a-a-a-a } else {
-a-a-a-a-a-a-a-a-a-a-a-a-a a= a/2;
-a-a-a-a-a-a-a-a-a-a-a-a-a b= b/2;
-a-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a }

-a-a-a-a-a-a-a Let nb|o, ab|o, bb|o represent the values n,a, and b in the iteration.
-a-a-a-a-a-a-a Assume that the cop(n) iteration is cyclic. The cycle is a fixed-length
-a-a-a-a-a-a-a sequence, and the process must contain the operations 3x+1 and x/2 (and
-a-a-a-a-a-a-a the associated operations --a and ++b, unless n is a 2^x number, but such
-a-a-a-a-a-a-a numbers do not cycle). Let the cyclic sequence of n be: -a-a-a-a-a-a-a-a-a nreU, nree, nrea, ..., nreo (n=nreU).
-a-a-a-a-a-a-a Because --a and ++b are continuously interpolated during the cycle, if

I think "interpolated" is not the right word.-a Not sure exactly what is being claimed, but maybe
this doesn't matter - check my next comment...

-a-a-a-a-a-a-a ab|orea0, then bb|o and nb|o=ab|o+bb|o will increase infinitely, contradicting the
-a-a-a-a-a-a-a assumption that nb|o is cyclic. Therefore, ab|o=0 must hold during the cycle,

Regardless of your reasoning, it is clear (and easily proved) that as the cycle repeats, ab|o at
the
same point in the cycle must decrease until it becomes zero.-a At this point ab|o remains zero for
all
further i, and no more --a,++b operations occur.-a (So there can only be finitely many such ops,
but
I agree ab|o has to become zero, which seems to be what you want to claim.)

-a-a-a-a-a-a-a but the condition of ab|o=0 only exists in 1-4-2-1, ab|o=0 cannot cause the
-a-a-a-a-a-a-a non-1-4-2-1 cycle of nreU,nree,nrea,...,nreo.

That doesn't follow from anything you've said so far.-a So this proof will not make you famous.
Maybe
you can work on this and fill in the gap.-a You need an earlier "Prop: If ab|o=0 then bb|o <= 4" or
equivalent".-a 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 ab|o 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.

-a-a-a-a-a-a-a Therefore, we can conclude that cop(n) iterations are non-cyclic.

Prop: For any nreeN<1,+1>, the cop iteration operation terminates. -a-a-a Proof: Since an odd number n will always become even immediately after the
-a-a-a-a-a-a-a cop iteration, it must undergo n/2 iterations. Therefore, we have an
-a-a-a-a-a-a-a equivalent rcop3:

-a-a-a-a-a-a-a void rcop3(int n) {
-a-a-a-a-a-a-a-a-a int a=n,b=0;
-a-a-a-a-a-a-a-a-a for(; a+b!=1;) {
-a-a-a-a-a-a-a-a-a-a-a if((a%2)!=0) {
-a-a-a-a-a-a-a-a-a-a-a-a-a --a; ++b;
-a-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a-a // a/b measure point A
-a-a-a-a-a-a-a-a-a-a-a if((b%2)!=0) {
-a-a-a-a-a-a-a-a-a-a-a-a-a a= 3*a;
-a-a-a-a-a-a-a-a-a-a-a-a-a b= 3*b+1;
-a-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a-a a= a/2;
-a-a-a-a-a-a-a-a-a-a-a b= b/2;
-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a }

-a-a-a-a-a-a-a Let n be odd and there be no `--a`, `++b` process. Assume that each odd
-a-a-a-a-a-a-a operation is paired with only one even operation (the actual ratio is 1.5
-a-a-a-a-a-a-a even operations, but 1.5 is a statistical value; the decisive inference
-a-a-a-a-a-a-a can only take the guaranteed value of 1). Then, at measurement point A,
-a-a-a-a-a-a-a we have:

-a-a-a-a-a-a-a areU = n-1
-a-a-a-a-a-a-a areo = (3*areoreireU)/2 = ... = (n-1)*(3/2)-urU+-| -a-a-a-a-a-a-a breU = 1
-a-a-a-a-a-a-a breo = (3*breoreireU+1)/2 = ... = 2*(3/2)-urU+-| -1

This is just an approximation, not exact.-a It is not hard to get the exact value, since you seem
to
know about geometric series...

-a-a-a-a-a-a-a areo/breo = (areoreireU)/(breoreireU) = ((n-1)*(3/2)-urU+-|)/(2*(3/2)-urU+-| -1)
-a-a-a-a-a-a-a-a-a-a-a-a-a = ... = (n-1)/(2-1/(3/2)-urU+-|)

-a-a-a-a-a-a-a Interim summary: areo/breo < areoreireU/breoreireU and lim{x->reR} areo/breo = (n-1)/2.

I agree with this value (n-1)/2, /given your assumptions/ :
--a-a n odd
--a-a no --a operations
--a-a every odd op is followed by exactly one even op.

But those assumptions are impossible in a real example, and real sequences will include multiple
even ops and/or --a ops.

OTOH all sequences have ab|o/bb|o as non-increasing, so ab|o/bb|o will reach zero (and stay there) or
converge to some other limit value >= 0.-a In the latter case, you have not shown that that limit
value will be (n-1)/2.-a (Hopefully your argument below does not depend on the particular value
to
which it converges?)

-a-a-a-a-a-a-a-a-a (After eight iterations, areo/breo is approximately 0.51. Actual iterations
-a-a-a-a-a-a-a-a-a-a may also include --a and ++b operations, so the actual value of areo/breo
-a-a-a-a-a-a-a-a-a-a will converge faster than the formula)

It must converge, but not necessarily to (n-1)/2 ...

After this point your argument seems to lose focus, and the notation is wrong!

-a-a-a-a-a-a-a Let r = a/b, then n/b = (a+b)/b = a/b+1 = r+1 -a-a-a-a-a-a-a => b = (a+b)/(r+1)

ok this is simple algebra for any /specific/ iteration value of n,a,b.-a These values are
changing as
we iterate...

-a-a-a-a-a-a-a Assuming the cop(n) iteration does not terminate, and m is one of the
-a-a-a-a-a-a-a number in the iteration sequence. Therefore, we can derive the
-a-a-a-a-a-a-a following:
-a-a-a-a-a-a-a => b = m/(r+1)

True for m,b,r for /that specific iteration/.

-a-a-a-a-a-a-a => The limit of r+1 = (m-1)/2 + 1 = (m+1)/2 -a-a-a-a-a-a-a => b = (2*m)/(m+1) = 2/(1+1/m)
-a-a-a-a-a-a-a => b = 2 (the limit of b. At least it is known that m will be a large
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a number)

No that's not right - you're mixing values of m,b,r with those for later iterations of cop() and
with limits.-a Also you're assuming r-->(m-1)/2.-a That was a specific result given your
(impossible)
assumptions listed above.-a In general r /does/ converge, but might converge to some other
number, or
become zero (in which case it also converges to zero so it's still true r converges).-a That is,
unless you find a way to fix your proof to prove otherwise...

To avoid confusing m,b,r as you've defined them with later iterations of cop(), best to call the
values for later iterations mb|o,bb|o,rb|o or similar.-a And assume rb|o-->R (e.g.).

So:
-a-a-a-a The limit of r+1 = R+1-a-a-a-a-a-a // with possibility R=0 -a-a-a-a bb|o = mb|o/(rb|o+1)
-a-a-a-a lim bb|o = lim mb|o / (R+1)
... EXCEPT that you have not shown that mb|o converges, so that last line is nonsense - we only
use
'lim' symbol when we the limits are known to exist...

-a-a-a-a-a-a-a Since there is a limit (the numerical value is not important),

??? a limit to what?-a rb|o ---> R, but it seems you're trying to argue bb|o converges?-a That's not
plausible.-a You can see this must be wrong, just from your earlier (overly) simplified sequence
for
which you originally calculated R = (n-1)/2. In that calculation you wrote:

-a-a-a-a-a breo = (3*breoreireU+1)/2 = ... = 2*(3/2)-urU+-| -1

and it is clear that bb|o is growing in an unbounded fashionry, not converging to b=2.-a You've
just
got muddled...-a Note: I don't necessarily agree with this breo formula - it looks to be only an
approximation, but I do agree with your areo/breo limit [with your given assumptions].

-a-a-a-a-a-a-a the
-a-a-a-a-a-a-a iteration involves an infinite number of iterations of --a, a will
-a-a-a-a-a-a-a inevitably become zero, so the iteration cannot fail to meet the
-a-a-a-a-a-a-a iteration termination contion.

That is also not right - once ab|o becomes zero, there will be /no more --a operations, so there
can't
be infinitely many of them!

Regardless:

1.-a IF there are infinitely many iterations of --a, they can be interspersed
-a-a-a-a-a with a *= 3 operations, so it does not follow (just from what you've said)
-a-a-a-a-a that a /must/ become zero.
2.-a If a does become zero, it does not follow that the 1-4-2-1 loop has been
-a-a-a-a-a encountered, unless you have some argument to prove that.-a [This is
-a-a-a-a-a the same problem as with your earlier "no cycles" proof.]

-a-a-a-a-a-a-a If n is even, then repeating the even operation (a finite number of times)
-a-a-a-a-a-a-a cop(n) will yield an odd number without affecting the termination result
-a-a-a-a-a-a-a as stated above. Therefore, the proposition is proved.

..aside from fixing the problems above.

Mike.

I agree with many point of your criticism, it is helpful.
Since your comments are on the original script, I will post the updated version to avoid
unnecessary reply.

--- [quote from the finalized version]
Prop:-a-a ....[cut]
-a-a-a-a-a-a void rcop3(int n) {
-a-a-a-a-a-a-a-a int a=n,b=0;
-a-a-a-a-a-a-a-a for(; a+b!=1;) {
-a-a-a-a-a-a-a-a-a-a if((a%2)!=0) {
-a-a-a-a-a-a-a-a-a-a-a-a --a; ++b;
-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a // a/b measure point A
-a-a-a-a-a-a-a-a-a-a if((b%2)!=0) {
-a-a-a-a-a-a-a-a-a-a-a-a a= 3*a;
-a-a-a-a-a-a-a-a-a-a-a-a b= 3*b+1;
-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a a= a/2;
-a-a-a-a-a-a-a-a-a-a b= b/2;
-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a }

-a-a-a-a-a-a The following proof demonstrates:
-a-a-a-a-a-a-a-a 1. The ratio a/b is decreasing.
-a-a-a-a-a-a-a-a 2. b has limit.
-a-a-a-a-a-a-a-a 3. a must decrease to below b because of the above reasons.
-a-a-a-a-a-a-a-a 4. Done, n=a+b has limit (cop(n) is known to terminate for n<2-|rU| at
-a-a-a-a-a-a-a-a-a-a-a least).

-a-a-a-a-a-a Let n be odd and there be no `--a`, `++b` process. Assume that each odd
-a-a-a-a-a-a operation is paired with only one even operation, then, at measurement
-a-a-a-a-a-a point A, we have:

-a-a-a-a-a-a areU = n-1
-a-a-a-a-a-a areo = (3*areoreireU)/2 = ... = (n-1)*(3/2)-urU+-| -a-a-a-a-a-a breU = 1
-a-a-a-a-a-a breo = (3*breoreireU+1)/2 = ... = 2*(3/2)-urU+-| -1 -a-a-a-a-a-a areo/breo = (areoreireU)/(breoreireU) = ((n-1)*(3/2)-urU+-|)/(2*(3/2)-urU+-| -1)
-a-a-a-a-a-a-a-a-a-a-a-a = ... = (n-1)/(2-1/(3/2)-urU+-|)

-a-a-a-a-a-a Interim summary: areo/breo < areoreireU/breoreireU and lim{x->reR} areo/breo = (n-1)/2.
-a-a-a-a-a-a-a-a (After eight iterations, areo/breo is approximately 0.51. Actual iterations
-a-a-a-a-a-a-a-a-a may also include --a and ++b operations, so the actual value of areo/breo
-a-a-a-a-a-a-a-a-a will converge faster than the formula)

-a-a-a-a-a-a Let r = a/b, then n/b = (a+b)/b = a/b+1 = r+1
-a-a-a-a-a-a => b = (a+b)/(r+1) = n/(r+1)
-a-a-a-a-a-a After sufficient iterations:
-a-a-a-a-a-a => The limit of r+1 = (n-1)/2 + 1 = (n+1)/2
-a-a-a-a-a-a => b = (2*n)/(n+1) = 2/(1+1/n)
-a-a-a-a-a-a => b = 2 (the limit of b. it is known that n is a large number)

-a-a-a-a-a-a Since b has limit (the numerical value is not important), the iteration
-a-a-a-a-a-a involves an infinite number of iterations of --a, a will inevitably become
-a-a-a-a-a-a zero, so the iteration cannot fail to meet the iteration termination
-a-a-a-a-a-a condition.
----------------------

1. a/b ratio (formula) is a lower bound estimate as stated. In the real cases,
-a-a-a it decreases faster.
2. In the iteration, even ops does not change a/b ratio. Ops --a,++b only makes
-a-a-a the ratio a/b-amore decreasing.
3. The proof only needs to show there is a limit. What value a/b converges does
-a-a-a not important.

So we agree a/b converges, but the updates above do not address any of the problems raised in my
previous post...

Mike.

Confirmed, thanks. "b has limit" is flawed.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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/Coll-proof-en.txt/download

The text is converted by google translate with modest modification from >>>>> https://sourceforge.net/projects/cscall/files/MisFiles/Coll-proof-zh.txt/download
Reader might want to try different translator or different settings. >>>>>
-----------------------------------------------------------------------------
Collatz function ::=

-a-a-a-a-a-a-a int cop(int n) {
-a-a-a-a-a-a-a-a-a if(n<=1) {
-a-a-a-a-a-a-a-a-a-a-a if(n<1) {
-a-a-a-a-a-a-a-a-a-a-a-a-a throw Error;
-a-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a-a return 1;-a-a-a-a // 1 is the iteration endpoint >>>>> -a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a if(n%2) {
-a-a-a-a-a-a-a-a-a-a-a return 3*n+1; // Odd number rule
-a-a-a-a-a-a-a-a-a } else {
-a-a-a-a-a-a-a-a-a-a-a return n/2;-a-a // Even number rule
-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a }

Collatz number: If an integer n, nreeN<1,+1>, after the cop iteration will
-a-a-a-a-a eventually calculate to 1 (i.e., cop(...cop(n))=1), then n is a Collatz
-a-a-a-a-a number. Otherwise n is not a Collatz number.

Collatz Problem: For each integer n, nreeN<1,+1>, is n a Collatz number? IOW,
-a-a-a-a-a the question is equivalent to asking whether the following procedure rcop
-a-a-a-a-a terminates or not.

-a-a-a-a-a-a-a void rcop(int n) {
-a-a-a-a-a-a-a-a-a for(;n!=1;) {
-a-a-a-a-a-a-a-a-a-a-a n=cop(n);
-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a }

Prop: cop(n) iteration contains no cycle (except for the '1-4-2-1' cycle, since
-a-a-a-a-a-a 1 is the termination condition).

If you could prove just this much, you would become famous, at least amongst mathematicians!

-a-a-a Proof: n can be decomposed into n= a+b. rcop(n) can be rewritten as rcop2(n):

-a-a-a-a-a-a-a void rcop2(int n) {
-a-a-a-a-a-a-a-a-a int a=n,b=0;
-a-a-a-a-a-a-a-a-a for(;a+b!=1;) { // a+b= n in the cop iterative process.
-a-a-a-a-a-a-a-a-a-a-a if((a%2)!=0) {
-a-a-a-a-a-a-a-a-a-a-a-a-a --a; ++b;-a // Adjust a and b so that a remains even and the
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // following algorithm can be performed and remains
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a // equivalent to cop(n) iteration.
-a-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a-a if((b%2)!=0) { // Equivalent to (a+b)%2 (because a is even).
-a-a-a-a-a-a-a-a-a-a-a-a-a a= 3*a;
-a-a-a-a-a-a-a-a-a-a-a-a-a b= 3*b+1;-a-a-a // 3*(a+b)+1= (3*a) +(3*b+1) >>>>> -a-a-a-a-a-a-a-a-a-a-a } else {
-a-a-a-a-a-a-a-a-a-a-a-a-a a= a/2;
-a-a-a-a-a-a-a-a-a-a-a-a-a b= b/2;
-a-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a }

-a-a-a-a-a-a-a Let nb|o, ab|o, bb|o represent the values n,a, and b in the iteration.
-a-a-a-a-a-a-a Assume that the cop(n) iteration is cyclic. The cycle is a fixed-length
-a-a-a-a-a-a-a sequence, and the process must contain the operations 3x+1 and x/2 (and
-a-a-a-a-a-a-a the associated operations --a and ++b, unless n is a 2^x number, but such
-a-a-a-a-a-a-a numbers do not cycle). Let the cyclic sequence of n be: >>>>> -a-a-a-a-a-a-a-a-a nreU, nree, nrea, ..., nreo (n=nreU).
-a-a-a-a-a-a-a Because --a and ++b are continuously interpolated during the cycle, if

I think "interpolated" is not the right word.-a Not sure exactly what is being claimed, but maybe
this doesn't matter - check my next comment...

-a-a-a-a-a-a-a ab|orea0, then bb|o and nb|o=ab|o+bb|o will increase infinitely, contradicting the
-a-a-a-a-a-a-a assumption that nb|o is cyclic. Therefore, ab|o=0 must hold during the cycle,

Regardless of your reasoning, it is clear (and easily proved) that as the cycle repeats, ab|o at
the
same point in the cycle must decrease until it becomes zero.-a At this point ab|o remains zero for
all
further i, and no more --a,++b operations occur.-a (So there can only be finitely many such ops,
but
I agree ab|o has to become zero, which seems to be what you want to claim.)

-a-a-a-a-a-a-a but the condition of ab|o=0 only exists in 1-4-2-1, ab|o=0 cannot cause the
-a-a-a-a-a-a-a non-1-4-2-1 cycle of nreU,nree,nrea,...,nreo.

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 ab|o=0 then bb|o <= 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 ab|o 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.-a So this proof will not make you famous.
Maybe
you can work on this and fill in the gap.-a You need an earlier "Prop: If ab|o=0 then bb|o <= 4" or
equivalent".-a 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 ab|o 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.

-a-a-a-a-a-a-a 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 nreeN<1,+1>, the cop iteration operation terminates.
-a-a-a Proof: Since an odd number n will always become even immediately after the
-a-a-a-a-a-a-a cop iteration, it must undergo n/2 iterations. Therefore, we have an
-a-a-a-a-a-a-a equivalent rcop3:

-a-a-a-a-a-a-a void rcop3(int n) {
-a-a-a-a-a-a-a-a-a int a=n,b=0;
-a-a-a-a-a-a-a-a-a for(; a+b!=1;) {
-a-a-a-a-a-a-a-a-a-a-a if((a%2)!=0) {
-a-a-a-a-a-a-a-a-a-a-a-a-a --a; ++b;
-a-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a-a // a/b measure point A
-a-a-a-a-a-a-a-a-a-a-a if((b%2)!=0) {
-a-a-a-a-a-a-a-a-a-a-a-a-a a= 3*a;
-a-a-a-a-a-a-a-a-a-a-a-a-a b= 3*b+1;
-a-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a-a a= a/2;
-a-a-a-a-a-a-a-a-a-a-a b= b/2;
-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a }

-a-a-a-a-a-a-a Let n be odd and there be no `--a`, `++b` process. Assume that each odd
-a-a-a-a-a-a-a operation is paired with only one even operation (the actual ratio is 1.5
-a-a-a-a-a-a-a even operations, but 1.5 is a statistical value; the decisive inference
-a-a-a-a-a-a-a can only take the guaranteed value of 1). Then, at measurement point A,
-a-a-a-a-a-a-a we have:

-a-a-a-a-a-a-a areU = n-1
-a-a-a-a-a-a-a areo = (3*areoreireU)/2 = ... = (n-1)*(3/2)-urU+-|
-a-a-a-a-a-a-a breU = 1
-a-a-a-a-a-a-a breo = (3*breoreireU+1)/2 = ... = 2*(3/2)-urU+-| -1

This is just an approximation, not exact.-a It is not hard to get the exact value, since you seem
to
know about geometric series...

-a-a-a-a-a-a-a areo/breo = (areoreireU)/(breoreireU) = ((n-1)*(3/2)-urU+-|)/(2*(3/2)-urU+-| -1)
-a-a-a-a-a-a-a-a-a-a-a-a-a = ... = (n-1)/(2-1/(3/2)-urU+-|)

-a-a-a-a-a-a-a Interim summary: areo/breo < areoreireU/breoreireU and lim{x->reR} areo/breo = (n-1)/2.

I agree with this value (n-1)/2, /given your assumptions/ :
--a-a n odd
--a-a no --a operations
--a-a every odd op is followed by exactly one even op.

But those assumptions are impossible in a real example, and real sequences will include multiple
even ops and/or --a ops.

OTOH all sequences have ab|o/bb|o as non-increasing, so ab|o/bb|o will reach zero (and stay there) or
converge to some other limit value >= 0.-a In the latter case, you have not shown that that limit
value will be (n-1)/2.-a (Hopefully your argument below does not depend on the particular value
to
which it converges?)

-a-a-a-a-a-a-a-a-a (After eight iterations, areo/breo is approximately 0.51. Actual iterations
-a-a-a-a-a-a-a-a-a-a may also include --a and ++b operations, so the actual value of areo/breo
-a-a-a-a-a-a-a-a-a-a will converge faster than the formula)

It must converge, but not necessarily to (n-1)/2 ...

After this point your argument seems to lose focus, and the notation is wrong!

-a-a-a-a-a-a-a Let r = a/b, then n/b = (a+b)/b = a/b+1 = r+1
-a-a-a-a-a-a-a => b = (a+b)/(r+1)

ok this is simple algebra for any /specific/ iteration value of n,a,b.-a These values are
changing as
we iterate...

-a-a-a-a-a-a-a Assuming the cop(n) iteration does not terminate, and m is one of the
-a-a-a-a-a-a-a number in the iteration sequence. Therefore, we can derive the
-a-a-a-a-a-a-a following:
-a-a-a-a-a-a-a => b = m/(r+1)

True for m,b,r for /that specific iteration/.

-a-a-a-a-a-a-a => The limit of r+1 = (m-1)/2 + 1 = (m+1)/2
-a-a-a-a-a-a-a => b = (2*m)/(m+1) = 2/(1+1/m)
-a-a-a-a-a-a-a => b = 2 (the limit of b. At least it is known that m will be a large
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a number)

No that's not right - you're mixing values of m,b,r with those for later iterations of cop() and
with limits.-a Also you're assuming r-->(m-1)/2.-a That was a specific result given your
(impossible)
assumptions listed above.-a In general r /does/ converge, but might converge to some other
number, or
become zero (in which case it also converges to zero so it's still true r converges).-a That is,
unless you find a way to fix your proof to prove otherwise...

To avoid confusing m,b,r as you've defined them with later iterations of cop(), best to call the
values for later iterations mb|o,bb|o,rb|o or similar.-a And assume rb|o-->R (e.g.).

So:
-a-a-a-a The limit of r+1 = R+1-a-a-a-a-a-a // with possibility R=0
-a-a-a-a bb|o = mb|o/(rb|o+1)
-a-a-a-a lim bb|o = lim mb|o / (R+1)
... EXCEPT that you have not shown that mb|o converges, so that last line is nonsense - we only
use
'lim' symbol when we the limits are known to exist...

-a-a-a-a-a-a-a Since there is a limit (the numerical value is not important),

??? a limit to what?-a rb|o ---> R, but it seems you're trying to argue bb|o converges?-a That's not
plausible.-a You can see this must be wrong, just from your earlier (overly) simplified sequence
for
which you originally calculated R = (n-1)/2. In that calculation you wrote:

-a-a-a-a-a breo = (3*breoreireU+1)/2 = ... = 2*(3/2)-urU+-| -1

and it is clear that bb|o is growing in an unbounded fashionry, not converging to b=2.-a You've
just
got muddled...-a Note: I don't necessarily agree with this breo formula - it looks to be only an
approximation, but I do agree with your areo/breo limit [with your given assumptions].

-a-a-a-a-a-a-a the
-a-a-a-a-a-a-a iteration involves an infinite number of iterations of --a, a will
-a-a-a-a-a-a-a inevitably become zero, so the iteration cannot fail to meet the
-a-a-a-a-a-a-a iteration termination contion.

That is also not right - once ab|o becomes zero, there will be /no more --a operations, so there
can't
be infinitely many of them!

Regardless:

1.-a IF there are infinitely many iterations of --a, they can be interspersed
-a-a-a-a-a with a *= 3 operations, so it does not follow (just from what you've said)
-a-a-a-a-a that a /must/ become zero.
2.-a If a does become zero, it does not follow that the 1-4-2-1 loop has been
-a-a-a-a-a encountered, unless you have some argument to prove that.-a [This is
-a-a-a-a-a the same problem as with your earlier "no cycles" proof.]

-a-a-a-a-a-a-a If n is even, then repeating the even operation (a finite number of times)
-a-a-a-a-a-a-a cop(n) will yield an odd number without affecting the termination result
-a-a-a-a-a-a-a as stated above. Therefore, the proposition is proved. >>>>>

..aside from fixing the problems above.


Mike.

I agree with many point of your criticism, it is helpful.
Since your comments are on the original script, I will post the updated version to avoid
unnecessary reply.

--- [quote from the finalized version]
Prop:-a-a ....[cut]
-a-a-a-a-a-a void rcop3(int n) {
-a-a-a-a-a-a-a-a int a=n,b=0;
-a-a-a-a-a-a-a-a for(; a+b!=1;) {
-a-a-a-a-a-a-a-a-a-a if((a%2)!=0) {
-a-a-a-a-a-a-a-a-a-a-a-a --a; ++b;
-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a // a/b measure point A
-a-a-a-a-a-a-a-a-a-a if((b%2)!=0) {
-a-a-a-a-a-a-a-a-a-a-a-a a= 3*a;
-a-a-a-a-a-a-a-a-a-a-a-a b= 3*b+1;
-a-a-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a-a-a-a-a a= a/2;
-a-a-a-a-a-a-a-a-a-a b= b/2;
-a-a-a-a-a-a-a-a }
-a-a-a-a-a-a }

-a-a-a-a-a-a The following proof demonstrates:
-a-a-a-a-a-a-a-a 1. The ratio a/b is decreasing.

Agree.

-a-a-a-a-a-a-a-a 2. b has limit.

Not proven.

-a-a-a-a-a-a-a-a 3. a must decrease to below b because of the above reasons.

Not proven.

-a-a-a-a-a-a-a-a 4. Done, n=a+b has limit (cop(n) is known to terminate for n<2-|rU| at
-a-a-a-a-a-a-a-a-a-a-a least).

-a-a-a-a-a-a Let n be odd and there be no `--a`, `++b` process. Assume that each odd
-a-a-a-a-a-a operation is paired with only one even operation, then, at measurement
-a-a-a-a-a-a point A, we have:

-a-a-a-a-a-a areU = n-1
-a-a-a-a-a-a areo = (3*areoreireU)/2 = ... = (n-1)*(3/2)-urU+-|
-a-a-a-a-a-a breU = 1
-a-a-a-a-a-a breo = (3*breoreireU+1)/2 = ... = 2*(3/2)-urU+-| -1
-a-a-a-a-a-a areo/breo = (areoreireU)/(breoreireU) = ((n-1)*(3/2)-urU+-|)/(2*(3/2)-urU+-| -1)
-a-a-a-a-a-a-a-a-a-a-a-a = ... = (n-1)/(2-1/(3/2)-urU+-|)

-a-a-a-a-a-a Interim summary: areo/breo < areoreireU/breoreireU and lim{x->reR} areo/breo = (n-1)/2.
-a-a-a-a-a-a-a-a (After eight iterations, areo/breo is approximately 0.51. Actual iterations
-a-a-a-a-a-a-a-a-a may also include --a and ++b operations, so the actual value of areo/breo
-a-a-a-a-a-a-a-a-a will converge faster than the formula)

It must converge, but not necessarily to (n-1)/2 ...

After this point your argument seems to lose focus, and the notation is wrong!

-a-a-a-a-a-a Let r = a/b, then n/b = (a+b)/b = a/b+1 = r+1
-a-a-a-a-a-a => b = (a+b)/(r+1) = n/(r+1)

ok this is simple algebra for any /specific/ iteration value of n,a,b. These values are changing as
we iterate...

-a-a-a-a-a-a After sufficient iterations:
-a-a-a-a-a-a => The limit of r+1 = (n-1)/2 + 1 = (n+1)/2

you have not shown r converges to (n-1)/2, only that it converges to /something/.
[You showed it converges to (n-1)/2 under your stated conditions which do not apply in general.

-a-a-a-a-a-a => b = (2*n)/(n+1) = 2/(1+1/n)

No that's not right - you're mixing values of m,b,r with those for later iterations of cop() and
with limits. Also you're assuming r-->(n-1)/2. That was a specific result given your (impossible)
assumptions listed above. In general r /does/ converge, but might converge to some other number, or
become zero (in which case it also converges to zero so it's still true r converges). That is,
unless you find a way to fix your proof to prove otherwise...

Let's say rb|o ---> R. So:

bb|o = nb|o/(rb|o+1)
lim bb|o = lim nb|o / (R+1) // rb|o+1 ---> R+1
... EXCEPT that *you have not shown that nb|o converges*, so that last line is nonsense - we only use
'lim' symbol when we the limits are known to exist...

-a-a-a-a-a-a => b = 2 (the limit of b. it is known that n is a large number)

You have not proved that b converges. You can see this must be wrong, just from your earlier
(overly) simplified sequence for which you originally calculated R = (n-1)/2. In that calculation
you wrote:

breo = (3*breoreireU+1)/2 = ... = 2*(3/2)-urU+-| -1

and it is clear that bb|o is growing in an unbounded fashionry, not converging to b=2. You've just
got muddled... Note: I don't necessarily agree with this breo formula - it looks to be only an
approximation, but I do agree with your areo/breo limit [with your given assumptions].

-a-a-a-a-a-a Since b has limit (the numerical value is not important), the iteration
-a-a-a-a-a-a involves an infinite number of iterations of --a, a will inevitably become
-a-a-a-a-a-a zero, so the iteration cannot fail to meet the iteration termination
-a-a-a-a-a-a condition.

That is also not right - once ab|o becomes zero, there will be /no more --a operations, so there can't
be infinitely many of them!

Regardless:

1. IF there are infinitely many iterations of --a, they can be interspersed
with a *= 3 operations, so it does not follow (just from what you've said)
that a /must/ become zero.
2. If a does become zero, it does not follow that the 1-4-2-1 loop has been
encountered, unless you have some argument to prove that. [This is
the same problem as with your earlier "no cycles" proof.]

----------------------

1. a/b ratio (formula) is a lower bound estimate as stated. In the real cases,
-a-a-a it decreases faster.
2. In the iteration, even ops does not change a/b ratio. Ops --a,++b only makes
-a-a-a the ratio a/b-amore decreasing.
3. The proof only needs to show there is a limit. What value a/b converges does
-a-a-a not important.

So we agree a/b converges, but the updates above do not address any of the problems raised in my
previous post...

Mike.

Will you elaborate precisely?

Original comments repeated above.


Mike.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

wij <wyniijj5@gmail.com> writes:
[329 lines deleted]

Just a gentle reminder that this discussion, though it occasionally
includes something that looks like C code, is not about C.

There's a related thread about the Collatz Conjecture in comp.theory.
I encourage anyone who feels the need to discuss it to do so there --
or at least not to do so here.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 1/29/2026 9:33 PM, Janis Papanagnou wrote:

On 2026-01-28 21:59, Chris M. Thomasson wrote:

[...]

A real with infinite precision can hold an irrational?

What are you talking about here? Abstract computers? - Please
explain.[*]

Its an abstract thought indeed... :^)

I had been talking about a geometric representation of mathematics
by the ancient Greeks. In that case an "irrational" was represented
by a geometric entity, e.g. the diagonal of a square (for sqrt(2)).

I'm not aware that back then they used real numbers with precision.

Think of a number where each, say 10-ary symbols 0...9, is derived from
a TRNG. For an unsigned integer, say the _first_ symbol is a TRNG from
1...9. All the others are TRNG from 0...9.

401986393421051...

Take it to infinity... is it a number???

;^)

Janis

[*] OTOH, this all - including the OP - appears to be quite OT and
IMO better fits in a math newsgroup, so we can also just abstain
from further digressions.

Well, shit happens... ;^)
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

I'm not intendig to proof anything, but I wrote this some time ago when being bored.

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <assert.h>
#include <ctype.h>

#define N 1024

int check(char *s)
{
int result=1;
while (*s)
{
if (!isdigit(*s++))
{
result=0;
}
}
return(result);
}

char *insert(char *s,char c,int *l)
{
int i;
assert (*l<(N-1));

for (i=*l; i; --i)
{
s[i]=s[i-1];
}
s[0]=c;
++(*l);
s[*l]='\0';
return(s);
}

char *even(char *s,int *l)
{
int c,carry,i;
char *copy;

copy=malloc(*l+1);
assert(copy!=NULL);
copy[*l]='\0';
carry=0;
for (i=0; i<*l; ++i)
{
c=s[i]-'0'+carry;
carry=0;
if (c&1)
{
carry=10;
c-=1;
}
c=c/2;
copy[i]=c+'0';
}
i=0;
while (copy[i]=='0')
{
++i;
}
(*l)-=i;
strcpy(s,copy+i);
free(copy);
return(s);
}

char *odd(char *s,int *l)
{
int c,carry,i;
char *copy;

copy=malloc(*l+2);
assert(copy!=NULL);
carry=0;
copy[*l]='\0';
for (i=*l; i; --i)
{
c=3*(s[i-1]-'0')+carry;
if (i==*l)
{
++c;
}
copy[i-1]=(c%10)+'0';
carry=(c-(c%10))/10;
}
while(carry)
{
c=carry%10;
insert(copy,c+'0',l);
carry=(c-(c%10))/10;
}
strcpy(s,copy);
free(copy);
return(s);
}

int main(int argc,char *argv[])
{
int i,l;
char data[N];

for (i=1; i<argc; ++i)
{
strcpy(data,argv[i]);
if (check(data))
{
puts(data);
l=strlen(data);
while (strcmp(data,"1"))
{
if (data[l-1]&1)
{
odd(data,&l);
}
else
{
even(data,&l);
}
puts(data);
}
}
}
}
--
A tuna is a way of Liff

Jan v/d Broek
balglaas@xs4all.nl
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

The proof is revised (bug fixed), even shorter (109 lines)!
----------
This file is intended a proof of Collatz Conjecture. The contents may be updated anytime. https://sourceforge.net/projects/cscall/files/MisFiles/Coll-proof-en.txt/download
The text is converted by google translate with modest modification from https://sourceforge.net/projects/cscall/files/MisFiles/Coll-proof-zh.txt/download
Reader might want to try different translator or different settings. +---------+
| Preface |
+---------+
3x+1 problem: For any integer n greater than or equal to 1, if n is odd,
multiply by 3 and add 1. If n is even, divide by 2.
The question is, will all numbers be calculated to 1 using this method? The
following proof states that the answer is yes, they will always be calculated
to 1. Proving this problem using Peano's axioms like axiomatic system is
difficult (or would be very lengthy), so an algorithm (Turing machine model)
is used for proof. ----------------------------------------------------------------------------- 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, nreeN<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, nreeN<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: For any nreeN<1,+1>, the cop iteration operation terminates.
Proof: Let procedure rcop2 decomposes the n in rcop into n= a+b form.
void rcop2(int n) {
int a=n, b=0;
for(;a+b!=1;) { // a+b measure point A (a+b is equivalent to n in the
// cop iteration process)
if((a%2) != 0) {
--a; ++b; // a,b are adjusted so that a remains even, so that the
// following algorithm can be performed and remains
// equivalent to the cop(n) iteration.
}
// a/b measures point B
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)
}
a= a/2; // (a+b)/2 will be executed in each iteration
b= b/2;
}
}
Let n be odd and there be no --a, ++b process. Assume that each odd
operation is paired with an even operation. Then, at measurement point B,
we have:
areU= n-1
areo= (3*areoreireU)/2 =... = (n-1)*(3/2)-urU+-|
breU= 1
breo= (3*breoreireU+1)/2=... = 2*(3/2)-urU+-| -1
areo/breo= (areoreireU)/(breoreireU) = ((n-1)*(3/2)-urU+-|)/(2*(3/2)-urU+-| -1)
=... = (n-1)/(2- 1/(3/2)-urU+-|)
Interim summary: areo/breo < areoreireU/breoreireU, and lim{x->reR} areo/breo = (n-1)/2.
Because "approximately half the limit value (n-1)/2" (not including the
actual iterations which involve --a and ++b operations making areo smaller
and breo larger) is recursively true, we can deduce that:
(1) The actual value of areo/breo will decrease to the final value 0, and
a=0, eventually.
(2) The number of times breo is odd is less than the number of times breo is
even (there are two, or more, consecutive even operations).
Let r= a/b, areo=0. The value areoreireU, before iterating to 0, is 1 (measurement
point A). At this point, rreoreireU is a small value, relative to the initial
value rreU (the value of areo/breo can be considered as decreasing continuously
by (n-1)/2). When n>=5, breoreireU (=areoreireU*rreoreireU =rreoreireU) is guaranteed to be less
than n-1. Therefore, nreoreireU= areoreireU+breoreireU < 1+(n-1) <=> nreoreireU<n.
From nreoreireU<n, we can prove by mathematical induction that the proposition
"the iterative operation of cop(n) terminates" holds true.
+------------+
| References |
+------------+
[1] Real number contains infinity. Recurring decimals are irrational numbers.
Peano-Axioms system can hardly prove reRreerao.
https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
--- Synchronet 3.21b-Linux NewsLink 1.2