I stickied the thread. I thought it would be easier to navigate the board if the main objective was stickied. That might be a problem if we start focusing on multiple things, so if it seems like a bad idea anyone can feel free to whinge to me about it.

Since nobody seems to pay attention to the meta thread, I have to bring this here. One particular tripfag keeps getting reported for being a "namefag shitposter" (it's not Topol). They aren't really posting anything that helps us, but we haven't discussed rules at all so I can't really use my own discretion. I don't want to be distracting, but if we don't discuss rules, I can't really delete anything without having the power to delete whatever I want. I don't want that and I know none of you do. If nobody wants to discuss rules, I'm not going to do anything about this particular person, so whoever keeps reporting them, suggest some rules and see what everyone thinks.

>>1045

>What are ways or grids or cubes are there to represent each elements?

>You could use another pair apart from (e,n)

>What would that produce?

I'll post all of them again if anyone wants, but without spamming the thread, I made images with each possible pair of dimensions when we were still on /cbts/ and they make some interesting shapes. Pic related.

>>1088

So why don't you share how you did it?

It's been way too long since I paid enough attention to follow. I read the parts of the thread I missed and I have barely any idea what anyone is talking about. So does >>1342 mean we're there? I might try to turn all of this algebra into another part of those guide things I was working on since they got positive feedback.

Hey, so since I'm the BO I feel obliged to mention that while I haven't really been posting much for the last week, I am very much still here every day. Considering the ramifications of what we're doing, I'm sure it's important to all of you to know that the person responsible for the board hasn't abandoned it. Even before I became aware of this I had far more that I needed to do than I had the time for, and that's still the case. I've got a bit of time now, so (since I haven't seen anyone else doing it - if they have it would be handy to know) I'm going to try to conglomerate all of VQC's hints since the start and as much of the findings as I can understand over the next couple hours and turn them into something hopefully easy to understand.

>>1574

There are code tags: (without spaces obviously) [ c o d e ] then your text then [ / c o d e ]

Like so:

public static void Main(string[] args) { CreateTheEnd(); Output(); }

Here's every hint VQC has given thus far in one convenient location (apologies that it's a pdf again; I know why people are paranoid of them but I can't really think of any other way to do it). I didn't do much formatting so it may look bad in places but I was just copying and pasting text.

Thinking out of my ass here: we can calculate any of the variables by applying math to i and j. If we could magically calculate i and j from c, we'd be able to calculate a and b from c. Here's a plot with i as the x axis and j as the y axis every time a and b are primes. This might be useless but I only wasted a couple minutes on it.

Why do we have records for negative e? Why are they put into the graph? The numbers we're trying to find are only going to be positive.

>>1638

That does make sense, but if e is ever going to be negative, it's because d is larger than c (like you said). d is the floor of the square root of c, so how could it ever be bigger than c?

I don't know if anyone figured this out before me or found a better method for finding genesis cells, but here's a thing.

In order to find the genesis cell for a given product of two primes c, we need to use c to calculate e and n. e is easy, since it's derived directly from c.

e = c - ((floor(sqrt(c))) * (floor(sqrt(c))))

In order to calculate n from c, we need to know i, since

n = i - d

n = i - (floor(sqrt(c)))

That's trickier to calculate. That's the obvious stuff. Now here's an image (the first one) with c as the x axis and i as the y axis. A point is drawn every time c is the product of two primes. It creates what looks like a bunch of linear lines. In the second image, I used the straight line tool in Paint to be completely sure they were linear, although I only did it for a few lines. I'm not sure if each new line start every time the i loop starts again or if it's something else, but if we could figure it out and separate each of the lines, we could use simple gradient maths (rise/run) to calculate i from a given c. That would allow us to find the genesis cell for a given c (I haven't gotten into generating the rest of the cells from the genesis cell yet).

>>1648

If we weren't meant to care about i or j after the fact, why are we using them to calculate n? I don't think VQC was implying that we should just completely ignore i and j. VQC has been telling us to look for patterns. I found a pattern. What I'm saying is that if we can use only c to find i, we can use only c to find n. We can already use only c to find e. If we can find n from c, like we've been trying to do, we can find the genesis cell for a given c. Why would this not be worth looking into?

>>1652

So are you saying someone already figure out how to find n from c, or does "generating" mean something else?

>>1656

We really need some kind of jargon dictionary at this point. A few threads ago someone said that "genesis cell" meant the first cell of an infinite set (so t = 1 regardless of (e, n)). That's what I was referring to.

Further from this >>1647

If there is a way to find the gradient of each of these lines, we don't actually need to do anything with t/setSize. We'll have e, n, d, c and i, and we can use those to calculate a and b.

c = a*b

c = (i-j)(i+j)

c = i^2 - j^2

j^2 + c = i^2

j^2 = i^2 - c

j = sqrt(i^2 - c)

I also saw a far simpler method of calculating j somewhere else. With i and j we can calculate a and b regardless of any of the other infinite possible cells for a given (e, n). All we have to do is figure out how these lines are generated in terms of i and use gradients to calculate n from c.

Oh fuck man I found a very important pattern. I need a minute.

>>1704

Do the words "I need a minute" mean nothing to you?

Okay. As I mentioned here >>1647 (even though apparently I used the term genesis cell wrong; I was referring to the first cell of an infinite set), one way I was thinking we could find n from c was by finding i from c, since then we use n = i - d or n = i - (floor(sqrt(c))). Instead of spending half an hour turning this into something really easy to understand I'll just type out the process I took and hope everyone gets it and doesn't mind a whole bunch of text.

In order to figure out how to calculate i from c, since we can't do it with the variables we get from c alone, I tried to find a visual relationship between them. I made an image with a white pixel every time c is the product of two primes but instead of (e, n) as the axes it's (c, i). That's pic related. It shows the relationship between c and i, and it looks like a bunch of linear lines.

If these were linear, and we could figure out the relationship between these lines, we could use them to find i for a given c, couldn't we? All we'd need to do is find the correct line that our c is on and use simple gradient maths (rise / run). In order to confirm that these were linear lines, since it's a bit haphazard doing it in this Paint program I have, I changed the code around a little bit to plot each (c, i) as points in a big grid, much like the original {e, n, d, x, a, b} grid, but again with axes (c, i). I then highlighted from one point in each line to the next a few times in order to figure out the gradient. By the way, if anyone doesn't know, in whatever your spreadsheet software is, you can change the formula syntax to R1C1 and it'll change the x axis from letters to numbers, which is very handy (instead of something like BD24 it'll be something like R42C52, as in (42, 52)). In the next post I'll paste my calculations, since it'll break up the text a bit, and it'll show what the relationship is between these lines.

>>1709

Lowest line

R121C52:R277C130

(121, 52) to (277, 130)

Rise is 156, run is 78, gradient is 2 (6/3)

R133C58:R265C124

(133, 58) to (265, 124)

Rise is 132, run is 66, gradient is 2 (6/3)

R337C160:R457C220

(337, 160) to (457, 220)

Rise is 120, run is 60, gradient is 2 (6/3)

Next line upwards

R169C116:R217C156

(169, 116) to (217, 156)

Rise is 48, run is 40, gradient is 1.2 (6/5)

R253C186:R289C216

(253, 186) to (289, 216)

Rise is 36, run is 30, gradient is 1.2 (6/5)

R289C216:R313C236

(289, 216) to (313, 236)

Rise is 24, run is 20, gradient is 1.2 (6/5)

Next line upwards

R217C204:R229C218

(217, 204) to (229, 218)

Rise is 12, run is 14, gradient is 6/7 (0.857142 repeat)

R229C218:R265C260

(229, 218) to (265, 260)

Rise is 36, run is 42, gradient is 6/7

R265C260:R301C302

(265, 260) to (301, 302)

Rise is 36, run is 42, gradient is 6/7

Next line upwards

R181C210:R205C254

(181, 210) to (205, 254)

Rise is 24, run is 44, gradient is 6/11 (0.545454545454)

Next line up

R181C222:R193C248

(181, 222) to (193, 248)

Rise is 12, run is 26, gradient is 6/13 (0.461538 repeat)

Next line up

R205C290:R217C324

(205, 290) to (217, 324)

Rise is 12, run is 34, gradient is 6/17

>>1709

>>1710

I did the next one too and it was 6/19. The thing you should all be taking away from this is that the denominators are all primes, and from the lowest line to the highest line they increase in order with 6 as the constant numerator.

>>1712

I didn't realize until now but setSize was 12. That means that while those gradient rules still work the numbers are slightly different. I'm currently trying to figure out the mathematical relationship between each line that determines where the next one starts each time.