[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:
[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:
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 a
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:s
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 support
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 amnot
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.ups
And it is totally off-topic for C and C++.ÿ The last thing these gro
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:s
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 support
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 amnot
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 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?
On 25/01/2026 12:06, wij wrote:groups
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
pleaseneed is another Olcott.ÿ You also post sometimes on C and C++ -
ic,stick to those topics in this group.
I agree such repeating decimal is rational or not things may be off-top
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'te
understand how mathematics works.ÿ It is much harder to criticise th
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.ou
Please stick to the topic. There are many C/C++ stuff in my post, why y
people always choose to pick non-topic to post???
You know the truth in subconscious?
The Collatz conjecture is totally off-topic here.ÿ Writing a function
for it in C does not make it on-topic.
Now, if you want to talk purely about a C implementation of the Collatz
function, perhaps looking at ways to handle it efficiently for large numbers, that might be an interesting and on-topic here.
If you really had proof of the Collatz conjecture, especially one this
short, it would be sensational - Abel prize or Fields medal level stuff.
ÿ We should be hearing about it in the mainstream news.ÿ It isan
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:
On Sat, 2026-01-24 at 23:06 -0500, James Kuyper wrote:
This generalizes to work with any recurring decimal. When the
recurrence is n digits long (in the above example, n=2), just
multiply by 10^n.
Such arithmetic is called approximation ...
So what is, in your opinion, the exact representation of 4/33 as a
decimal fraction? Marking it as infinitely repeating means that it is
not in any sense an approximation - it is exact.
If it were an
approximation, there would be a finite difference between 4/33 and
0.1212.... How big is that difference? No matter how small of a finite difference you might think it has, going to infinitely many decimal
digits makes the actual difference smaller than that.
Keep in mind that, in the absence of specification to the contrary,
we're talking about the standard real number system, not one of those alternatives that extends the real number system by adding
infinitesimals, such as the surreals or the hyperreals.
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:?...b?b?b?...b?...
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
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,repeating part, consisting
where m ò 0, and b?b?...b? represents the
of n digits, where n > 0. First, separate out the non-repeating part:??b?...b?b?b?...b?...
ÿÿÿ X * 10 ** m = a?a?...a?.b?
from whichb?b?...b?b?b?...b?...
ÿÿÿ X * 10 ** m - a?a?...a? = 0.
ÿÿÿÿÿÿÿ = (b?b?...b? ö 10 ** n) + (b?b?...b? ö 10 **
ÿÿÿÿÿÿÿ = (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 isits lowest terms, it
what makes it ?rational?. If it?s not already in
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.
nI 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-precisio
integers, are you?
You need to prove 4/33 exactly equal to 0.1212..., not approximation.
(I probably regret answering to your post.)the _operations_ *repeat*
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
so the calculated decimals (1 and 2) will also repeat. And sensibly wevon Wahnsinn ist,
need a finite representation (see above) to express that.
ÿÿ Albert Einstein (for example) said: ?Die Definition
ÿÿ immer wieder das Gleiche zu tun und andere Ergebnisse zu erwarten?.
Are you expecting the sequence of decimals differing at some point?Not quite sure what you mean.
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:n.
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 approximatio
.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)
3First
ÿÿÿÿÿ __
ÿÿÿ 0.12ÿÿ orÿÿ 0.1212...
are just finite representations of real numbers; conventions. And 4/3
tis an expression representing an operation, the division. You can jus
o)do that computation (as you've certainly learned at school decades ag
u see that the _operations_ *repeat*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 yo
eso the calculated decimals (1 and 2) will also repeat. And sensibly w
efinition von Wahnsinn ist,need a finite representation (see above) to express that.
ÿÿÿ Albert Einstein (for example) said: ?Die D
sse zu erwarten?.ÿÿÿ immer wieder das Gleiche zu tun und andere Ergebni
.."Are you expecting the sequence of decimals differing at some point?
If not you see that the number represented by the convention "0.1212.
xt/downloadequals to the number calculated or expressed by "4/33".
JanisNot quite sure what you mean.
https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.t
... + non-zero-remainder (True identity. How to deny?)ÿÿÿÿÿÿÿÿÿ 3. 1/3 = 0.333
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.
art youYou cut off non-zero-remainder to stop repeating, so yes, you see the p
onwant to see, i.e. the front part without "...", and forgot the definiti
1"infinitely repeat" is invalidated.
Let n(i) be the repeating number 0.999... The range [n(i),1] remains 1-
youcorrespondence to [0,1] in each step, nothing changed except scale. Or
ty' orsuggests every zooming of the small area of Mandelbrot set will be 'emp
stuniform or 'stop' for some mysterious reason.
I assume you disagee my point in the previous post that every denial mu
.refute Prop 1= Repeating N+N infinitely does not yield natural number
nitely does not yield rational number.ÿÿÿÿÿÿÿ Prop 2= Repeating Q+Q infi
?ÿÿÿ (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)
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:xt/download
...
https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.t
... + non-zero-remainder (True identity. How to deny?)ÿÿÿÿÿÿÿÿÿ 3. 1/3 = 0.333
art youHow 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 p
onwant to see, i.e. the front part without "...", and forgot the definiti
"infinitely repeat" is invalidated.
There's no non-zero-remainder to cut off, nor is there any need to stop repeating. It repeats endlessly, and it is only because of the endless repetition that the remainder is 0. If it ever ended, the remainder
would be non-zero, as you claim.
The flaw is in your property 2, which claims that an infinite sum of
rational numbers is not a rational number. That's unambiguously not the
case in the standard real number system. Your proof of that claim is
based upon asserting that the numerator and denominator of each step in
the infinite series has a larger number of digits (which isn't
necessarily true - but that's unimportant), but ignores the fact that
the limit of an infinite sequence can have smaller numerators and denominators than the terms that make up the sequence.
...nitely does not yield rational number.
ÿÿÿÿÿÿÿ Prop 2= Repeating Q+Q infi
?ÿÿÿ (precisely, positive rational number)ÿÿÿÿÿÿÿÿÿÿÿ?
I dispute the validity of the proof of Prop 2.
On 26/01/2026 21:34, wij wrote:ation.
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 approxim
amesIs that all you want proven; a specific example?
This appears to be as trivial as the more general approach that J
see).gave and that you (for reasons beyond me) don't accept (or don't
.First
ÿÿÿÿÿÿ __
ÿÿÿÿ 0.12ÿÿ orÿÿ 0.1212..
4/33are just finite representations of real numbers; conventions. And
justis an expression representing an operation, the division. You can
s ago)do that computation (as you've certainly learned at school decade
0in individual steps, continuing each step with the remainder
ÿÿÿÿ 4/33 = 0ÿÿÿÿ =>
s point you see that the _operations_ *repeat*ÿÿÿÿ 40/33 = 1ÿÿÿ => 0.1
ÿÿÿÿ remainder 7
ÿÿÿÿ 70/33 = 2ÿÿÿ => 0.12
ÿÿÿÿ remainder 4
ÿÿÿÿ 40/33 = 1ÿÿÿ and at thi
ly weso the calculated decimals (1 and 2) will also repeat. And sensib
??Die Definition von Wahnsinn ist,need a finite representation (see above) to express that.
ÿÿÿÿ Albert Einstein (for example) said: ?
re Ergebnisse zu erwarten?.ÿÿÿÿ immer wieder das Gleiche zu tun und ande
t?Are you expecting the sequence of decimals differing at some poin
212..."If not you see that the number represented by the convention "0.1
en.txt/downloadequals to the number calculated or expressed by "4/33".
JanisNot quite sure what you mean.
https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-
= 0.333... + non-zero-remainder (True identity. How to deny?)ÿÿÿÿÿÿÿÿÿÿ 3. 1/3
toHow would you deny it, and call the cut-off 'equation' identity?
Have you ever heard of the concept of "limits" ?ÿ You might want
y to belearn something about them before embarrassing yourself.
What do you know about the concept of "limits"? (You invented? Don't tr
liated himselfthe next one, again. I remember the other expert in this forum has humi
her reply,once, not sure which one, if I can safely predict. And I ignored the ot
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 Itood
remember my history correctly).ÿ But I /learned/ about them - unders
them, understood proofs about them, understood how to use them.w to
And more importantly, I learned how mathematics works.ÿ I learned ho
read proofs, and how to write proofs.ÿ So I know writing down some
statement and claiming "True identity.ÿ How to deny?" does notu
constitute a proof.
But I suspect any rational argument will fall on deaf ears here.ÿ Yo
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:
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 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.
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:
eI have just finished the script. Any defect,insufficiency, or typo?
------------------
This file is intended a proof of Collatz Conjecture. The contents may b
t/downloadupdated anytime. https://sourceforge.net/projects/cscall/files/MisFiles/Coll-proof-en.tx
t/downloadThe text is converted by google translate with modest modification from https://sourceforge.net/projects/cscall/files/MisFiles/Coll-proof-zh.tx
------Reader might want to try different translator or different settings.
-----------------------------------------------------------------------
? throw Error;Collatz function ::=
ÿÿÿÿÿÿ int cop(int n) {
ÿÿÿÿÿÿÿÿ if(n<=1) {
ÿÿÿÿÿÿÿÿÿÿ if(n<1) {
ÿÿÿÿÿÿÿÿÿÿÿ?
ÿÿÿÿ // 1 is the iteration endpointÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿÿÿ return 1;
+1; // Odd number ruleÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿ if(n%2) {
ÿÿÿÿÿÿÿÿÿÿ return 3*n
;ÿÿ // Even number ruleÿÿÿÿÿÿÿÿ } else {
ÿÿÿÿÿÿÿÿÿÿ return n/2
tion willÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿÿÿ
Collatz number: If an integer n, n?N<1,+1>, after the cop itera
)=1), then n is a Collatzÿÿÿÿ eventually calculate to 1 (i.e., cop(...cop(n)
?ÿÿÿÿ number. Otherwise n is not a Collatz number.
ÿÿÿÿÿÿÿÿÿÿÿ?
number? IOW,Collatz Problem: For each integer n, n?N<1,+1>, is n a Collatz
he following procedure rcopÿÿÿÿ the question is equivalent to asking whether t
;ÿÿÿÿ terminates or not.
ÿÿÿÿÿÿ
ÿÿÿÿÿÿ void rcop(int n) {
ÿÿÿÿÿÿÿÿ for(;n!=1;) {
ÿÿÿÿÿÿÿÿÿÿ n=cop(n)
e, sinceÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿ }
ÿÿÿÿÿÿ
Prop: cop(n) iteration contains no cycle (except for the '1-4-2-1' cycl
gst mathematicians!ÿÿÿÿÿ 1 is the termination condition).
If you could prove just this much, you would become famous, at least amon
ewritten as rcop2(n):ÿÿ Proof: n can be decomposed into n= a+b. rcop(n) can be r
+b= n in the cop iterative process.ÿÿÿÿÿÿ
ÿÿÿÿÿÿ void rcop2(int n) {
ÿÿÿÿÿÿÿÿ int a=n,b=0;
ÿÿÿÿÿÿÿÿ for(;a+b!=1;) { // a
=0) {ÿÿÿÿÿÿÿÿÿÿ if((a%2)!
? --a; ++b;ÿ // Adjust a and b so that a remains even and theÿÿÿÿÿÿÿÿÿÿÿ?
?ÿÿÿÿÿÿÿÿÿÿÿ // foÿÿÿÿÿÿÿÿÿÿÿ?
?ÿÿÿÿÿÿÿÿÿÿÿ // eqÿÿÿÿÿÿÿÿÿÿÿ?
=0) { // Equivalent to (a+b)%2 (because a is even).ÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿÿÿ if((b%2)!
? a= 3*a;ÿÿÿÿÿÿÿÿÿÿÿ?
? b= 3*b+1;ÿÿÿ // 3*(a+b)+1= (3*a) +(3*b+1)ÿÿÿÿÿÿÿÿÿÿÿ?
? a= a/2;ÿÿÿÿÿÿÿÿÿÿ } else {
ÿÿÿÿÿÿÿÿÿÿÿ?
? b= b/2;ÿÿÿÿÿÿÿÿÿÿÿ?
?? represent the values n,a, and b in the iteration.ÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿ }
ÿÿÿÿÿÿ Let n?, a?, b?
s cyclic. The cycle is a fixed-lengthÿÿÿÿÿÿ Assume that the cop(n) iteration i
tain the operations 3x+1 and x/2 (andÿÿÿÿÿÿ sequence, and the process must con
++b, unless n is a 2^x number, but suchÿÿÿÿÿÿ the associated operations --a and
lic sequence of n be:ÿÿÿÿÿÿ numbers do not cycle). Let the cyc
, n?, ..., n? (n=n?).ÿÿÿÿÿÿÿÿ n?, n?
ly interpolated during the cycle, ifÿÿÿÿÿÿ Because --a and ++b are continuous
I think "interpolated" is not the right word.ÿ Not sure exactly whatis being claimed, but maybe
this doesn't matter - check my next comment...? and n?=a?+b? will increase infinitely, contra
ÿÿÿÿÿÿ a??0, then b?
ic. Therefore, a?=0 must hold during the cycle,ÿÿÿÿÿÿ assumption that n? is cycl
Regardless of your reasoning, it is clear (and easily proved) that as thecycle 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 onlybe finitely many such ops, but
I agree a? has to become zero, which seems to be what you want toclaim.)
0 only exists in 1-4-2-1, a?=0 cannot cause theÿÿÿÿÿÿ but the condition of a?=
?,n?,...,n?.ÿÿÿÿÿÿ non-1-4-2-1 cycle of n?,n
That doesn't follow from anything you've said so far.ÿ So this proofwill 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!sh], that a? only becomes
It does seem to be the case with numbers I've tried [n up to 30,000,000 i
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.p(n) iterations are non-cyclic.
ÿÿÿÿÿÿ Therefore, we can conclude that co
.Prop: For any n?N<1,+1>, the cop iteration operation terminates
iately after theÿÿ Proof: Since an odd number n will always become even immed
iterations. Therefore, we have anÿÿÿÿÿÿ cop iteration, it must undergo n/2
=0) {ÿÿÿÿÿÿ equivalent rcop3:
ÿÿÿÿÿÿ void rcop3(int n) {
ÿÿÿÿÿÿÿÿ int a=n,b=0;
ÿÿÿÿÿÿÿÿ for(; a+b!=1;) {
ÿÿÿÿÿÿÿÿÿÿ if((a%2)!
? --a; ++b;ÿÿÿÿÿÿÿÿÿÿÿ?
sure point Aÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿÿÿ // a/b mea
=0) {ÿÿÿÿÿÿÿÿÿÿ if((b%2)!
? a= 3*a;ÿÿÿÿÿÿÿÿÿÿÿ?
? b= 3*b+1;ÿÿÿÿÿÿÿÿÿÿÿ?
, `++b` process. Assume that each oddÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿÿÿÿ a= a/2;
ÿÿÿÿÿÿÿÿÿÿ b= b/2;
ÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿ }
ÿÿÿÿÿÿ Let n be odd and there be no `--a`
even operation (the actual ratio is 1.5ÿÿÿÿÿÿ operation is paired with only one
istical value; the decisive inferenceÿÿÿÿÿÿ even operations, but 1.5 is a stat
of 1). Then, at measurement point A,ÿÿÿÿÿÿ can only take the guaranteed value
??)/2 = ... = (n-1)*(3/2)???ÿÿÿÿÿÿ we have:
ÿÿÿÿÿÿ a? = n-1
ÿÿÿÿÿÿ a? = (3*a??
??+1)/2 = ... = 2*(3/2)??? -1ÿÿÿÿÿÿ b? = 1
ÿÿÿÿÿÿ b? = (3*b??
This is just an approximation, not exact.ÿ It is not hard to get theexact value, since you seem to
know about geometric series...???)/(b???) = ((n-1)*(3/2)?
ÿÿÿÿÿÿ a?/b? = (a?
? = ... = (n-1)/(2-1/(3/2)???)ÿÿÿÿÿÿÿÿÿÿÿ?
?? < a???/b??? and lim{ÿÿÿÿÿÿ Interim summary: a?/b?
ì} a?/b? = (n-1)/2.s will include multiple
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 sequence
even ops and/or --a ops.??/b? will reach zero (and stay there) or
OTOH all sequences have a?/b? as non-increasing, so a?
converge to some other limit value >= 0.ÿ In the latter case, youhave 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?)s, a?/b? is approximately 0.51. Actual iterations
ÿÿÿÿÿÿÿÿ (After eight iteration
--a and ++b operations, so the actual value of a?/b?ÿÿÿÿÿÿÿÿÿ may also include
ster than the formula)ÿÿÿÿÿÿÿÿÿ will converge fa
It must converge, but not necessarily to (n-1)/2 ...rong!
After this point your argument seems to lose focus, and the notation is w
b = a/b+1 = r+1ÿÿÿÿÿÿ Let r = a/b, then n/b = (a+b)/
? These values are changing asÿÿÿÿÿÿ => b = (a+b)/(r+1)
ok this is simple algebra for any /specific/ iteration value of n,a,b.?
we iterate...not terminate, and m is one of the
ÿÿÿÿÿÿ Assuming the cop(n) iteration does
Therefore, we can derive theÿÿÿÿÿÿ number in the iteration sequence.
+ 1 = (m+1)/2ÿÿÿÿÿÿ following:
ÿÿÿÿÿÿ => b = m/(r+1)
True for m,b,r for /that specific iteration/.
ÿÿÿÿÿÿ => The limit of r+1 = (m-1)/2
m)ÿÿÿÿÿÿ => b = (2*m)/(m+1) = 2/(1+1/
east it is known that m will be a largeÿÿÿÿÿÿ => b = 2 (the limit of b. At l
?ÿÿÿÿ number)ÿÿÿÿÿÿÿÿÿÿÿ?
No that's not right - you're mixing values of m,b,r with those for lateriterations 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 rconverges).ÿ That is,
unless you find a way to fix your proof to prove otherwise...cop(), best to call the
To avoid confusing m,b,r as you've defined them with later iterations of
values for later iterations m?,b?,r? or similar.ÿ And assume r?-->R (e.g.).
So:ÿ // with possibility R=0
ÿÿÿ The limit of r+1 = R+1ÿÿÿÿÿ
ÿÿÿ b? = m?/(r?+1)t line is nonsense - we only use
ÿÿÿ lim b? = lim m? / (R+1)
... EXCEPT that you have not shown that m? converges, so that las
'lim' symbol when we the limits are known to exist...
cal value is not important),ÿÿÿÿÿÿ Since there is a limit (the numeri
??? a limit to what?ÿ r? ---> R, but it seems you're tryingto 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, notconverging 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 [withyour given assumptions].
ber of iterations of --a, a willÿÿÿÿÿÿ the
ÿÿÿÿÿÿ iteration involves an infinite num
ration cannot fail to meet theÿÿÿÿÿÿ inevitably become zero, so the ite
more --a operations, so there can'tÿÿÿÿÿÿ iteration termination contion.
That is also not right - once a? becomes zero, there will be /no
be infinitely many of them!rspersed
Regardless:
1.ÿ IF there are infinitely many iterations of --a, they can be inte
ÿÿÿÿ with a *= 3 operations, so it does not follow(just from what you've said)
ÿÿÿÿ that a /must/ become zero.has been
2.ÿ If a does become zero, it does not follow that the 1-4-2-1 loop
ÿÿÿÿ encountered, unless you have some argument to prove that.ÿ [This is
ÿÿÿÿ the same problem as with your earlier "no cycles" proof.]
ven operation (a finite number of times)ÿÿÿÿÿÿ If n is even, then repeating the e
thout affecting the termination resultÿÿÿÿÿÿ cop(n) will yield an odd number wi
oposition is proved.ÿÿÿÿÿÿ as stated above. Therefore, the pr
..aside from fixing the problems above.
Mike.
On Sun, 2026-01-25 at 11:25 -0500, James Kuyper wrote:ystem'.
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 s
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)I agree with this value (n-1)/2, /given your assumptions/ :
ÿÿÿÿÿÿÿÿÿÿÿÿ = ... = (n-1)/(2-1/(3/2)???)
ÿÿÿÿÿÿ Interim summary: a?/b? < a???/b??? and lim{x->ì} a?/b? = (n-1)/2. >>
-ÿÿ 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.
Will you elaborate precisely?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.
Confirmed, thanks. "b has limit" is flawed.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...
??? a limit to what?ÿ r? ---> R, but it seems you're trying to argue b? converges?ÿ That's not
ÿÿÿÿÿÿÿ Since there is a limit (the numerical value is not important), >>>>
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:
[329 lines deleted]
Just a gentle reminder that this discussion, though it occasionally
includes something that looks like C code, is not about C.
There's a related thread about the Collatz Conjecture in comp.theory.
I encourage anyone who feels the need to discuss it to do so there --
or at least not to do so here.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 24:11:06 |
| Calls: | 117 |
| Calls today: | 117 |
| Files: | 368 |
| D/L today: |
560 files (257M bytes) |
| Messages: | 70,913 |
| Posted today: | 26 |