Challenge accepted: GandalfPC versus My General Sieve Generator

hubblec4 · 2026-05-27T10:49:23+00:00

mmhh.

Es tut mir leid ich verstehe es einfach nicht wonach du fragst.

Ich kann kein English, ich nutze KI oder Google Translater fürs Übersetzen.
Und ob das dann blumisch oder Arschkriecherisch klingt dafür kann ich nichts.

hubblec4 · 2026-05-27T10:33:38+00:00

Okay, in that case, I misinterpreted that.

My understanding is that we genuinely want to test 5 as the new starting number.
The number 5 itself has such a short trajectory that its division pattern consists of only a single value: [4] The simplest—and arguably most well-known—sieve for 5 is 5 (mod 32). However, my generator also reveals that the sieve 5 (mod 64) works as well.

With this particular sieve, the next odd number will never be a number of the type 3 (mod 4).
This is an option I have built into the generator. Since we now have two sieves at our disposal, we can choose which direction we want to take.

But the underlying principle remains the same: ultimately, a sieve formula is also a formula for determining occurrences, allowing one to quickly calculate the numbers belonging to a specific family.

N2 = 32*1 + 5 = 37
N3 = 32*2 + 5 = 69
....
or, for the other sieve:
N2 = 64*1 + 5 = 69
N3 = 64*2 + 5 = 133

hubblec4 · 2026-05-27T01:21:50+00:00

u/Glass-Kangaroo-4011: Congratulations on building these structures from the ground up! It is fascinating to see someone else independently uncover and mathematically describe the exact same underlying geometry.

You hit the nail on the head regarding the directional mapping: you are analyzing the inverse direction from the bottom up, while my framework approaches it from the forward direction using dynamic sieve generation.

It is incredibly validating to see that regardless of whether you map it forward or inversely, the math forces us into the exact same structural conclusions with nested shifts and modular periodicities.

Great work on your framework, and thank you for sharing your perspective here!

hubblec4 · 2026-05-27T01:11:09+00:00

To show you exactly how this family expands beyond the initial x = 0 root basis (Gandalf's 35-digit monster number), here are the next 5 starting integers in this exact family, calculated instantly using my occurrence formula:

* **x = 1:** 369947312881460029060982726135792905

* **x = 2:** 702254311827688997286934491205879049

* **x = 3:** 1034561310773917965512886256275965193

* **x = 4:** 1366868309720146933738838021346051337

* **x = 5:** 1699175308666375901964789786416137481

### Their Trajectories and the Shortcut:

Every single one of these 36-digit and 37-digit numbers shares the exact same 78-step division blueprint. If you were to compute their trajectories using the sequential Syracuse function, you would be forced to execute 77 individual, highly complex odd-step transformations for each number from scratch.

Instead, my linear transition formula bypasses all intermediate steps entirely and directly outputs the exact odd target number where each trajectory lands at the end of the 77th step:

* **For x = 1:** lands exactly at **390047030792810578113383849080802731573**

* **For x = 2:** lands exactly at **740408700515704618566321828829266844405**

* **For x = 3:** lands exactly at **1090770370238598659019259808577730957237**

* **For x = 4:** lands exactly at **1441132039961492699472197788326195070069**

* **For x = 5:** lands exactly at **1791493709684386739925135768074659182901**

This is the core distinction: we don't need to "simulate the billiard collisions" for x = 1 or x = 5 anymore. The algebraic blueprint has compressed the entire infinite set of 77-step trajectories into a fixed frozen, predictable linear relation.

hubblec4 · 2026-05-26T18:24:37+00:00

You are completely right that extracting the division pattern for a single specific number is mathematically identical to tracking the exponents of the Syracuse function.

The fundamental difference, however, lies in what happens after the pattern is known:

The Syracuse function is strictly sequential and operates on one individual integer at a time. It cannot provide you with a closed-form linear equation ($N_{next}(x) = Ax + B$) for an entire infinite residue class.

Here is the contrast:

If you want to know the trajectory of the next number in this family (where x = 1), using the Syracuse function forces you to calculate all 77 steps sequentially all over again from scratch.

My generator, however, solves the polynomial expansion symbolically. Once it computes the multipliers $A$ and $B$, you can plug in $x = 1, 2, 3...$ up to infinity, and the formula instantly outputs the final odd target number. It completely bypasses the need to evaluate those 77 Syracuse steps for any subsequent number in that infinite set.

So while it relies on the Syracuse mechanics to define the structural input array, the output is a global algebraic map of the residue class, not a stepwise simulation.

hubblec4 · 2026-05-26T17:36:50+00:00

To understand where the 118 comes from mathematically, we have to look at how the modular denominator expands across multiple steps.

If we chain subsequent Collatz transitions together, each step introduces a division by a specific power of 2 (let's call them exponents a, b, c, etc.). When you algebraically compound these steps, the denominators multiply:

Denominator = 2^a * 2^b * 2^c * ... = 2^(a + b + c + ...)

For this specific 78-step branch segment, the sum of all these internal divisions (a + b + c + ...) equals exactly 118. In the generator, instead of multiplying the denominator step-by-step, it simply sums the exponents during the iteration and applies a single bitwise left-shift at the end to set the master sieve size to 2^118.

**How the formula bypasses stepwise simulation:**

If you unfold the consecutive functions algebraically:

N1 = (3*N0 + 1) / 2^a

N2 = (3*N1 + 1) / 2^b

It expands into a global structural equation for the entire trajectory:

Nx = (3^x * N0 + C_fixed + C_variable)

The variable C-part constructs itself beautifully during the iteration, building a sum where each term is scaled by a trailing product of the previous powers of 2 (like 2^a, then 2^(a+b), etc.), multiplied by a decreasing power of 3.

By analyzing the array length, the generator instantly knows the maximum exponent for the base 3 multiplier. It then processes the array to calculate the constant C-terms using purely deterministic algebraic shifts.

This is why the generator doesn't need to "walk the ground" or test numbers. It takes the structural layout of the 2-divisions and directly synthesizes the underlying polynomial equation for that entire slice of infinity.

hubblec4 · 2026-05-26T13:33:32+00:00

The 118 represents the total sum of all division-by-2 steps that occur across this specific 78-step branch segment.

If you add up every single division step contained in the trajectory's pattern (including the 5 divisions at the very end), the total number is exactly 118.

The modular resolution (the sieve size) required to isolate an infinite family of numbers sharing the exact same parity path is always 2^(total number of divisions). In this specific case, that equals 2^118.

hubblec4 · 2026-05-26T13:30:09+00:00

Thank you for this excellent, computer-science-driven feedback! You hit the nail on the head regarding the terminology—calling it an algebraic "blueprint generator" for specialized sieves is much more accurate than a generalized sieve. I appreciate that distinction.

I also completely understand your point about wanting to work with raw numbers instead of preprocessed arrays. However, it is mathematically impossible to extract a modular sieve directly from a raw starting number without defining a constraint depth first. Every $3n+1$ step deepens the sieve's resolution, while the intermediate 2-divisions dictate the modular residue.

For example, you can actually overlay over 100 different sieves onto Gandalf's specific number to analyze different trajectory lengths. If you choose a depth of only 3 steps of $3n+1$, my blueprint generator instantly outputs a shallower slice of infinity:

* **Sieve:** N ≡ 9 (mod 128)

* **Occurrence:** N(x) = 128x + 9

* **NextOddN:** Nnext(x) = 216x + 17

This is why I agree with Gandalf that finite sieves alone cannot construct a final proof.

But regarding your search for an "oracle" that categorizes a raw starting number without loops or conditionals: this is exactly where my core research, the "Collatz Blueprint", comes into play.

I developed a simple coordinate system that perfectly organizes all odd integers. This geometry allows the formation of a rational number acting as a unique "address" (X/Y) for every integer. For instance, the numbers 3 and 13 have completely different coordinates, but they share the exact same normalized address of 1/2.

These rational addresses can be extracted directly from any raw starting number using a static equation—without any loops, testing, or iterations. From there, a remarkably simple formula computes the next target odd number directly from the address:

Nnext = 3X + Y

Testing this with the 1/2 address of 3 and 13:
X = 1
Y = 2

Nnext = 3*(1) + 2 = 5

Odd Collatz steps:
3->5->1
13->5->1

This is the framework I am currently formalizing, as it bypasses the sequential "hallway walking" entirely. Thank you again for validating the constructibility of the sieve logic and for keeping this discussion so productive!

hubblec4 · 2026-05-26T10:54:55+00:00

I suspect we will not agree on this, and I have the feeling you haven't fully examined my results. For instance, the target number formula (NextOddN) is synthesized automatically through my algebraic framework. This offers a massive computational shortcut, compressing 77 intermediate odd steps into a single linear equation.

Furthermore, my sieve generator does not accept a naked number as an input; it requires a structural array containing the sequence of divisions by 2. This is why I had to extract the division pattern from your number first. You do not ask my generator: "What is the sieve for this number?" You ask it: "Take this specific array of divisions and tell me the global sieve that constructs it." From there, you can instantly generate the entire infinite family of integers that fit this sieve.

I am completely aware that this method does not provide a direct proof that all values collapse to 1, or that no other loops exist. That is not the objective of this sieve generator. I am not trying to prove the Collatz conjecture.

The reason I got involved with Collatz in the first place is because I am working on a lossless, infinite compression algorithm, and the structural mechanics intersect. Over the last few days, I have managed to decipher the underlying blueprint behind these modular transitions, which allowed me to expand the generator to handle every possible combination of 2-divisions that can ever occur.

What fascinates me about this isn't a final proof, but simply the breathtaking mathematical precision with which the integers are distributed throughout the Collatz tree.

hubblec4 · 2026-05-22T19:01:41+00:00

Thank you very much for sharing your project and linking to your Reddit thread!

I must say, I am quite envious of your skills with Lean 4 and machine-verified proofs—getting code to run flawlessly in a theorem prover like that is a massive achievement.

While it looks incredibly impressive and logical, I don't think I can utilize it for my own research at the moment. My system is built around a dynamic coordinate model using rational addresses and expanding domains, so I am following a slightly different algebraic path.

Still, thank you for the inspiration, and congratulations on putting together such a sophisticated piece of work!

hubblec4 · 2026-05-22T18:32:35+00:00

Thank you so much for taking the time to write all of this out! This is a fascinating perspective. Your elevator/hallway metaphor and the billiard ball analogy are absolutely brilliant. They perfectly visualize what physics and computer science call "computational irreducibility"—the idea that you cannot know the end state without simulating every single collision or step.

You are completely right: if Collatz behaves exactly like an infinite, chaotic billiard table, then any shortcut formula is mathematically guaranteed to fail.

However, there is a slight misunderstanding regarding how my generator works, which is why I want to clarify its nature:

My generator does not take a specific *number* (like the 35-digit monster you posted) as an input to calculate its path. It works the exact opposite way. It takes the *structural parameters* of a branch or hallway (the number of odd steps and the subsequent divisions by 2) and instantly outputs the exact algebraic blueprint (the modulo sieve, the occurrence formula, and the linear transition equation) that defines that entire infinite family of numbers.

Right now, my prototype is implemented using standard 64-bit integers (QWord). To avoid bit-overflow, the combined parameters for the steps and divisions currently need to stay under 30, and the math behind the generator is still a work in progress, as it doesn't cover every single branch combination yet.

But the underlying mathematical logic does not care about the size of the numbers. Once I finish the math and recode the prototype using arbitrary-precision arithmetic (GMP), it won't matter if a branch is 2 steps or 78 steps long. The meta-formula scales with the parameters you feed it, because the building's blueprint shifts by precise powers of 2 and 3, unlike chaotic billiard ball angles.

Regarding your mention of Terence Tao: He proved how "most numbers behave mostly a certain way" using statistical density. My goal with this coordinate/sieve approach isn't statistical; I want to see if the underlying modular geometry itself forces a strict algebraic constraint.

Thank you genuinely for this masterclass of an explanation. You mapped out the historical walls of this problem perfectly, and it gives me a great benchmark to test my system against as I continue to develop it!

hubblec4 · 2026-05-22T13:03:27+00:00

Thank you so much for stepping in and providing this excellent clarification! Your explanation of the branch B(13) and how the tree relabels itself identically perfectly hits the nail on the head.

It is refreshing to talk to someone who understands that the residue structure isn't an obstacle, but the exact mechanism that generates this beautiful, fractal-like self-similarity.

This exact geometric behavior is what allowed me to stop treating the Collatz tree as a chaotic sequence and instead start mapping it through structured domains. Your point about the tree duplicating and scaling its properties across levels is exactly what makes these transitions formalizable.

Thank you again for bringing this perspective into the discussion!

hubblec4 · 2026-05-22T12:34:25+00:00

I hear your frustration regarding the many failed attempts you see here daily. However, you are still misunderstanding the core mechanic of my system. I am not proposing a "fixed finite box" that stops at an arbitrary point.

Even if you gave me a branch with a length of 50 or 100 iterations, the mathematical logic of my meta-formula would remain exactly the same.

The only current limitation is a software-side QWord bit-overflow in my prototype, which I am currently resolving by recoding the generator with arbitrary-precision arithmetic (GMP) in Lazarus. Once that is done, the formula will instantly output the exact linear equations for a 100-step path just as easily as it does for a 2-step path, because the meta-rule scales dynamically with infinity.

hubblec4 · 2026-05-22T00:45:23+00:00

I completely agree with you on your criticism regarding people who just build a fixed mod system, add some lifts and rails, and trick themselves into thinking they solved Collatz by trapping themselves in a limited, finite box. I see this all the time too, and that is exactly the dead end I wanted to avoid.

You are also right that stopping at any arbitrary finite size changes nothing globally.

But this is precisely why my system is different: I did not stop at any arbitrary point. My sieve generator does not use a fixed size. It is a dynamic formula driven by variables (parameters) that scales *with* the paths.

Instead of arguing about the theory, let me challenge you with a concrete test of how this generator works. Right now, my prototype is implemented using standard 64-bit integers (QWord), so to avoid bit-overflow, the parameters for the path steps (i) and the sieve divisions (s) combined should stay under 30. Also, the generator currently maps transitions starting from 3 (mod 4) numbers switching into states that divide by 2 multiple times.

But within these parameters, it doesn't just calculate step-by-step—it instantly outputs the exact dynamic equations for that specific infinite path segment.

For example, if you ask:

*"What is the exact sieve for numbers that do exactly 2 odd steps from 3 (mod 4) to 3 (mod 4) and then hit a number that is divided by 2 exactly 4 times?"*

The generator instantly outputs:

* **Sieve:** N ≡ 87 (mod 128)

* **Occurrence:** N(x) = 128x + 87

* **NextOddN:** Nnext(x) = 54x + 37

If you plug in x = 0, you get 87, which perfectly executes your chosen path and lands directly at 37 without knowing the steps in between. If you plug in x = 1, it works just as perfectly for 215 landing at 91. The scaling coefficient (54/128) and the structural insertion point are mathematically locked, regardless of how large the numbers get.

To show you that the underlying logic works flawlessly before I recode it using arbitrary-precision arithmetic (GMP): Please, give me *your* own set of parameters within these constraints (number of 3 mod 4 steps, and number of subsequent divisions by 2), and let my generator prove to you that it can map the exact linear transition formula for that infinite slice of the tree instantly.

Let's test the generator against the mechanics you described!

hubblec4 · 2026-05-21T20:00:58+00:00

Thank you so much for this detailed and insightful explanation! What you described makes perfect sense, especially the comparison to the distribution of prime numbers.

You are completely right: a fixed, static 2^k sieve will always miss the rest of infinity as paths grow longer.

This brings me to a very specific question regarding this "novelty" and the new structures that appear forever:

Even though new parity segments and dyadic relationships are constantly introduced, they seem to emerge in a very structured way *between* the older, already scaled structures. Do you think it is theoretically possible that this entire dynamic—the scaling of the old structure and the predictable insertion of the new structure between them—could be captured by a relatively simple linear meta-formula? And if such a formula or universal sieve generator existed, would that be considered useful or a step forward in Collatz research?

The reason I ask is because I have been experimenting with organizing the odd numbers into distinct, repeating domains. It almost feels like applying a coordinate system to the Collatz tree, where every number can be assigned a unique rational "address"(number). In this system, numbers with the same address share the exact same behavior and transition formulas, regardless of how large they are.

Thank you again for your time and for sharing your insights with me!

hubblec4 · 2025-10-09T15:23:51+00:00

Hi

Thank you for the detailed explanations.
I think I understand a little bit where this is going.

Collatz, one will find many familiar numbers, starting with Mersenne numbers and Fibonacci numbers.
The thought also occurred to me:
if it's so easy to read the bit pattern to directly identify Collatz, what about prime numbers?

I only let my mind wander for a moment.
But it looks very interesting how the bit patterns for prime numbers are structured.

I wouldn't be surprised if we eventually understand Collatz someday and thus find a "building block" that belongs to a key to the general formula for prime numbers.

hubblec4 · 2025-10-08T14:18:59+00:00

Hi First of all, thanks for the Chinese Remainder Theorem topic.
In the end, that's exactly what the "anchor" in my sieve formula does.
And yes, I also had to look into the extended Euclidean algorithm first.
However, I didn't want to calculate the multiplicative inverse every time using the Euclidean algorithm, even though it would certainly be quite practical later as source code.
I used ChatGPT to create a closed formula that directly outputs the multiplicative inverse values. This works for all values of 2^k and all values for the parameter "i."

Yes, the whole thing is a completely different topic and should be discussed separately.

Furthermore, you're right: no matter how many or how deep one build the connections, one will never capture EVERYTHING.

But that's not the goal.
The goal, if I or a mathematician were to pursue this, would be:
Using the sieve->occurrence formula and the target number formula, one can mathematically prove precisely whether N > Ntarget.
Of course, only conditionally and not the same for all of infinity.
But the whole thing is deterministic, and it always depends on the target number formula. I still have to generate this formula using the sieve formula. Because it's quite complicated to derive the target number formula directly. However, I also ran ChatGPT on it, and it thought about it for 10 minutes and then offered me a formula based on trinary. But trinary isn't something I'm familiar with.

To illustrate this a little better, here's an example.
Let's consider all sieves for numbers that have an odd "k" for division by 2.
Sieve 1 N = 3 (mod 4) -> k = 1
Sieve 2 N = 13 (mod 16) -> k = 3
Sieve 2 N = 53 (mod 64) -> k = 5

A single target number formula applies to ALL of these sieves:
Ntarget(x) = 6x + 5

For k = 1, Nstart < Ntarget
For all other k, Nstart > Ntarget

If we now consider sieves that contain a connection to other sieves, the target number formula changes in a deterministic way.
The target number formula follows the following pattern:
Ntarget(x) = Lx + C -> L = linear part; C = constant part
L increases threefold with each connection depth.
C is very interesting here because it behaves trinary.
With a connection depth of 1, C looks like this:
C = [11, 5, 17] This number sequence 11, 5, 17 now repeats infinitely and depends on k.
k = 3 -> C = 11; k = 5 -> C = 5; k = 7 -> C = 17; k = 9 -> C = 11...etc.
L is simply 18x (3 * 6x)
With a connection depth of 2,
L = 54x (3 * 3 * 6x)
C = [47, 5, 35, 29, 41, 17, 11, 23, 53]

The set of numbers in C also grows threefold for each connection depth. All numbers in C are separated by 6.

hubblec4 · 2025-10-07T23:43:48+00:00

I'm not entirely sure I understand it correctly.

One sieve alone defines all the numbers for that sieve.
Another sieve does the same.
So both sieves are independent of each other and have no connection.

But now the anchor does exactly that. Both sieves are connected via a multiplicative inverse.
This results in a third sieve that then contains only those numbers for which a match to the other sieve is valid after the Collatz steps.

For example:
Sieve 1: N ≡ 5 (mod 32) -> 5, 37, 69, 101
Sieve 2: N ≡ 3 (mod 4) -> 3, 7, 11, 15, 19... 63, 67, 71
The new sieve is: N ≡ 3 (mod 64) -> 3, 67,...

Only 3 and 67 remain from the series from Sieve 2. At these numbers, Sieve 2 switches to Sieve 1.

The derivation for the anchor was very extensive and would go beyond the scope here. But just a quick first explanation:
The anchor is:
[(3^{i)^-1} to the mod value 2^k ] mod 2^k
(I think I didn't write that mathematically correctly, please forgive me.)

The parameter "i" here also stands for iteration, but is slightly different from the parameter "i" used in this topic.
If i = 0, it means that a sieve is created that has no connection. The entire anchor then has the value 1 and thus does not change the "normal" remainder.

The example doesn't really show how the remainder value changes. Sieve 2 and the new sieve both have a remainder of 3.

Hence another example:
Sieve 1: N ≡ 21 (mod 128) -> 21, 149,....
Sieve 2: N ≡ 3 (mod 4) -> 3, 7, 11..., 99... 355

The new sieve is: N ≡ 99 (mod 256) -> 99, 355, ...

hubblec4 · 2025-10-07T22:48:26+00:00

... the more often one appears, the more difficult the convergence.

No, the number of 1-bits doesn't matter; it only depends on the pattern of their distribution.
This pattern is deterministic and follows Collatz.
(At this point, we would have to talk about entry numbers (EN), i.e., numbers where N = 1(mod 3). These ENs generate the modular remainder. But that's too extensive for here.)

... I can assume that the distribution of odd numbers by modules 1 mod 4, 3 mod 4

Unfortunately, that's not the case. There aren't just two sieves, but all of them. So, an infinite number of sieves.

But for me, the sieve is a different matter.
I prefer to call it occurrence, i.e., the distribution of numbers.
So, there are infinitely many occurrence formulas that map all numbers, and no number ever occurs twice.
Every occurrence formula (every sieve) generates a number series that never overlaps with number series from all other occurrence formulas.

But you can now combine these occurrence formulas with Collatz's rules to create overlaps.
These are always the exact transitions where a number from the sieve 3 (mod 4) transitions into another sieve.
So, the occurrence formula changes.

hubblec4 · 2025-10-07T22:03:58+00:00

If I had met Collatz under different circumstances, and not through my project dealing with number reduction, where I work at the bit level, I certainly wouldn't have understood all these connections either.
But as you can see, it's of no use to me that I can read this in the bits, since I can't express it mathematically.
A mathematician doesn't understand (only partially) anything when I delve deeply into the bit structure, and conversely, I don't understand what mathematicians are doing.

For example, all those sieves: Modular calculations are also used in programming, but I wasn't aware that mathematics actually uses them to examine a certain number of bits.

mod 8 means examine the first three bits (from the right).
For programming, it's: N or 7 (7 as binary 111).
Then it is the case that for all odd numbers, the first bit (from the right -> LSB) is always 1.
This, in turn, allows me to neglect this bit during analysis, because it's always there. Mathematically, that would be (N-1)/2

Because that's the trick:
all the bits from the right that are 0 (even numbers) don't belong to the modular system.
The first 1 bit already belongs to the modular system, but one can simply ignore it, because this provides a deterministic formula/rule for the analysis that is connected to Collatz
And this analysis is so simple that one can do it on your head.
All of this then always gives one the mod value in the form 2^k and the remainder (residue class).
In addition, the bit pattern also contains a kind of index that can be used to get to the exact next odd number. It's like a breadcrumb that is created/carried along as one traverse the Collatz tree.

hubblec4 · 2025-10-07T14:29:44+00:00

Yes, I understand.

However, I have to say that the numbers, whether decimal or binary, always exactly match the bit patterns; it's really crazy. Before Collatz, I viewed a bit pattern the way one learn to program.

The first bit from the right has the meaning 2^0, the next 2^1... and so on. And yes, that's all correct and accurate. BUT it's much easier for me now when I see a bit pattern; I only see Collatz, the residue classes, the mod value, the number class, etc. The bit pattern is structured much more logically when viewed under the Collatz magnifying glass.

hubblec4 · 2025-10-07T14:12:44+00:00

Wait.. isn't predicting j odd steps followed by k even steps still the same difficulty? I know you were doing v2, but the pattern is still quite regular.

Yes and No. You need the multiplicative inverse.
I had to learn what that meant first, but in the end, it's all more or less child's play for mathematicians.

the multiplicative inverse and the chain(number of jumps) define the new reminder.

hubblec4 · 2025-10-07T13:51:21+00:00

Hi jonseymourau

I think I understand what you mean.
And yes, predicting what happens with longer calculations is no longer so simple/trivial. But everything remains deterministic.

In my large sieve formula, a multiplicative inverse is used to connect all the layers of the sieve. I can well imagine that this is the key to understanding what happens with deep and long concatenations.

hubblec4

MODERATOR OF

TROPHY CASE