I'm not making heads or tails of these latest crumbs from VQC. So I've been looking at something else.

I noticed how we can "climb" down the n's from a given record. As we increase the a and b monotonically we will jump between different e's and the n will at certain times lower by one until it hits 1.

For (e, 2) (where applicable) this follows a simple equation of d - floor((e - 1)/2).

Meaning to go from (3, 2, 3), which is {3:2:12:5:7:21} you add 11 to both 7 and 21.

d here is 12, 12 - (3 - 1)/2 = 11. The record for 7 + 11, 21 + 11 is (0, 1, 24, 6, 18, 32) which is also the first record that has n = 1 for 7 + k, 21 + k for k < 11. For these records the x in the record (e, 1) will always be the (e, 2) x + 1.

No idea if this is useful, but it was interesting. For n 2 I haven't spotted an obvious pattern yet.

>>3462

Decision Tree's aren't strictly binary, though.

>>3468

Of course, my intention wasn't to discourage, but simply to point it out. It's also a good thing to keep in mind, if some branches might require more than binary splits.

>At the correct element in the grid at (e, 1) where the value of a at that element equals the na we want, if you subtract 2d+1 from na then you are in the negative half of the grid in terms of e and the value at the same element in the first row will be (n-1)a

I'm trying to wrap my head around this one. I'll try with an example and if you guys understand it in another way let me know:

We use c = 145. This is a=5,b=29 so the correct na in our case is 25.

The d is 12, so we do 25 - (2 * 12 + 1) which equals 0.

We are now supposed to be in the negative half of the grid with regards to e, which I then assume, we are going after: e - (2 * 12 + 1) =-24. The first record in -24 is {-24:1:28:8:20:38}.

Here a is (5 - 1)5 which is correct, but the crumb states "the value at the same element in the first row will be (n - 1)a". I interpret that as the same record at t (1, 1), where a[t] = 25 should also be the t in (-24, 1) where a = 20. However, this doesn't match, since 20 appears in t=1 in (-24, 1) and 25 appears at t = 4 in (1, 1).

So does that mean that na - (2*d + 1) doesn't reference the same e, as e - (2 * d + 1)?

>>3470

Now, I'm not sure if we know but from what I've seen, if we do e - (2 * d + 1) then (n - 1)a will appear in (e - (2 * d + 1), 1) at some point.

Could it be that we have to use these two together? Somehow combine (e, 1) and (e - (2 * d + 1))?

>>3471

And, of course(?) shouldn't then (n + 1)a appear in e + (2 * d - 1) as well?

>>3466

>>You're going to use column e=1 to show whether the conjecture about Fermat primes is true during this

Has anyone looked for the Fermat numbers in (e, 1) yet?

I haven't looked into it myself, not sure if someone else has, but we know that they will always be in (1, n) for greater than 3, and this makes sense since Fermat Primes are all perfect squares + 1. All perfect squares will occur in (0, n) and since we add 1, we will give it a remainder of 1 shy from a perfect square.

>>3473

This probably won't work for large numbers, but what we do when we compute f (2*d + 1) is that we are actually increasing by one square.

Now, I'm thinking out loud again. We can do e + (2 * d - 1) and here we will find (n + 1)a. But we can generalize it to k * (2 * d - k), where k is the number of squares to add to e.

This means that the (n + k)a will be in (e + k * (2 * d - k), 1) and it will occur at a lower t. I don't know if we can guarantee it to exist as t = 1, though. I mean if we could then we would have found (n + k)a which would be amazing. Then we would be even closer to the actual answer.

Take our beloved example of c = 145. We know the record we want is (1, 5, 12, 7, 5, 29).

If we then do 1 + (2 * d - 1) we will get 24. Here we will find 5 * 6 (30) at t=4 (same t as an btw, but probably not something that holds true for every number).

But let's add more squares to it: e + 4*(2 * d - 4) =1 + 4*(2 * 12 - 1) => 81.

This is the same as (n + 4)5 which is (5 + 4)5 which is 45.

For e = 81, we have the following records:

(81, 1, 42, 1, 41, 45)

(81, 1, 48, 3, 45, 53)

(81, 1, 58, 5, 53, 65)

(81, 1, 72, 7, 65, 81)

(81, 1, 90, 9, 81, 101)

Thus we've "moved" a(n+4) up to t=1. This works fine for c = 145, though. It probably won't work smooth for big numbers.

Someone want to take a look at this and see if it make sense?

def genesis_block(e): if e 0: return (0, 1, 4, 2, 2, 8) x = e % 2 a = int(e/2) + x n = 1 b = a + 2x + 2n c = math.fabs(a*b) d = math.floor(math.sqrt(c)) return (int(e), int(n), int(d), int(x), int(a), int(b)) def factorize(c): e, n, d, x, a, b = rowForAB(1, c) dd = d/2 if dd % 2 1: dd -= 1 ee,nn,dd,xx,aa,bb = genesis_block(e + dd * (2 * d - dd)) print(math.gcd(c, aa*bb))

>>3475

It only works for small numbers though. But maybe there is a way to get it faster?

>>3476

Actually, thinking more about it I just got caught up with low numbers. The big numbers multiplied by (n + k)*a will diverge too far from the genesis cell. I don't think this is a the direction to the solution.

Although I am interested in what you guys think about the (n + ..) angle, though.

Aren't all negative x's simply the next records x * -1?

For (1, 1) we have the following records:

(1, 1, 2, 1, 1, 5)

(1, 1, 8, 3, 5, 13)

(1, 1, 18, 5, 13, 25)

(1, 1, 32, 7, 25, 41)

(1, 1, 50, 9, 41, 61)

(1, 1, 72, 11, 61, 85)

Isn't the negative x for (1, 1) these:

(1, 1, 2, -3, 5, 1)

(1, 1, 8, -5, 13, 5)

(1, 1, 18, -7, 25, 13)

(1, 1, 32, -9, 41, 25)

(1, 1, 50, -11, 61, 41)

(1, 1, 72, -13, 85, 61)

Which are the same records, except the x refers to the next records x multiplied by negative 1 (or simply negated)?

>>3511

So…?

1. Check if e is zero

2. Check if e is odd or even

3. Check if big N is odd or even

…?

>>3556

1. Check if d is odd or even?

Parity of d will give us parity of x, right?

We can't deduce parity of d from e alone, as you can see in (4, 2).

Of course, I'm now assuming we CAN figure out the parity of x by looking at d. Not sure if we can / haven't looked enough to see if it's possible.

Some preliminary work:

def rowForAB(a, b): c = ab d = int(math.floor(math.sqrt(c))) e = int(c - dd) n = int(((a + b)/2) - d) x = int(d - a) return (e, n, d, x, a, b)def recurse(c): e, n, d, x, a, b = rowForAB(1, c) if e == 0: return [d, c//d] if gcd(e, d) != 1: return [gcd(e, d), c//(gcd(e, d))] return [[e, recurse(e)], [d, recurse(d)]]

This can be used to study the branching.

>>3580

Of course, welcome back!

The triangle numbers are interesting.

To generate the A's for an odd e, you compute

(e + 1)/2 + 2 * (t * (t - 1)).

And the function for even e D's its:

e/2 + 2 * (t * (t - 1))

Which is (e + 1) / 2 + 4 * T_(n - 1) (A for odd e)

and e / 2 + 4 * T_(n - 1) (D for odd e)

>>3801

He means https ://en.wikipedia.org/wiki/Triangular_number

>>3804

>>rowForAB(1, 17 * 53)(1, 421, 30, 29, 1, 901)>>> rowForAB(1, 17 * 53 * 17 * 53)(0, 405000, 901, 900, 1, 811801)>>> s(405000/2)450.0>>> getTFromA(1, 421)15.0>>> generateNthRowFromGenesis(1, 15)(1, 1, 450, 29, 421, 481)

So it appears the n in c**2 is equal to the corresponding d[t] where t is the t that a=1,b=c's n appear in (e, 1).

Not sure if this will hold though. But if it is, then it would explain why sqrt(n/2) - n = x. Since d - a = x.

>>3808

Well, if I understood the VQC decision tree, we should trim d and e.

So we are making a function f, that will return a factor of the input parameter. So far we know the following:

Step 1:

Trim input c until it is an odd number.

Calculate e, d from trimmed c

Compute GCD(e, d)

If GCD(e, d) != 1 then return GCD(e, d)

Step 2:

We now have to factorize d and e, which essentially means we have to call our function f again, two times, one for e and one for d.

Step 3 is still unknown, but somehow involves the VQC and triangle numbers.

So assuming I wrapped my head around it, trimming d and e are necessary (and thus also what makes it a recursive function).

>>3809

Step 3 also involved a tree from our d, e factorizations.

Actually, thinking more about it. I don't think we are supposed to use f(d) and f(e). Given the idea that f is supposed to return a factor, I think we need two functions.

f which takes our c and g which takes our e and d. We use f to factorize a number and g to generate a tree.

>>3812

>>3811

If f is supposed to just return a single factor, then how will we be able to build a tree at all?

Assuming the flow of the code is something like this:

function f(c)

d = floor(sqrt(c))

e = c - d * d

if gcd(d, e) != 1:

return gcd(d, e)

factor_d = f(d)

factor_e = f(e)

…

How will f(d) and f(e) be used to build a tree, assuming this function will return a single factor?

>>3815

I agree. I find it a bit hard to reason about, though.

As for step 3 I have no real idea on how that might be. There's a lot of crumbs that wouldn't fit into it. Like why was f (2 * d + 1) important if it's not used somewhere?

He also keeps reminding us about the xx + e = 2an. Maybe step 3 will somehow give us x, so we compute xx + e and then find 2an? In which case gcd will help us out. So far I'm still trying to make sure I got the step 2 part correct.

>>3817

I'm just thinking out loud here. We know that we will get a tree of d's and e's. Maybe we need to look at the records of the leafs and somehow build up?

Like, we generate a big tree, then we go down to the bottom and start working our way up. We do <somethingwith the leafs to build up and keep doing that until we "bubble" up to the top and by then we will have a factor(s)?

>>3820

Well I tried generating the tree for 145. It yields (among others) 3 and when you compute the same function with 145 * 3, you'll get 5, 87. But if this holds up for more numbers I'm not sure about yet.

>>3825

It shouldn't be too hard to estimate the time complexity of step 1 and 2. Best case we do one squart root (to estimate d and e) and return d (e = 0).

This should be O(log n).

If e != 0 we compute GCD(e, d) which also has a time complexity of O(log n).

This can be seen as the time complexity of O(log n + log n) which is the same as O(log n).

For the recursive parts, we still only compute O(log n) so overall I think step 1&2 should have a time complexity of O(log n).

It's been years though since I did this formally at uni, so I'm only using what I remember. I might have some old textbooks I can go over at some time, to double check. Maybe CA can chip in on this?

But without knowing the remaining steps, it's impossible to say anything with regards to the algorithm as a whole.

>>3837

I haven't had time to really dig into this, but I've been trying to play with primes.

We know that this function will return a factor, so for a prime number that means it will return either 1 og the prime itself (I'm assuming). This we can also use the function as a primality tester.

If that's true, then somehow, the tree will be used to show that it has no factors other than 1 or it self.

No idea on how though, but maybe it will be easier by starting to look at a few smaller numbers where the branches can't be big.

Just an idea, maybe I'll take a stab at that during the weekend.

Do we have any knowledge of how to use f (2*d + 1) yet?

Has anyone looked into making a map over the, still, not solved crumbs from VQC?

I've been looking more into the triangle numbers, nothing new to report, but just another way of finding c**2 (0, N).

Calculate the triangle number of d**2 and subtract the d[t] in (e, 1) where big N is a[t].

Example:

Record for 145 is (1, 61, 12, 11, 1, 145). At t=6 in (1, 1) we have (1, 1, 72, 11, 61, 85).

Compute the triangle number for 144 and subtract 72. You're left with triangleN(144) - 72 = 10368

Which is also the record for a=1, b = c*c.

Doubt it's useful for step 3, or any steps, but it is interesting.

>>3887

x or x + n. So this can be interpreted in a few ways, either that we have no clue if we'll find x or if we are going to find x + n. However, there are no coincidences, right?

I'm speculating that maybe it depends on the parity of e (or d). Maybe if e is even, we're going to find x, if e is odd, we're going to find x + n.

>>3895

Not with this algo it won't. Finding Mersenne primes should be a simple game.

>>3940

There is probably some pattern behind it either being x or x+n. If it is something as simple as e being odd or even, I don't know. Maybe it also depends on which branch you choose?

Like if you use the e branch you will find x, if you use the d branch you will find x+n. Of course, I don't understand the tree yet.

Take our example c = 145. If you use the d-branch, do you have to stick to the d branch through the tree, or does it depend on the different records in the sub tree?

>>3942

Hmm, yeah that makes sense. The question is are we going to traverse the whole tree, or just different branches (Has VQC said anything regarding this)?

I'm looking into the tree for 3^k for odd k. I figure if there is a pattern here, it should be easier to figure it out by observing smaller trees where we know what to expect and preferably in a predictable way (Like just 3 as a growing factor).

I also think we are still missing pieces right? Like how the f works, I know PMA has been looking into it, but I haven't had time to go over his results yet.

Do we also know the underlying pattern of d[t] - d and the growth of (n - 1) as a factor? I'm not sure if we need to know there before we look for patterns in the tree, or if the tree will help us find these patterns (and how to apply them).

>>3995

I think we're being given the crumbs in a disordered fashion.

I don't know if we have everything in place for the tree right now. We might be missing crumbs, still, rendering the tree useless.

Unfortunately VQC is sporadic in his hints, so it's hard to tell. At the same time, I don't want to be spoon fed this stuff either, it's a fun challenge. However, I do question how much we've been able to solve ourselves.

It seems like we're just hitting our heads against the wall until he somehow drops a few crumbs (or parts). And then we jump on it until we're stuck. Rinse repeat.

Now we know we're talking about fractals here, right? Instead of going the other way around, why don't we try and understand why we need to recurse down the tree. Try and study the patterns at the core of the nodes, see if we can understand why the tree is necessary in the first place.

>>4000

We know we are talking about a fractal. And we've been told previously that we are going to try and figure out which branch we are in of the fractal.

Once we know that, we can solve it. So maybe the tree represents a part of our fractal, and we are going to use this tree to figure out where we are in the fractal.

If we can figure out how this relates to a fractal, somehow generate and study it, then maybe then we can understand the tree more.