[Reference] Real number and infinity. Recurring decimals are
irrational numbers.
[Reference] Real number and infinity. Recurring decimals are
irrational numbers.
On Sun, 25 Jan 2026 00:37:38 +0800, wij wrote:Such arithmetic is called approximation, or magic proof simply because
[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.
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 ...
On Sun, 25 Jan 2026 13:28:31 +0800, wij wrote:Prove it. No one wants blind belief.
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, it’s exact.
I think your problem is you are trying to think about maths using aYour problem is just repeating what you are told to repeat, no meaning.
specific low-level programming language (C or C++) which only supports finite-precision integers.
On Sun, 2026-01-25 at 08:15 +0000, Lawrence D’Oliveiro 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, it’s 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.
On 25/01/2026 09:46, wij wrote:
On Sun, 2026-01-25 at 08:15 +0000, Lawrence D’Oliveiro 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, it’s 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.
On 25/01/2026 09:46, wij wrote:
On Sun, 2026-01-25 at 08:15 +0000, Lawrence D’Oliveiro 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, it’s 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 alsoI see no proof, just opinion, 'blind belief', repeating. I was expecting
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), inventingSaid a lot, but I am afraid soon you will find you are accusing yourself.
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.I agree such repeating decimal is rational or not things may be off-topic, but who brought it up?
On Sun, 2026-01-25 at 08:15 +0000, Lawrence D’Oliveiro 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, it’s exact.
Prove it.
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++. 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.
I agree such repeating decimal is rational or not things may be off-topic, 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???
You know the truth in subconscious?
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.
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++. 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.
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 functionDo posters have to write a C function for sales of tissue paper to be on-topic? It is because you believe you know C (but shallow).
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.Why did I often heard you guys arguing about wild 'philosophy' of C
If you really had proof of the Collatz conjecture, especially one this short, it would be sensational - Abel prize or Fields medal level stuff.Sounds to confirm what I thought: All is simply because you are not there
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.
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 ...
On Sun, 25 Jan 2026 13:28:31 +0800, wij wrote:You need to prove 4/33 exactly equal to 0.1212..., not approximation.
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 anYes, the same as infinity/infinitesimal.
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,True if you are not referring to the current 'standard real number system'. What else? (doesn't sound to contain much information)
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.
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.
On Sun, 2026-01-25 at 08:15 +0000, Lawrence D’Oliveiro 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, it’s 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.
On Sun, 25 Jan 2026 16:46:43 +0800, wij wrote: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!).
On Sun, 2026-01-25 at 08:15 +0000, Lawrence D’Oliveiro 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, it’s 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.a₁a₂...aₘb₁b₂...bₙb₁b₂...bₙ...
where the a’s and b’s are decimal digits, such that a₁a₂...aₘ represents the initial non-repeating part, consisting of m digits,
where m ≥ 0, and b₁b₂...bₙ represents the repeating part, consisting of n digits, where n > 0. First, separate out the non-repeating part:
X * 10 ** m = a₁a₂...aₘ.b₁b₂...bₙb₁b₂...bₙ...
from which
X * 10 ** m - a₁a₂...aₘ = 0.b₁b₂...bₙb₁b₂...bₙ... = (b₁b₂...bₙ ÷ 10 ** n) + (b₁b₂...bₙ ÷ 10 ** n²) + ...
= (b₁b₂...bₙ ÷ (10 ** n - 1))
Notice that’s 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 “rational”. If it’s 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.
No, I don't believe 'infinite-precision integer' is representable.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.
You’re not familiar with languages that support infinite-precision integers, are you?
You need to prove 4/33 exactly equal to 0.1212..., not approximation.
(I probably regret answering to your post.)Not quite sure what you mean. https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
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: „Die Definition von Wahnsinn ist, immer wieder das Gleiche zu tun und andere Ergebnisse zu erwarten“.
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
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¹⁶ at
least.
Funny!!!!!!!!
On Mon, 2026-01-26 at 01:25 +0100, Janis Papanagnou wrote:
(I probably regret answering to your post.)Not quite sure what you mean.
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: „Die Definition von Wahnsinn ist,
immer wieder das Gleiche zu tun und andere Ergebnisse zu erwarten“. >>
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
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)
On 26/01/2026 16:51, wij wrote: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
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
__
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: „Die Definition von Wahnsinn ist,
immer wieder das Gleiche zu tun und andere Ergebnisse zu erwarten“.
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".
JanisNot 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)
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.)Not quite sure what you mean.
On 2026-01-25 18:20, wij wrote:
Is that all you want proven; a specific example?
You need to prove 4/33 exactly equal to 0.1212..., not approximation. >>>>
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: „Die Definition von Wahnsinn ist,
immer wieder das Gleiche zu tun und andere Ergebnisse zu erwarten“.
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
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.
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 obvious, I leave as record)
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.)Not quite sure what you mean.
On 2026-01-25 18:20, wij wrote:
Is that all you want proven; a specific example?
You need to prove 4/33 exactly equal to 0.1212..., not approximation. >>>>>
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: „Die Definition von Wahnsinn ist,
immer wieder das Gleiche zu tun und andere Ergebnisse zu erwarten“.
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
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.
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 obvious, 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. 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).
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.)Not quite sure what you mean.
On 2026-01-25 18:20, wij wrote:
Is that all you want proven; a specific example?
You need to prove 4/33 exactly equal to 0.1212..., not approximation. >>>>>>
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: „Die Definition von Wahnsinn ist,
immer wieder das Gleiche zu tun und andere Ergebnisse zu erwarten“.
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
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.
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 obvious, 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.
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).
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.
Prop 2= Repeating Q+Q infinitely does not yield rational number.
(precisely, positive rational number)
On 26/01/2026 16:51, wij wrote: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.
...
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 ofAccordingly, I suppose you deny this passage:
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.
...No problem, you just need to prove it yourself.
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.
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
__
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: „Die Definition von Wahnsinn ist,
immer wieder das Gleiche zu tun und andere Ergebnisse zu erwarten“.
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".
JanisNot 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.
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 obvious, 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.
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.
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.
Prop 3: Recurring decimals are irrational numbers.
wij <wyniijj5@gmail.com> writes:Agree, but elementary (high school or earlier) algebra told a false proposition if Prop1, Prop2, Prop3 are true.
Prop 3: Recurring decimals are irrational numbers.
This proposition is already known to be false from
elementary (high school or earlier) algebra.
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 didn’t know about “real” numbers back then. He was talking about “irrational” numbers.
On 27/01/2026 23:52, Lawrence D’Oliveiro 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 didn’t know about “real” numbers back then. He was talking about >> “irrational” numbers.
Indeed. They certainly knew about irrational numbers - [...]
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.
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
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.
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 tooobvious, 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.
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.
On 2026-01-28 08:29, David Brown wrote:
On 27/01/2026 23:52, Lawrence D’Oliveiro 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 didn’t know about “real” numbers back then. He was talking about >>> “irrational” numbers.
Indeed. 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ß-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).
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
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.
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 obvious, 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.
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.
In article <871pj9tze2.fsf@bsb.me.uk>, Ben Bacarisse <ben@bsb.me.uk> wrote:
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.
I'm not convinced. The definition of a decimal number is the sum of
its digits multiplied by the appropriate powers of 10, which for a non-terminating decimal is defined as a limit. You are implicitly
using limits to even assert that there is a decimal representation of
1/3.
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, n∈N<1,+1>, after the cop iteration will
eventually calculate to 1 (i.e., cop(...cop(n))=1), then n is a Collatz
number. Otherwise n is not a Collatz number.
Collatz Problem: For each integer n, n∈N<1,+1>, is n a Collatz number? IOW,
the question is equivalent to asking whether the following procedure rcop
terminates or not.
void rcop(int n) {
for(;n!=1;) {
n=cop(n);
}
}
Prop: cop(n) iteration contains no cycle (except for the '1-4-2-1' cycle, since
1 is the termination condition).
Proof: n can be decomposed into n= a+b. rcop(n) can be rewritten as rcop2(n):
void rcop2(int n) {
int a=n,b=0;
for(;a+b!=1;) { // a+b= n in the cop iterative process.
if((a%2)!=0) {
--a; ++b; // Adjust a and b so that a remains even and the
// following algorithm can be performed and remains
// equivalent to cop(n) iteration.
}
if((b%2)!=0) { // Equivalent to (a+b)%2 (because a is even).
a= 3*a;
b= 3*b+1; // 3*(a+b)+1= (3*a) +(3*b+1)
} else {
a= a/2;
b= b/2;
}
}
}
Let nᵢ, aᵢ, bᵢ represent the values n,a, and b in the iteration.
Assume that the cop(n) iteration is cyclic. The cycle is a fixed-length
sequence, and the process must contain the operations 3x+1 and x/2 (and
the associated operations --a and ++b, unless n is a 2^x number, but such
numbers do not cycle). Let the cyclic sequence of n be:
n₁, n₂, n₃, ..., nₓ (n=n₁).
Because --a and ++b are continuously interpolated during the cycle, if
aᵢ≠0, then bᵢ and nᵢ=aᵢ+bᵢ will increase infinitely, contradicting the
assumption that nᵢ is cyclic. Therefore, aᵢ=0 must hold during the cycle,
but the condition of aᵢ=0 only exists in 1-4-2-1, aᵢ=0 cannot cause the
non-1-4-2-1 cycle of n₁,n₂,n₃,...,nₓ.
Therefore, we can conclude that cop(n) iterations are non-cyclic.
Prop: For any n∈N<1,+1>, the cop iteration operation terminates.
Proof: Since an odd number n will always become even immediately after the
cop iteration, it must undergo n/2 iterations. Therefore, we have an
equivalent rcop3:
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:
a₁ = n-1
aₓ = (3*aₓ₋₁)/2 = ... = (n-1)*(3/2)ˣ⁻¹
b₁ = 1
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -1
aₓ/bₓ = (aₓ₋₁)/(bₓ₋₁) = ((n-1)*(3/2)ˣ⁻¹)/(2*(3/2)ˣ⁻¹ -1)
= ... = (n-1)/(2-1/(3/2)ˣ⁻¹)
Interim summary: aₓ/bₓ < aₓ₋₁/bₓ₋₁ and lim{x->∞} aₓ/bₓ = (n-1)/2.
(After eight iterations, aₓ/bₓ is approximately 0.51. Actual iterations
may also include --a and ++b operations, so the actual value of aₓ/bₓ
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.
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, n∈N<1,+1>, after the cop iteration will eventually calculate to 1 (i.e., cop(...cop(n))=1), then n is a Collatz
number. Otherwise n is not a Collatz number.
Collatz Problem: For each integer n, n∈N<1,+1>, is n a Collatz number? IOW,
the question is equivalent to asking whether the following procedure rcop
terminates or not.
void rcop(int n) {
for(;n!=1;) {
n=cop(n);
}
}
Prop: cop(n) iteration contains no cycle (except for the '1-4-2-1' cycle, since
1 is the termination condition).
If you could prove just this much, you would become famous, at least amongst mathematicians!
Proof: n can be decomposed into n= a+b. rcop(n) can be rewritten as rcop2(n):
void rcop2(int n) {
int a=n,b=0;
for(;a+b!=1;) { // a+b= n in the cop iterative process. if((a%2)!=0) {
--a; ++b; // Adjust a and b so that a remains even and the
// following algorithm can be performed and remains
// equivalent to cop(n) iteration.
}
if((b%2)!=0) { // Equivalent to (a+b)%2 (because a is even).
a= 3*a;
b= 3*b+1; // 3*(a+b)+1= (3*a) +(3*b+1) } else {
a= a/2;
b= b/2;
}
}
}
Let nᵢ, aᵢ, bᵢ represent the values n,a, and b in the iteration.
Assume that the cop(n) iteration is cyclic. The cycle is a fixed-length
sequence, and the process must contain the operations 3x+1 and x/2 (and
the associated operations --a and ++b, unless n is a 2^x number, but such
numbers do not cycle). Let the cyclic sequence of n be: n₁, n₂, n₃, ..., nₓ (n=n₁).
Because --a and ++b are continuously interpolated during the cycle, if
I think "interpolated" is not the right word. Not sure exactly what is being claimed, but maybe
this doesn't matter - check my next comment...
aᵢ≠0, then bᵢ and nᵢ=aᵢ+bᵢ will increase infinitely, contradicting the
assumption that nᵢ is cyclic. Therefore, aᵢ=0 must hold during the cycle,
Regardless of your reasoning, it is clear (and easily proved) that as the cycle repeats, aᵢ at the
same point in the cycle must decrease until it becomes zero. At this point aᵢ remains zero for all
further i, and no more --a,++b operations occur. (So there can only be finitely many such ops, but
I agree aᵢ has to become zero, which seems to be what you want to claim.)
but the condition of aᵢ=0 only exists in 1-4-2-1, aᵢ=0 cannot cause the
non-1-4-2-1 cycle of n₁,n₂,n₃,...,nₓ.
That doesn't follow from anything you've said so far. So this proof will not make you famous. Maybe
you can work on this and fill in the gap. You need an earlier "Prop: If aᵢ=0 then bᵢ <= 4" or
equivalent". Then you can be famous!
It does seem to be the case with numbers I've tried [n up to 30,000,000 ish], that aᵢ only becomes
zero when we hit the final 1-4-2-1 cycle, so your claim is plausibly /true/, but that's not a
/proof/ in any sense, of course.
Therefore, we can conclude that cop(n) iterations are non-cyclic.
Prop: For any n∈N<1,+1>, the cop iteration operation terminates.
Proof: Since an odd number n will always become even immediately after the
cop iteration, it must undergo n/2 iterations. Therefore, we have an
equivalent rcop3:
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:
a₁ = n-1
aₓ = (3*aₓ₋₁)/2 = ... = (n-1)*(3/2)ˣ⁻¹ b₁ = 1
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -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...
aₓ/bₓ = (aₓ₋₁)/(bₓ₋₁) = ((n-1)*(3/2)ˣ⁻¹)/(2*(3/2)ˣ⁻¹ -1)
= ... = (n-1)/(2-1/(3/2)ˣ⁻¹)
Interim summary: aₓ/bₓ < aₓ₋₁/bₓ₋₁ and lim{x->∞} aₓ/bₓ = (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 aᵢ/bᵢ as non-increasing, so aᵢ/bᵢ 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, aₓ/bₓ is approximately 0.51. Actual iterations
may also include --a and ++b operations, so the actual value of aₓ/bₓ
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 mᵢ,bᵢ,rᵢ or similar. And assume rᵢ-->R (e.g.).
So:
The limit of r+1 = R+1 // with possibility R=0
bᵢ = mᵢ/(rᵢ+1)
lim bᵢ = lim mᵢ / (R+1)
... EXCEPT that you have not shown that mᵢ 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? rᵢ ---> R, but it seems you're trying to argue bᵢ 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:
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -1
and it is clear that bᵢ is growing in an unbounded fashionry, not converging to b=2. You've just
got muddled... Note: I don't necessarily agree with this bₓ formula - it looks to be only an
approximation, but I do agree with your aₓ/bₓ 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 aᵢ 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.I agree with many point of your criticism, it is helpful.
On Sun, 2026-01-25 at 11:25 -0500, James Kuyper wrote:Prop2 had rewrote (easier for older high schools to understand). https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
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 if 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 should mean (an option may be merely for signifying overflow), I would suggest reserve the bit, not mixing with other meaning.
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 ::=
int cop(int n) {
if(n<=1) {
if(n<1) {
throw Error;
}
return 1; // 1 is the iteration endpoint
}
if(n%2) {
return 3*n+1; // Odd number rule
} else {
return n/2; // Even number rule
}
}
Collatz number: If an integer n, n∈N<1,+1>, after the cop iteration will >>> eventually calculate to 1 (i.e., cop(...cop(n))=1), then n is a Collatz
number. Otherwise n is not a Collatz number.
Collatz Problem: For each integer n, n∈N<1,+1>, is n a Collatz number? IOW,
the question is equivalent to asking whether the following procedure rcop
terminates or not.
void rcop(int n) {
for(;n!=1;) {
n=cop(n);
}
}
Prop: cop(n) iteration contains no cycle (except for the '1-4-2-1' cycle, since
1 is the termination condition).
If you could prove just this much, you would become famous, at least amongst mathematicians!
Proof: n can be decomposed into n= a+b. rcop(n) can be rewritten as rcop2(n):
void rcop2(int n) {
int a=n,b=0;
for(;a+b!=1;) { // a+b= n in the cop iterative process. >>> if((a%2)!=0) {
--a; ++b; // Adjust a and b so that a remains even and the
// following algorithm can be performed and remains
// equivalent to cop(n) iteration.
}
if((b%2)!=0) { // Equivalent to (a+b)%2 (because a is even).
a= 3*a;
b= 3*b+1; // 3*(a+b)+1= (3*a) +(3*b+1)
} else {
a= a/2;
b= b/2;
}
}
}
Let nᵢ, aᵢ, bᵢ represent the values n,a, and b in the iteration.
Assume that the cop(n) iteration is cyclic. The cycle is a fixed-length
sequence, and the process must contain the operations 3x+1 and x/2 (and
the associated operations --a and ++b, unless n is a 2^x number, but such
numbers do not cycle). Let the cyclic sequence of n be:
n₁, n₂, n₃, ..., nₓ (n=n₁).
Because --a and ++b are continuously interpolated during the cycle, if
I think "interpolated" is not the right word. Not sure exactly what is being claimed, but maybe
this doesn't matter - check my next comment...
aᵢ≠0, then bᵢ and nᵢ=aᵢ+bᵢ will increase infinitely, contradicting the
assumption that nᵢ is cyclic. Therefore, aᵢ=0 must hold during the cycle,
Regardless of your reasoning, it is clear (and easily proved) that as the cycle repeats, aᵢ at the
same point in the cycle must decrease until it becomes zero. At this point aᵢ remains zero for all
further i, and no more --a,++b operations occur. (So there can only be finitely many such ops, but
I agree aᵢ has to become zero, which seems to be what you want to claim.) >>
but the condition of aᵢ=0 only exists in 1-4-2-1, aᵢ=0 cannot cause the
non-1-4-2-1 cycle of n₁,n₂,n₃,...,nₓ.
That doesn't follow from anything you've said so far. So this proof will not make you famous. Maybe
you can work on this and fill in the gap. You need an earlier "Prop: If aᵢ=0 then bᵢ <= 4" or
equivalent". Then you can be famous!
It does seem to be the case with numbers I've tried [n up to 30,000,000 ish], that aᵢ only becomes
zero when we hit the final 1-4-2-1 cycle, so your claim is plausibly /true/, but that's not a
/proof/ in any sense, of course.
Therefore, we can conclude that cop(n) iterations are non-cyclic.
Prop: For any n∈N<1,+1>, the cop iteration operation terminates.
Proof: Since an odd number n will always become even immediately after the
cop iteration, it must undergo n/2 iterations. Therefore, we have an
equivalent rcop3:
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:
a₁ = n-1
aₓ = (3*aₓ₋₁)/2 = ... = (n-1)*(3/2)ˣ⁻¹
b₁ = 1
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -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...
aₓ/bₓ = (aₓ₋₁)/(bₓ₋₁) = ((n-1)*(3/2)ˣ⁻¹)/(2*(3/2)ˣ⁻¹ -1)
= ... = (n-1)/(2-1/(3/2)ˣ⁻¹)
Interim summary: aₓ/bₓ < aₓ₋₁/bₓ₋₁ and lim{x->∞} aₓ/bₓ = (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 aᵢ/bᵢ as non-increasing, so aᵢ/bᵢ 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, aₓ/bₓ is approximately 0.51. Actual iterations
may also include --a and ++b operations, so the actual value of aₓ/bₓ
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 mᵢ,bᵢ,rᵢ or similar. And assume rᵢ-->R (e.g.).
So:
The limit of r+1 = R+1 // with possibility R=0
bᵢ = mᵢ/(rᵢ+1)
lim bᵢ = lim mᵢ / (R+1)
... EXCEPT that you have not shown that mᵢ 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? rᵢ ---> R, but it seems you're trying to argue bᵢ 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: >>
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -1
and it is clear that bᵢ is growing in an unbounded fashionry, not converging to b=2. You've just
got muddled... Note: I don't necessarily agree with this bₓ formula - it looks to be only an
approximation, but I do agree with your aₓ/bₓ 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 aᵢ 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.]
..aside from fixing the problems above.
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.
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¹⁶ 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:
a₁ = n-1
aₓ = (3*aₓ₋₁)/2 = ... = (n-1)*(3/2)ˣ⁻¹
b₁ = 1
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -1
aₓ/bₓ = (aₓ₋₁)/(bₓ₋₁) = ((n-1)*(3/2)ˣ⁻¹)/(2*(3/2)ˣ⁻¹ -1)
= ... = (n-1)/(2-1/(3/2)ˣ⁻¹)
Interim summary: aₓ/bₓ < aₓ₋₁/bₓ₋₁ and lim{x->∞} aₓ/bₓ = (n-1)/2.
(After eight iterations, aₓ/bₓ is approximately 0.51. Actual iterations
may also include --a and ++b operations, so the actual value of aₓ/bₓ
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
the ratio a/b more decreasing.
3. The proof only needs to show there is a limit. What value a/b converges does
not important.
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 ::=
int cop(int n) {
if(n<=1) {
if(n<1) {
throw Error;
}
return 1; // 1 is the iteration endpoint }
if(n%2) {
return 3*n+1; // Odd number rule } else {
return n/2; // Even number rule }
}
Collatz number: If an integer n, n∈N<1,+1>, after the cop iteration will
eventually calculate to 1 (i.e., cop(...cop(n))=1), then n is a Collatz
number. Otherwise n is not a Collatz number.
Collatz Problem: For each integer n, n∈N<1,+1>, is n a Collatz number? IOW,
the question is equivalent to asking whether the following procedure rcop
terminates or not.
void rcop(int n) {
for(;n!=1;) {
n=cop(n);
}
}
Prop: cop(n) iteration contains no cycle (except for the '1-4-2-1' cycle, since
1 is the termination condition).
If you could prove just this much, you would become famous, at least amongst mathematicians!
Proof: n can be decomposed into n= a+b. rcop(n) can be rewritten as rcop2(n):
void rcop2(int n) {
int a=n,b=0;
for(;a+b!=1;) { // a+b= n in the cop iterative process.
if((a%2)!=0) {
--a; ++b; // Adjust a and b so that a remains even and the
// following algorithm can be performed and remains
// equivalent to cop(n) iteration.
}
if((b%2)!=0) { // Equivalent to (a+b)%2 (because a is even).
a= 3*a;
b= 3*b+1; // 3*(a+b)+1= (3*a) +(3*b+1) } else {
a= a/2;
b= b/2;
}
}
}
Let nᵢ, aᵢ, bᵢ represent the values n,a, and b in the iteration.
Assume that the cop(n) iteration is cyclic. The cycle is a fixed-length
sequence, and the process must contain the operations 3x+1 and x/2 (and
the associated operations --a and ++b, unless n is a 2^x number, but such
numbers do not cycle). Let the cyclic sequence of n be: n₁, n₂, n₃, ..., nₓ (n=n₁).
Because --a and ++b are continuously interpolated during the cycle, if
I think "interpolated" is not the right word. Not sure exactly what is being claimed, but maybe
this doesn't matter - check my next comment...
aᵢ≠0, then bᵢ and nᵢ=aᵢ+bᵢ will increase infinitely, contradicting the
assumption that nᵢ is cyclic. Therefore, aᵢ=0 must hold during the cycle,
Regardless of your reasoning, it is clear (and easily proved) that as the cycle repeats, aᵢ at
the
same point in the cycle must decrease until it becomes zero. At this point aᵢ remains zero for
all
further i, and no more --a,++b operations occur. (So there can only be finitely many such ops,
but
I agree aᵢ has to become zero, which seems to be what you want to claim.)
but the condition of aᵢ=0 only exists in 1-4-2-1, aᵢ=0 cannot cause the
non-1-4-2-1 cycle of n₁,n₂,n₃,...,nₓ.
That doesn't follow from anything you've said so far. So this proof will not make you famous.
Maybe
you can work on this and fill in the gap. You need an earlier "Prop: If aᵢ=0 then bᵢ <= 4" or
equivalent". Then you can be famous!
It does seem to be the case with numbers I've tried [n up to 30,000,000 ish], that aᵢ only
becomes
zero when we hit the final 1-4-2-1 cycle, so your claim is plausibly /true/, but that's not a
/proof/ in any sense, of course.
Therefore, we can conclude that cop(n) iterations are non-cyclic.
Prop: For any n∈N<1,+1>, the cop iteration operation terminates. Proof: Since an odd number n will always become even immediately after the
cop iteration, it must undergo n/2 iterations. Therefore, we have an
equivalent rcop3:
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:
a₁ = n-1
aₓ = (3*aₓ₋₁)/2 = ... = (n-1)*(3/2)ˣ⁻¹ b₁ = 1
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -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...
aₓ/bₓ = (aₓ₋₁)/(bₓ₋₁) = ((n-1)*(3/2)ˣ⁻¹)/(2*(3/2)ˣ⁻¹ -1)
= ... = (n-1)/(2-1/(3/2)ˣ⁻¹)
Interim summary: aₓ/bₓ < aₓ₋₁/bₓ₋₁ and lim{x->∞} aₓ/bₓ = (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 aᵢ/bᵢ as non-increasing, so aᵢ/bᵢ 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, aₓ/bₓ is approximately 0.51. Actual iterations
may also include --a and ++b operations, so the actual value of aₓ/bₓ
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 mᵢ,bᵢ,rᵢ or similar. And assume rᵢ-->R (e.g.).
So:
The limit of r+1 = R+1 // with possibility R=0 bᵢ = mᵢ/(rᵢ+1)
lim bᵢ = lim mᵢ / (R+1)
... EXCEPT that you have not shown that mᵢ 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? rᵢ ---> R, but it seems you're trying to argue bᵢ 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:
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -1
and it is clear that bᵢ is growing in an unbounded fashionry, not converging to b=2. You've
just
got muddled... Note: I don't necessarily agree with this bₓ formula - it looks to be only an
approximation, but I do agree with your aₓ/bₓ 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 aᵢ 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.
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¹⁶ 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:
a₁ = n-1
aₓ = (3*aₓ₋₁)/2 = ... = (n-1)*(3/2)ˣ⁻¹ b₁ = 1
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -1 aₓ/bₓ = (aₓ₋₁)/(bₓ₋₁) = ((n-1)*(3/2)ˣ⁻¹)/(2*(3/2)ˣ⁻¹ -1)
= ... = (n-1)/(2-1/(3/2)ˣ⁻¹)
Interim summary: aₓ/bₓ < aₓ₋₁/bₓ₋₁ and lim{x->∞} aₓ/bₓ = (n-1)/2.
(After eight iterations, aₓ/bₓ is approximately 0.51. Actual iterations
may also include --a and ++b operations, so the actual value of aₓ/bₓ
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
the ratio a/b more decreasing.
3. The proof only needs to show there is a limit. What value a/b converges does
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.
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 ::=
int cop(int n) {
if(n<=1) {
if(n<1) {
throw Error;
}
return 1; // 1 is the iteration endpoint }
if(n%2) {
return 3*n+1; // Odd number rule } else {
return n/2; // Even number rule }
}
Collatz number: If an integer n, n∈N<1,+1>, after the cop iteration will
eventually calculate to 1 (i.e., cop(...cop(n))=1), then n is a Collatz
number. Otherwise n is not a Collatz number.
Collatz Problem: For each integer n, n∈N<1,+1>, is n a Collatz number? IOW,
the question is equivalent to asking whether the following procedure rcop
terminates or not.
void rcop(int n) {
for(;n!=1;) {
n=cop(n);
}
}
Prop: cop(n) iteration contains no cycle (except for the '1-4-2-1' cycle, since
1 is the termination condition).
If you could prove just this much, you would become famous, at least amongst mathematicians!
Proof: n can be decomposed into n= a+b. rcop(n) can be rewritten as rcop2(n):
void rcop2(int n) {
int a=n,b=0;
for(;a+b!=1;) { // a+b= n in the cop iterative process.
if((a%2)!=0) {
--a; ++b; // Adjust a and b so that a remains even and the
// following algorithm can be performed and remains
// equivalent to cop(n) iteration.
}
if((b%2)!=0) { // Equivalent to (a+b)%2 (because a is even).
a= 3*a;
b= 3*b+1; // 3*(a+b)+1= (3*a) +(3*b+1) } else {
a= a/2;
b= b/2;
}
}
}
Let nᵢ, aᵢ, bᵢ represent the values n,a, and b in the iteration.
Assume that the cop(n) iteration is cyclic. The cycle is a fixed-length
sequence, and the process must contain the operations 3x+1 and x/2 (and
the associated operations --a and ++b, unless n is a 2^x number, but such
numbers do not cycle). Let the cyclic sequence of n be: n₁, n₂, n₃, ..., nₓ (n=n₁).
Because --a and ++b are continuously interpolated during the cycle, if
I think "interpolated" is not the right word. Not sure exactly what is being claimed, but maybe
this doesn't matter - check my next comment...
aᵢ≠0, then bᵢ and nᵢ=aᵢ+bᵢ will increase infinitely, contradicting the
assumption that nᵢ is cyclic. Therefore, aᵢ=0 must hold during the cycle,
Regardless of your reasoning, it is clear (and easily proved) that as the cycle repeats, aᵢ at
the
same point in the cycle must decrease until it becomes zero. At this point aᵢ remains zero for
all
further i, and no more --a,++b operations occur. (So there can only be finitely many such ops,
but
I agree aᵢ has to become zero, which seems to be what you want to claim.)
but the condition of aᵢ=0 only exists in 1-4-2-1, aᵢ=0 cannot cause the
non-1-4-2-1 cycle of n₁,n₂,n₃,...,nₓ.
That doesn't follow from anything you've said so far. So this proof will not make you famous.
Maybe
you can work on this and fill in the gap. You need an earlier "Prop: If aᵢ=0 then bᵢ <= 4" or
equivalent". Then you can be famous!
It does seem to be the case with numbers I've tried [n up to 30,000,000 ish], that aᵢ only
becomes
zero when we hit the final 1-4-2-1 cycle, so your claim is plausibly /true/, but that's not a
/proof/ in any sense, of course.
Therefore, we can conclude that cop(n) iterations are non-cyclic.
Prop: For any n∈N<1,+1>, the cop iteration operation terminates. Proof: Since an odd number n will always become even immediately after the
cop iteration, it must undergo n/2 iterations. Therefore, we have an
equivalent rcop3:
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:
a₁ = n-1
aₓ = (3*aₓ₋₁)/2 = ... = (n-1)*(3/2)ˣ⁻¹ b₁ = 1
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -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...
aₓ/bₓ = (aₓ₋₁)/(bₓ₋₁) = ((n-1)*(3/2)ˣ⁻¹)/(2*(3/2)ˣ⁻¹ -1)
= ... = (n-1)/(2-1/(3/2)ˣ⁻¹)
Interim summary: aₓ/bₓ < aₓ₋₁/bₓ₋₁ and lim{x->∞} aₓ/bₓ = (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 aᵢ/bᵢ as non-increasing, so aᵢ/bᵢ 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, aₓ/bₓ is approximately 0.51. Actual iterations
may also include --a and ++b operations, so the actual value of aₓ/bₓ
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 mᵢ,bᵢ,rᵢ or similar. And assume rᵢ-->R (e.g.).
So:
The limit of r+1 = R+1 // with possibility R=0 bᵢ = mᵢ/(rᵢ+1)
lim bᵢ = lim mᵢ / (R+1)
... EXCEPT that you have not shown that mᵢ 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? rᵢ ---> R, but it seems you're trying to argue bᵢ 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:
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -1
and it is clear that bᵢ is growing in an unbounded fashionry, not converging to b=2. You've
just
got muddled... Note: I don't necessarily agree with this bₓ formula - it looks to be only an
approximation, but I do agree with your aₓ/bₓ 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 aᵢ 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.
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¹⁶ 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:
a₁ = n-1
aₓ = (3*aₓ₋₁)/2 = ... = (n-1)*(3/2)ˣ⁻¹ b₁ = 1
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -1 aₓ/bₓ = (aₓ₋₁)/(bₓ₋₁) = ((n-1)*(3/2)ˣ⁻¹)/(2*(3/2)ˣ⁻¹ -1)
= ... = (n-1)/(2-1/(3/2)ˣ⁻¹)
Interim summary: aₓ/bₓ < aₓ₋₁/bₓ₋₁ and lim{x->∞} aₓ/bₓ = (n-1)/2.
(After eight iterations, aₓ/bₓ is approximately 0.51. Actual iterations
may also include --a and ++b operations, so the actual value of aₓ/bₓ
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
the ratio a/b more decreasing.
3. The proof only needs to show there is a limit. What value a/b converges does
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.
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 ::=
int cop(int n) {
if(n<=1) {
if(n<1) {
throw Error;
}
return 1; // 1 is the iteration endpoint >>>>> }
if(n%2) {
return 3*n+1; // Odd number rule
} else {
return n/2; // Even number rule
}
}
Collatz number: If an integer n, n∈N<1,+1>, after the cop iteration will
eventually calculate to 1 (i.e., cop(...cop(n))=1), then n is a Collatz
number. Otherwise n is not a Collatz number.
Collatz Problem: For each integer n, n∈N<1,+1>, is n a Collatz number? IOW,
the question is equivalent to asking whether the following procedure rcop
terminates or not.
void rcop(int n) {
for(;n!=1;) {
n=cop(n);
}
}
Prop: cop(n) iteration contains no cycle (except for the '1-4-2-1' cycle, since
1 is the termination condition).
If you could prove just this much, you would become famous, at least amongst mathematicians!
Proof: n can be decomposed into n= a+b. rcop(n) can be rewritten as rcop2(n):
void rcop2(int n) {
int a=n,b=0;
for(;a+b!=1;) { // a+b= n in the cop iterative process.
if((a%2)!=0) {
--a; ++b; // Adjust a and b so that a remains even and the
// following algorithm can be performed and remains
// equivalent to cop(n) iteration.
}
if((b%2)!=0) { // Equivalent to (a+b)%2 (because a is even).
a= 3*a;
b= 3*b+1; // 3*(a+b)+1= (3*a) +(3*b+1) >>>>> } else {
a= a/2;
b= b/2;
}
}
}
Let nᵢ, aᵢ, bᵢ represent the values n,a, and b in the iteration.
Assume that the cop(n) iteration is cyclic. The cycle is a fixed-length
sequence, and the process must contain the operations 3x+1 and x/2 (and
the associated operations --a and ++b, unless n is a 2^x number, but such
numbers do not cycle). Let the cyclic sequence of n be: >>>>> n₁, n₂, n₃, ..., nₓ (n=n₁).
Because --a and ++b are continuously interpolated during the cycle, if
I think "interpolated" is not the right word. Not sure exactly what is being claimed, but maybe
this doesn't matter - check my next comment...
aᵢ≠0, then bᵢ and nᵢ=aᵢ+bᵢ will increase infinitely, contradicting the
assumption that nᵢ is cyclic. Therefore, aᵢ=0 must hold during the cycle,
Regardless of your reasoning, it is clear (and easily proved) that as the cycle repeats, aᵢ at
the
same point in the cycle must decrease until it becomes zero. At this point aᵢ remains zero for
all
further i, and no more --a,++b operations occur. (So there can only be finitely many such ops,
but
I agree aᵢ has to become zero, which seems to be what you want to claim.)
but the condition of aᵢ=0 only exists in 1-4-2-1, aᵢ=0 cannot cause the
non-1-4-2-1 cycle of n₁,n₂,n₃,...,nₓ.
That doesn't follow from anything you've said so far. So this proof will not make you famous.
Maybe
you can work on this and fill in the gap. You need an earlier "Prop: If aᵢ=0 then bᵢ <= 4" or
equivalent". Then you can be famous!
It does seem to be the case with numbers I've tried [n up to 30,000,000 ish], that aᵢ only
becomes
zero when we hit the final 1-4-2-1 cycle, so your claim is plausibly /true/, but that's not a
/proof/ in any sense, of course.
Therefore, we can conclude that cop(n) iterations are non-cyclic.
Prop: For any n∈N<1,+1>, the cop iteration operation terminates.
Proof: Since an odd number n will always become even immediately after the
cop iteration, it must undergo n/2 iterations. Therefore, we have an
equivalent rcop3:
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:
a₁ = n-1
aₓ = (3*aₓ₋₁)/2 = ... = (n-1)*(3/2)ˣ⁻¹
b₁ = 1
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -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...
aₓ/bₓ = (aₓ₋₁)/(bₓ₋₁) = ((n-1)*(3/2)ˣ⁻¹)/(2*(3/2)ˣ⁻¹ -1)
= ... = (n-1)/(2-1/(3/2)ˣ⁻¹)
Interim summary: aₓ/bₓ < aₓ₋₁/bₓ₋₁ and lim{x->∞} aₓ/bₓ = (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 aᵢ/bᵢ as non-increasing, so aᵢ/bᵢ 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, aₓ/bₓ is approximately 0.51. Actual iterations
may also include --a and ++b operations, so the actual value of aₓ/bₓ
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 mᵢ,bᵢ,rᵢ or similar. And assume rᵢ-->R (e.g.).
So:
The limit of r+1 = R+1 // with possibility R=0
bᵢ = mᵢ/(rᵢ+1)
lim bᵢ = lim mᵢ / (R+1)
... EXCEPT that you have not shown that mᵢ 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? rᵢ ---> R, but it seems you're trying to argue bᵢ 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:
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -1
and it is clear that bᵢ is growing in an unbounded fashionry, not converging to b=2. You've
just
got muddled... Note: I don't necessarily agree with this bₓ formula - it looks to be only an
approximation, but I do agree with your aₓ/bₓ 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 aᵢ 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.]
..aside from fixing the problems above.
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. >>>>>
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¹⁶ 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:
a₁ = n-1
aₓ = (3*aₓ₋₁)/2 = ... = (n-1)*(3/2)ˣ⁻¹
b₁ = 1
bₓ = (3*bₓ₋₁+1)/2 = ... = 2*(3/2)ˣ⁻¹ -1
aₓ/bₓ = (aₓ₋₁)/(bₓ₋₁) = ((n-1)*(3/2)ˣ⁻¹)/(2*(3/2)ˣ⁻¹ -1)
= ... = (n-1)/(2-1/(3/2)ˣ⁻¹)
Interim summary: aₓ/bₓ < aₓ₋₁/bₓ₋₁ and lim{x->∞} aₓ/bₓ = (n-1)/2.
(After eight iterations, aₓ/bₓ is approximately 0.51. Actual iterations
may also include --a and ++b operations, so the actual value of aₓ/bₓ
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
the ratio a/b more decreasing.
3. The proof only needs to show there is a limit. What value a/b converges does
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?
[...]
A real with infinite precision can hold an irrational?
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.[*]
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.
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.
wij <wyniijj5@gmail.com> writes:Depend on readers understanding.
[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.Agree.
I encourage anyone who feels the need to discuss it to do so there --
or at least not to do so here.
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);
}
}
}
}
On Tue, 2026-01-27 at 19:46 -0800, Tim Rentsch wrote:
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.
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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,096 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 398:09:19 |
| Calls: | 14,036 |
| Calls today: | 2 |
| Files: | 187,082 |
| D/L today: |
2,450 files (1,578M bytes) |
| Messages: | 2,479,082 |