This thread is for the purpose of examining old breads, for those of us starting late. This will allow us to work without detracting from the main RSA threads, and hopefully help us to catch up sooner rather than later.

Here are links to archives from /cbts, and older breads–you'll find relevant links in all of them:

RSA #0 —— https://archive.fo/XmD7P

RSA #1 —— https://archive.fo/RgVko

RSA #2 —— https://archive.fo/fyzAu

RSA #3 —— https://archive.fo/uEgOb

RSA #4 —— https://archive.fo/eihrQ

RSA #5 —— ,>>7

RSA #6 —— ,>>848

RSA #7 —— ,>>1713

RSA #8 —— ,>>2555

RSA #9 —— ,>>3361

RSA #10 —— ,>>4140

RSA #11 —— ,>>5042

RSA #12 —— ,>>5844

Pic related is a collection some industrious anon compiled of all of VQC's first posts. Additionally, VQC goes through the code in detail in RSA #5:

>>7

>>6211

This is the original C# code–again, you should go through the link in the above post for VQC's line-by-line explanation:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

using System;

using System.Collections.Generic;

using System.IO;

namespace IntegerFactorisation

{

public class TheEnd

{

public static string path = "";//PUT YOUR FILE PATH HERE

public static Dictionary<int, Dictionary<int, List<string>>theend = new Dictionary<int, Dictionary<int, List<string>>>();

public static void CreateTheEnd(int i_max = 512, int x_min = 0, int y_min = 0, int x_max = 64, int y_max = 64)

{

for (int i = 0; i < i_max; i++)

{

for (int j = 0; j < i; j++)

{

int a = i - j;

int b = i + j;

int c = a * b;

bool odd = c % 2 == 1;

int d = (int)Math.Sqrt(c);

int e = c - (d * d);

int f = e - ((2 * d) + 1);

int n = i - d;

int x = d - a;

if (!theend.ContainsKey(e)) theend[e] = new Dictionary<int, List<string>>();

if (!theend[e].ContainsKey(n))

{

theend[e][n] = new List<string>();

}

if (!theend.ContainsKey(f)) theend[f] = new Dictionary<int, List<string>>();

if (!theend[f].ContainsKey(n - 1)) theend[f][n - 1] = new List<string>();

string text = "{" + string.Format("{0}:{1}:{2}:{3}:{4}:{5}", e, n, d, x, a, b) + "}";

theend[e][n].Add(text);

text = "{" + string.Format("{0}:{1}:{2}:{3}:{4}:{5}", f, n - 1, d + 1, x + 1, a, b) + "}";

theend[f][n - 1].Add(text);

}

}

}

public static void Output(int i_max = 256, int x_min = -64, int y_min = 0, int x_max = 64, int y_max = 64, int set_size = 12)

{

TextWriter tw = File.CreateText(path + "output.csv");

for (int y = 0; y < y_max; y++)

{

for (int z = 0; z < set_size; z++)

{

for (int x = x_min; x < x_max; x++)

{

if (theend.ContainsKey(x) && theend[x].ContainsKey(y) && theend[x][y].Count z)

{

tw.Write(theend[x][y][z] + ",");

}

else

{

tw.Write(",");

}

}

tw.WriteLine("");

}

}

tw.Close();

}

}

}

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are many other versions written in other languages at the top of RSA #12. VQC recommended going with a language that had a good "Big Integer" library. A good graphics library also seems to help.

>>6217

I've found this pdf (which I've renamed) to be an excellent compilation of VQC's hints, up to a few months ago. I like it because you can click on links that take you to the archived threads–very useful. It was first posted here:

>>1602

The second pdf ('verifyRSA0.pdf') isn't a pdf at all–once you've downloaded it, change the extension to .csv. You can use it to verify your results. It comes from this post:

>>1189

The image is of my first output, using the settings from the original thread. When looking over VQC's code for outputting a graphic (RSA #0), you can see that the innocuous "odd" function comes into play there. In my graphic, I haven't applied it yet…with all of the occupied cells filled in, you can see clear pathways emanating down-and-outward from (0,0) at the top. The vertical lines running parallel to the line along e=0 are interesting as well. They run along e = -1, e = -4, e = -8, e = - 15, e = -24…so you can see that the number of columns between each of them are 0 (between e=0 and e=-1), 2, 4, 6, 8, 10…

Here is VQC's algo for making the first image:

>Bitmap with black pixel at (0,0) all white for rest of row.

>All black first row.

>Whenever a cell has any elements, it is black.

>Whenever a cell has zero elements, it is white.

>if (!theend.ContainsKey(e)) theend[e] = new Dictionary<int, List<string>>();

> if (!theend[e].ContainsKey(n))

> {

> theend[e][n] = new List<string>();

> if (use_bmp && odd)

> {

> bmp.SetPixel(e, n, Color.White);

> }

> }

and here's the link for context:

https://archive.fo/o/XmD7P/https://8ch.net/cbts/res/672.html%23q31407

(this is missing from the .pdf compilation of VQC's hints)

You can see that it's meant as an addition to the original code posted earlier in that thread, so that you would be creating the image as you filled the grid. I'm assuming "use_bmp" means that the cell at (e,n) is occupied; "odd" is one of the unused parts of that original code as well.

One thing I've noticed–in the function calls to output the results, one of the parameters is i_max again. In the first instance, it's called to populate the grid…but it isn't used to create the output. Not sure what that's all about, but it's worth noting.

>>6480

This is the output I'm getting when I

a) eliminate all black in the zeroeth row, except for (0,0)

b) make all even C cells white

I feel as if I've screwed-up. All the symmetry is lost-rather than looking like a beacon shining light down upon all of us, it looks like a shower of nappy dandruff coming toward your face.

Actually, looking back at VQC's provisions, it's clear the image is wrong. The first row is broken on the left side, and it should't be. I also hard-coded the provision for the zeroeth row. I must be misinterpreting what 'use_bmp' means; I'll report back when I figure it out.

Other pic related is the new image superimposed over the old, to show changes.

>>6481

I remember we all seemed to come up with our own methods for generating the bitmaps. What you're getting being different to everyone else's might be because of that. For mine (referring to the Java version), right after generating the variables for a given (i, j), I call image.setRGB(e (the x coordinate), n (the y coordinate), col (which is a variable holding the colour value)). Instead of a regular bitmap I'm using a BufferedImage object. Maybe implementing it differently could help. I haven't actually used C# much so I don't know how bitmaps work in C#. There's probably an equivalent to Java's BufferedImage somewhere.

>>6485

Thanks for the input AA :)

I started with "setRGB(~~~)" for each pixel in Java, but for some odd reason the image was wigging out when I tried to open it; plus, at 128 x 64, it was a little small. So I switched to drawing rectangles, which are sized by a scalar that I choose, depending on how large the grid is.

After thinking about it for awhile, I think I understand where the disconnect lies: each cell has multiple values for "c", so when VQC says that we shouldn't output the values (or rather, output them the same color as we would a cell with no values), what do we do when there are both even and odd values for "c"? For example, here's the cell I have at at 4,2:

{4: 2: 4: 2: 2: 10} c = 10

{4: 2: 9: 4: 5: 17} c = 35

{4: 2: 16: 6: 10: 26} c = 260

{4: 2: 25: 8: 17: 37} c = 629

{4: 2: 36: 10: 26: 50} etc…

{4: 2: 49: 12: 37: 65}

{4: 2: 64: 14: 50: 82}

{4: 2: 81: 16: 65: 101}

{4: 2: 100: 18: 82: 122}

{4: 2: 121: 20: 101: 145}

{4: 2: 144: 22: 122: 170}

{4: 2: 169: 24: 145: 197}

So I think that filtering out even values of "c" comes when we start graphing for individual values within the cell, not so much for this first part.

The reason I've been having inconsistent results is twofold:

1. I have two graphing functions: one that graphs for both even and odd cells, and another that graphs only odd cells. For the second function, I was checking each entry of 't' to see if 'c' was odd or even–if it was even, the cell was marked white. If it was odd, it was marked black. But since not every cell had twelve entries, and some of the cells had both evens and odds, the only way a cell was marked black was if there were twelve entries for 't', and if the last one had an odd 'c' value.

2. in the graphing function that accounted for both even and odd values of 'c', I mistakenly used these conditionals:

if(grid.containsKey(x)

&& grid.get(x).containsKey(y)

&& grid.get(x).get(y).size() z){

…but VQC mentioned that, if there were any values at all in the cell, then it should be marked; since 't' could be taken arbitrarily large one entry essentially means infinite entries. So instead I changed the last conditional to

&& grid.get(x).get(y).size() 0){

and that solved the problem.

Now it's time to inspect & take it into the -y region

>>6502

I think the idea was to plot a point if a given (e,n) exists (meaning infinite cs will exist there). It's a big grid of pixels, with x and y values corresponding to e and n values, and if an infinite set of c values exists at one of those (e,n) pairs, it plots a point. Your image looks like it's meant to now. Here's one with a higher iMax (and opposite colours). Another interesting thing to do is to plot with other variables as the axes. I did one for each possible combination in December. Here's a couple of them. I don't think anyone ever figured out any useful information from them but they're interesting to look at.

So obviously this thread is for you to more publicly get your head around the threads and everything, and I've been planning to do a better introductory sticky. Do you think it would be productive if we sort of went back and forth about it? As in, I have a rough idea of how I would implement the sticky, but I don't know if it would actually be digestible or too much/not enough information, and you're one of the people it would be for. We could help each other out in that sense.

My rough idea (in a broad, less explanatory sense) is this:

>this grid works kind of like a quantum computer in the sense that each (e,n) cell is a qubit (or a possible solution), we want to find one particular cell that contains our c, and the collapse of the superposition (in quantum computing this means applying a specific action to the qubits that spews out the correct one - I've watched probably hours of videos and none of them have explained exactly what this process is, but the point is that there's an action that takes place analogous to what we do with the grid) is a mathematical formula that involves our c value

>ignoring the fact that it's called a "virtual quantum computer", the whole idea is that there are concepts in mathematics that have been hidden from the public by the elite, and someone who knows about it is trying to disclose it to the public (VQC), but he thinks the best way for that to happen is for people to "discover" it (with guidance, obviously)

>one of these concepts revolves around the idea that we can factor a number without just checking every number up to the square root and seeing if it divides the number without a remainder - there's a direct calculation we can do on c to find a and b

>VQC has given us vague hints as to how to use this grid to find the answer, but in general we're just kind of blindly plugging away with the concepts he's told us about like toddlers shoving square pegs into round holes

>the concepts he's shown us that are meant to be used in varying capacities to find a and b from c are as follows:

<there are incremental rules that allow you to go from cell to cell (i.e. if e increases by 1, other variables might also increase by 1 or 2e or something like that, and if within an infinite set (e,n) t increases by 1, it affects the values of a and b - we should probably get a full list of these together)

<there are other cells that are in some way related to the (e,n) we're trying to find, such as (e,1), which is the cell with the same e but an n value of 1, or the cell (e,n) at which the a and b values equal 1 and c respectively (which is the only other cell that produces our c value other than the one with the prime numbers), or (e+2n,n), (e+4n,n), (e+6n,n) etc (we should also probably get a full list of these together)

<we can apply the idea of related cells to the related cells (i.e. if we find the cell at which (a,b)=(1,c), we can also find that cell's (e,1) and so on) and apply the transform rules (incrementing values as above)

<there's a factor tree we can create using d and e (I don't completely understand it but it's here >>3654 if you want to have a look; I think it's finding the d of d, and then the d of that d and so on)

<we can represent c as the difference between two squares (d+n)(d+n) - (x+n)(x+n), and we can represent odd (x+n) squares as eight triangle numbers +1, so if you can somehow find the base of the triangles based on the known values d, e and f, you can find a and b based on x and n

>so what we're doing is figuring out how to use these concepts to find a and b from c, although we're not really that sure how it's actually meant to work

Is that confusing or vague or anything like that?

>>6515

I'd be delighted–in fact, I was hoping that some of you would drop by on

occasion with some insight.

As far as an introductory thread, I think the best thing you could do would

be to immediately clarify that this is called a "virtual quantum computer",

not so much because it models one, but that it does what a quantum computer

can do–for these purposes, break encryption. Honestly, for all I know it

could be an exact replica–but the way I look at it, it's an analogy in the

fashion that "hands of stone" meant a hard-hitting boxer, not someone with a

medical issue.

From the other thread (re: your "what is the grid" .pdf), I think you nailed it

when you explained that what we're doing here doesn't really seem to involve

quantum computing; it's more a series of illustrative exercises meant to teach

us the true mathematics that have been hidden from us. That, combined with

some examples of what may be possible with such knowledge, would do well enough

to pique people's interest.

You're right that I'm doing this publicly for a reason–I'm trying to establish

the pattern of thoughts and realizations so people can see how one thing

progresses to another (this makes the arrogant assumption that I'll make it to

'another'). I'm also hoping to encourage others to do so–different people

will notice different things, which may, in turn, spark a realization in

someone with more knowledge.

I'm also making a program that will output .csv and .png files, then an

interactive 2D grid, then 3D, then 4D+. I imagine this is being taught to be

spread, so I'll make it available when it's done.

At this point I'm looking to isolate the patterns generated–there's obviously

some fractal action going on, but what is the base pattern that's being

repeated? The only unbroken lines emanating from (0,0) are the horizontal ones

starting one line below, the vertical one from center, and the two others

extending from an angle arcTan(2) (approx. 63.435 degrees) from horizontal.

It's also worth noting that the lines caught within the "christmas tree"

parabola are parallel to this line (I haven't verified this mathematically, it

just looks that way).

You can also see a line emanating 45 degrees from horizontal, though it isn't

continuous. The interplay of these two angled lines is what causes some of

the diamond patterns.

Furthermore, either the same sets of angled lines are emanating from each of

the vertical lines extending leftward, or the ones offset from the main ones

(coming off of 0,0) just happen to intersect the vertical lines perfectly.

This is an interesting relationship.

From the main vertical, as well as these two other angled lines, we see other

lines emanating…and they're always emanting to the left and/or up, in a

direction clockwise from the line where they start—like echoes reoccurring

further and further away.

But all this changes if you think of this as peering at a 3D image in 2D;

it's as if none of the cells are noise at all—rather, they're part of another

pattern coming from a different base. It's like looking at an x-ray that's

focused at too many depths, rather than the one you want to look at. The

vertical lines emanating from (0,0)—are they the only ones, or is there

another set directly behind them that's being covered? You can ask the same of

any of the lines we see. Also, the angles take on new meaning in higher

dimensions–are we looking at lines connecting the axis of different pyramids or

tetrahedrons? Cubes? A "Great dodecahedron?" Maybe lines connecting a sphere

to 13 other spheres (http://mathworld.wolfram.com/SphericalCode.html)?

I don't think this goes much further until we figure out how these relate in

3D+.

Pic related is a graphic illustrating how the "spiral" lines and the arcTan(2) line seem to relate

>>6526

This one extends the connection.

>>6526

My mistake, the angle is arcTan(1/2), about 26.5650512 degrees.

Found something interesting today :)

Numbers represent ratios of length. The purple triangle is meant to illustrate the arcTan(1/2) angle between the horizontal line to the right (from the origin) and the unbroken line that travels down and to the right. The pattern of cells describing that line, extending from the origin, is two cells to the right, one down, repeat until end.

What's really interesting, however, is that the points at which these cells end seem to demonstrate a relationship as well. Taking to main thread.

"VQCmap2.png" is massive so here it is in 3 parts

>>6563

>>6562

>>6564

>>6565

Thank you :)

I got distracted and made an angle plotting program in Java:

https://pastebin.com/m7j61jCy

It's just something I slapped together–I was going to use it to see if I could identify some regular patterns in the grid by incrementing a ray in by a constant angle, then running it through several revolutions.

It hasn't been skinned, and there are a lot of issues…but it's a distraction and I don't want to invest any more time in it for now. It does, however, make some neat images :)

The image size height box actually doesn't do anything–the output is a square image dependent upon the value in the image width box, and the size of the window. I believe the "cap" image is independent of the window size.

The program runs when you increment/decrement the "rise" or "run" buttons. the little button next to those indicates whether the rise/run is multiplied by pi; there should really be a toggle that makes it so that only one can be on at a time, but that's one of many, many issues I acknowledge. I may go back and improve it someday, but there are more pressing issues at hand.

>>6526

Correction: they don't emanate up and left. They emanate left only. VQC just hinted that a fourth dimension would stack three dimensional objects in a line. This is three dimensions, rendered in two dimensions…and I believe what we're seeing is a stack of "trees" shifting leftward. I'll try to reproduce the effect graphically later today.

>>6596

I've been working on identifying patterns over the past two days. This has been my methodology:

First, I noted that the vertical line moves reoccurs several times to the left of the original. I'm going on a hunch and saying that this is a repeating pattern, and the vertical line is like the "trunk" of a tree. The pattern it follows is a shift one spot left, followed by a shift 3 spots from there, then five, then seven, etc.

Taking this into account, I looked for other instances of that pattern. I could already tell that the trend lines were repeating (as noted earlier). What I did not realize was what the trends were, exactly.

So I just drew lines along them, as in pic related. That was helpful, but the lines cross through a number of cells that may or may not be a part of the trend. So I tried to figure out which ones were–and it became obvious pretty quickly: you identify cells that belong to the trendline by noting whether or not the cells to the left of them repeat in the same pattern of 1, 3, 5, 7, 9, etc.

Going with that, I realized that there was a regular, definite pattern to each of the trend lines. This is probably fantastically obvious to most people, but I recognized that the patterns extended in rays from the n=1 line, always to the right, at a slope dependent on e's distance from the middle column.

For instance: from the e=2,n=1 column, go right two, down one, and continue onward: that marks a continuous, unbroken trend to the middle of the graphic, then continues onward in a trend of 4 to the right, 2 down (same ratio). There is no 1/1 trend, but there's a 2/2 trend starting from e=1,n=1. There's no 1/3 trend, but there's a 2:6 trend starting at e=3, n=1–that ones goes all the way down as well. In fact, I was able to identify trends for every even 'e' value in the n=1 row: the slope was always -1/'e' (rise/run).

In a larger graphic, trends would show up for other things–I found so many in the i=1024 graphic that I gave up. Needless to you start seeing things like "down one, over 498"; but you also see more multiples of those slopes.

As for odd slopes, there's the 2/2 (= 1/1) slope, and the 2/6 trend for n = 3. The latter one is special: it isn't mirrored on the other side. There may be others like it, but this one is glaringly obvious. I'm wondering if it's like a "leg" to another dimension.

I made a huge graphic that's small in memory, but huge in size:

>>6596

It's the grid cells, with text, overlaid by the trend colors. I'll upload more stuff if people find this useful or interesting. Also going to post in the new trend thread.

>>6636

Pic related is the underlying grid image from the previous post. You can take the "PixelDotsRight" image or the "pixelfamiles64icolorrays" image and overlay them on top of this to see what I mean.

Oh, here's the link to that huge graphic:

https://anonfile.com/Xcpeg4f5b8/outputRSA0_20480x10240_i_64_xMin_0_xMax_128_yMin_0_yMax_64_t_0_scalar160xWithTextTrendOverlay.png

It looks like other pic related, but the cell contents can still be read when zoomed in.

>>6638

Here's some things that I noticed.

>>6564

In the dark image compiling all of the rules, I'm not sure I understand this line:

<The x-intercept of the line that goes through the point containing all the factors of c is (a + 1)

Maybe it has something to do with the elliptical encryption part.

>>6656

That line in the list of rules is just a random statement somebody noticed that I put in. It isn't from Chris or even significant afaik

>>6658

Thank you for the clarification :) I was trying to figure out whether it meant "x-intercept" as in the place where a horizontal line was crossed, or whether it had something to do with the 'x' variable in 'e:n:d:x:a:b'

>>6683

Because:

a) I'm trying to look for a fundamental pattern being repeated

b) it seems so easy to get from the right side of the tree to the left, and

c) I've always thought the idea of "imaginary numbers" was a stupid way to compensate for not using vectors

d) I happened to notice that the "imaginary" side fills in so many gaps

…I went and "flipped" the left side of the image over the right, to see what came up.

Pics related are:

1. the original, 256 x 64 image with settings at imax = 64, xmin=-128, xmax=128, ymin=0, ymax=64, t=12

2. the original, with another copy flipped and superimposed over it

3. the left side flipped over the right side

4. with the left side set to red, the right side set to blue, the left superimposed over the right to show what they have in common, and what they have different.

5. the result of flipping one grid over another, and showing only that which they both have in common.

Note the "face" in center of the image in the last one. Beautiful.

Obviously when you mirror something, you're going to get a lot of symmetry…so a disclaimer is called for. But notice how the left side seems to fill in so many of the gaps? Several "horizontal bars" show up, particularly where n is an odd prime (n=13, for instance). There are crosses everywhere, reminiscent of a fractal pattern based on the cross…as well as pyramids.

Final note: I was wrong about the 1/3 slope not translating to the left side. It's mainly the 2/2 and 1/2 slopes, as you can see in the final image.

I just can't get over it. Will render in larger scale.

>>6690

Meh, not as dramatic…although one gets a sense of the Vitruvian Men with their arms horizontal, stacked on top of each other

If anyone would like a copy of the grid in binary, I've uploaded one here:

https://anonfile.com/N9V4h8ffb9/outputRSA0_256x64binary.csv

The settings are:

imax = 64

xmin = -128

xmax = 128

ymin = 0

ymax = 64

tmax = 16

I appended '-' signs to negative 'e' values, and '+' signs to everything else. Values are separated by underscores, and 'c' is added to the end, after '…'

I will probably make a smaller run and turn it into a graphic sometime soon.

I thought I had something big, but it didn't quite hit all the marks.

In terms of 'c', you can hit every prime number in the grid by moving left or right along the n=1 line, then moving down one and right two from each of the "nodes" in the n=0 line. Movement along these diagonals is simple: down-and-right is 'c' + 2, up-and-left is 'c' - 2. Although there isn't always a continuous line of cells to jump to, the nodes always seem to have values that ensure the pattern will work. For instance:

(-34,1) c = 495

(-36,0) c = 325, 364, 405, 448, 493, 540, 589, 640, 693, 748, 805, and 864

You can see that there is a value that fits the pattern: up-and-left, from 495 to 493.

Here's a harder one—a prime near the bottom, moving to the same node along the same diagonal:

(12,24) c = 61 //the prime

(-36,0) c = (same as above)

We're going up 24 cells, so we would be looking for a value of (61 - (24 * 2)) = 13. Even though there isn't one listed, as VQC has said we can have as many 't' values as we'd like.

Looking at the pattern, we see that it's increasing by 39, 41, 43, 45…etc. So if we went down from 325, we would likely get (325-37) = 288, (288 - 35) = 253, (253 - 33) = 220, (220 - 31) = 189, (189 - 29) = 160, (160 - 27) = 133, (133 - 25) = 108, (108 - 23) = 85, (85 - 21) = 64, (64 - 19) = 45, (45 - 17) = 28, (28 - 15) = 13…and there it is.

I say that this was almost big because, by moving along the n=1 line, and moving along these diagonals, you can hit cells containing almost every semiprime.

I don't think any of the grids contain the semiprimes of the form (2 * <a prime>). Other than those, I would expect to see these values:

>15 21 33 39 51 57 69 87 93 35 55 65 85 95 115 145 155 77 91 119 133 161 203 217 143 187 209 253 319 341 221 247 299 377 403 323 391 493 527 437 551 589 667 713 899

Because all semiprimes show up a least twice in the grid, I was able to find cells along either the diagonals or the n = 1 row for all of them except: 69, 115, 161, and 341. The first three are multiples of 23; the last is (11 * 31).

Oh wait. Figured it out. Taking to main thread ;)

//main thread is locked at the moment, posting here so I can get some sleep

I think I figured out something major—it's so simple, I apologize in advance if it's already known.

I've spent the last two days trying to figure out a way to map all the primes and semiprimes. I thought I had it when I realized that the cells containing every prime and 90% of the semiprimes lie along the "down one, right two" lines extending from the (0,0) cell and the 'nodes' to the left of it; unfortunately I was missing some.

Then I realized something: values in the cells aren't restricted to that pathway at all. In fact, they can move either up and left, up and right, down and left, or down and right, along either 1/1 or 1/2 lines.

This is how it works:

When you receive some number 'c', you chart a pathway to one of the 'nodes.' This pathway must be along either a 1/1 or 1/2 line (pic related). As you move up-and-left along a 1/1 line, subtract 1 from 'c'. As you move up-and-left along a 1/2 line, subtract 2 from 'c'. If you move up-and-right along the 1/1 line, add one to 'c'; and add 2 if you move likewise along a 1/2 line.

Similarly, if you want to get from a 'node' to a value, work in reverse fashion: subtract 1 or 2 when moving down-and-left, add 1 or two when moving to the right. It doesn't necessarily have to be movement between a node and a value, either–it can be movement among any two cells, or jumps between cells, so long as movement goes along those lines.

Travel along the 'nodes' at the top should be relatively easy; I'm not sure if we've figured out a way to list values for t < 0 (or if it's even possible), but the values in each node follows a predictable pattern of constantly-increasing (or decreasing) increments; for instance, at (e=0,n=0,t=1), c = 1; the first cell to the left (-1,0,1) c = 3; then next 'node' (-4,0,1) c = 5. The one after is a bit of a problem: (-9,0,1) c = 16; but if you look at the values, you can discern a pattern:

{-9: 0: 5: 3: 2: 8}___16

{-9: 0: 6: 3: 3: 9}___27

{-9: 0: 7: 3: 4: 10}___40

{-9: 0: 8: 3: 5: 11}___55

…

From t=3 to t=2, c=40 and c=27, a difference of 13. From t=2 to t=1, there's a difference of 11. The next logical 'c' would be a decrease of 9, which would give us 7–exactly what we need to continue our pattern of increasing by two for every node to the left.

That's just one pathway, of course, among likely infinite pathways.

Since every semiprime seems to show up at least twice in the grid, you can always find one that lands along one of these lines–or at least, that's been my experience thus far. I've also found a way to 'jump' to an equivalent cell on the opposite side of the grid (where e = -f, n = n). Not sure if it will work in all cases, but there will be a way (see the "recycled bread" thread).

I've also found that all squares show up in the columns to the left of center, at odd values for 'f'; only one value per column, that may show up several times (or not at all).

Again, apologies if this is old. There's a lot of ground to cover, and this isn't exactly clickbait reading ;)

It's been a long day…

>>6690

Major correction:

I kept referring to the left side of the grid as the "imaginary" side. Dumb. The left side is defined by 'f' instead of 'e'.

Whereas 'e' would represent the difference between the nearest smaller perfect square that could be taken out of 'c' and 'c' itself, 'f' is the difference between the nearest larger perfect square and 'c'.

So, take c = 15, for instance: the nearest smaller perfect square would be 9, and the nearest larger perfect square would be 16. So from 15, we would get a cell corresponding to e = (15 - 9) = 6, and a cell corresponding to f = (15 - 16) = - 1.

>>6762

I'm starting to realize that the pathways don't seem to matter.

As far as the values for 'c' go, you increment or decrement as 'e' increases or decreases; for instance, if you have a value 'c' and are trying to match it to a node 6 squares to the right, you increment your value'c' by 6 and you should find a corresponding value in the node (again, I'm calling 'nodes' the cells in the n=0 row). It may not be showing in the grid, but if you follow the pattern of c[t] elements, one should match up.

Now that I think about it, I believe VQC said something about being able to find "all factors" for something in a given column. So it looks like I might have triumphantly stumbled upon, and was amazed by, what is probably obvious to everyone else.

>>6808

Posting this graphic anyway.

Noticed that you can reach the lower square from many (perhaps all) semiprimes that are less than iMax by moving up one, left two in jumps. For example: on a 64 iMax grid with setsize = 12, 33 will be at (-3,11,1). If you jump up and left four times, you'll get to 'c' = 25, at (-11,7,1). Going by the method in pic related, you know you have to move four jumps because 'c' drops 2 each jump, and you need to get to 'c' = d^2.

Similarly, 51, 55, and 57 are all down-and-right from 49 in the central column, at appropriate distances.

For odd-numbered semiprimes with even-numbered squares below them (such as 36 would be d^2 out of 39), a combination of movements is required. For instance, you can get to 36 at (0,0) from 39 in (3,2) by jumping 2 left, up 1, then diagonal up-and-left (moving left 3 takes 39 down to 36). At another 39 cell, it's possible to jump down-and-left in the same fashion to get to another 36. It doesn't seem to work for one of them (the one in the same diagonal as the 33 cell in line with 25). Unless there's more t-values hidden in the 0 column.

Way beyond tired at this point.

How you get to the matching 'c' cell higher in the column is a mystery so far, even with smaller numbers. For instance, the two cells containing 'c' = 33 are 10 rows apart; in fact, for every semiprime I've check so far, I've gotten an even number of rows

separating them. This number tends to increase as 'c' values increase, but not always. The values for 49, for instance, are 18 rows apart, whereas the values for 51 are 16.

Here's a massive, ~24k x 6k image of the grid:

http://anonfile.com/S3Zfnbf7b1/outputRSA0_24576x6144_i_512_xMin_-1024_xMax_1024_yMin_0_yMax_512_t_12_scalar12x.png

This one marks each individual 't' value by a line of color in the cell:

Primes are red, Fermat primes are dark red, perfect squares of primes are brown, squares green, perfect squares dark green, cubes darker green still, semiprimes blue, compound numbers light gray, empty 't' values white. I tried filling the cells, but the values were already hitting over 1 million in a 16 x 8 grid with tMax = 12—I would've had to rewrite my code to work with BigIntegers instead (maybe some day).

Pic related is a smaller version, i = 32.

Going through the old threads, you can see that everyone went crazy over the Golden Ratio, and how it could be used to isolate primes. I tried using the formulas posted, with no success. It had always confused me, as the instructions were to do a modulus with the Golden Ratio, but the Golden Ratio is an irrational number (ie, floating point). Unless there's something I'm missing, you can't use the modulo operator with floating point numbers. I tried using the (a + b) / a, but if the goal is to get the golden ratio, dividing by integers is always going to truncate–so even if the real answer would be 1.618…, it would truncate to 1. If the goal was to extract primes, then the formula if(a % GR prime){ do something } means you already have a list of primes or a function to find them…so no point in bothering with the modulo, just say "if(a prime){ do something }"

Assuming I was missing something (and I probably am), and knowing that all of the primes were in the spiral, I figured maybe it was really "if ((e + n) / e) % GR == prime){ etc.}. I started drawing GR's over the grid—a from the top to the outer-edges of the spiral. It didn't take long to figure out that it wouldn't work (see yellow rectangle in pic related). So instead I started drawing rectangles along the boundary—this is easier said than done; t can be a somewhat arbitrary decision as to which point to pick as a boundary, especially on the left side.

I started from the bottom, where the lines where more clear. My data points were:

e n

1 -1

4 -2

5 -4

8 -8

9 -12

12 -18

13 -24

16 -32

17 -40

20 -50

21 -60

24 -72

25 -84

28 -98

29 -112

32 -128

33 -144

36 -162

37 -180

41 -220

44 -242

45 -264

48 -288

49 -312

52 -338

53 -364

56 -392

57 -420

60 -450

61 -480

64 -512

65 -544

68 -578

69 -612

72 -648

73 -684

76 -722

77 -760

80 -800

81 -840

84 -882

85 -924

88 -968

If you throw that into a spreadsheet, you'll find a recurring pattern—for every 8n, the slope decreases by -1/e (disregard negatives when programming, this was just for graphing).

For instance, the last point was at 88,-968. 88/8 = 11, and -968/88 = 11. At (80,-800), you have 80/8 = 10, and -800/80 = 10. This pattern continues every four points, and it's the larger of the rectangle series that I used.

So the function would be (e / 8) = (n / e) → e^2 = 8*n → n = (e * e) / 8

if(n >= (e * e) / 8){

draw pixel;

}

something like that.

Pic related is the function y = -x^2/8, superimposed over the grid with rectangles.

I think CollegeAnon (GA now) was working on this, and probably got it. This is how I came to it myself.

Finally, this won't extract the diagonals—it's just the boundary for the spiral. I actually just found a pretty good way to (mostly) isolate the diagonals:

if( (n - 1) >= (f * f / 8){

do stuff with e,n,d,x,a,b;

}

if(n >= (e * e / 8){

do stuff with f, n-1, d+1, x-1, a, b;

}

I'd love to say I planned it, but it was an accident. I'll refine tomorrow. Here's the results:

http://anonfile.com/50Sdp5f0b9/outputRSA0_3072x12288_i_2048_xMin_-256_xMax_256_yMin_0_yMax_2048_t_6_scalar6x.png

I'd noticed before that the Fermat Primes were the only ones that occurred outside of the spiral, but I'd never noticed that those outside occurrences line up with the ends of certain diagonals (see darker red cells, pic related).

{2: 1: 1: 0: 1: 3}___3

{-1: 0: 2: 1: 1: 3}___3

{-4: 0: 3: 2: 1: 5}___5

{-8: 4: 5: 4: 1: 17}___17

{-32: 112: 17: 16: 1: 257}___257

One the 'f' side, their 'd + 1' values are the Fermat Primes that precede them. Not sure how often this occurs among primes. Since they occur just to the left of the spiral, they can be probably be described by the same function, offset by 1 (ie, n = e^2 + 1).

If one moves along the diagonals starting from 5 at (-4,0) and counts all the primes between it and the next one (17 at (1,5)), you find 3 of them—which is the previous Fermat Prime. If one counts all of the primes after 17 at (-8,4), to 257 at (1,113), you get 85—which is (this Fermat Prime) * the previous Fermat Prime. I was going to hand-count from 257 to 65,537, but you know…

All kinds of magic going on here.

Here's a 7k x 28k zoomable image of the spiral, with t=1 entries readable in the cell:

http://anonfile.com/WaH7q0f5b4/outputRSA0_7040x28160_i_512_xMin_-64_xMax_64_yMin_0_yMax_512_t_1_scalar55xWithText.png

Despite the huge size, it's only 2.4 MB. I've had issues with such large images on mobile devices, but they work great for desktops–especially if you want to mark them up in a drawing program.

I'll post another version soon with some 't' values in each cell; if anyone has a request, just say so.

The previous versions from yesterday were missing some crucial cells; I've had to rig my filters, as they were cutting out e=0,e=1, and e=2 entries. I'll post them once I have something elegant and comprehensive; right now it looks like IRS code.

Color codes are: dark red for Fermat numbers, red for primes, blue for semiprimes, various shades of green for squares/cubes/4ths/etc, with darker meaning higher power.

The format for the cells are:

(e,n)

c

a,b

d,x

One thing I've noticed: following the pattern of 4,8,12,16,20,…,(n+4), as in cell (1,1), you'll find yourself hitting lots of primes and semiprimes (which makes sense, given that they're all odd and you're jumping by even increments). You'll find them converging on certain numbers; for instance, I started at 1, 5, 13, 25…, drawing lines on both sides of the spiral, and converged at 25, 145, and 841. At the first semiprime I'd reached (85), I tried branching from there–again incrementing by 4, 8, 12…and ended-up meeting the other lines I'd drawn at 145.

After putting together a program to check out the "tree" idea:

>>6515 (red text)

I came across this post too late:

>>3745

Unfortunately I'd done a couple on paper, and it seemed promising…so I got pretty far with it. The idea of a data structure that filled itself out with factors is pretty awesome. Unfortunately, it breaks down for larger values–plus, if you follow the methods I used (next paragraph), you'll be taking and checking square roots at every turn; that alone means it isn't VQC's method.

This is how I understood it (for anybody trying to figure it out): Take your input semiprime 'c' value, then take the square root of it. The result of the square root will go to 'd', and the difference will go to 'e'. If either 'd' or 'e' are perfect squares, leave them alone–they're roots. Otherwise, if they're divisible by two, divide by two until they become odd (I also checked to see if they'd become perfect squares). After that, take the square root again, branche to two more 'd' and 'e' values, rinse and repeat until every factor left is a perfect square. Add those all up, and you've got part of the semiprime.

In the examples, the values '2' and '3' were left as well, which threw me off for at first. But if you keep breaking those down in a similar fashion, you'll get two '1's for 2, and three '1's for 3—which sum to 2 and 3 respectively, so no point in breaking them down.

On a positive note, it was a lot of fun, good experience, and thanks to all of this rooting of small numbers I found a very, very slight issue with the BigInteger Sqrt function as given in:

https://archive.fo/XmD7P

For BigIntegers with values of 4 or 5, the result will come back as 1. Everything else seems to work fine, from what I've seen.

The variable walkthrough is as follows:

input 'number' == 4 (or 5)

high = number /2 = (4 or 5) / 2 == 2;

low == 0;

n = (high + low) / 2 = (2 + 0) / 2 == 1;

p = n * n = (1 * 1 ) == 1;

if(number p) → low == 1;

(high == (low + 1)) → break from while loop

return statement conditional:

is number p? ( false)

if true, return n (n == 1)

if false, return low (low == 1) → this is the value returned

Is it important? Probably not. It may not even be worth the fix, but if it bothers anyone then you can add this conditional after the one that checks if 'number' == BigInteger.Zero:

if(number / 2 == 2){

return 2;

}

or

if(number >1 == 2){

return 2

}

in java, it's

if(number.shiftRight(1).compareTo(BigInteger.valueOf(2) == 0){

return new BigInteger("2");

}

Onward to PMA's triangle number discoveries–the images that drew me here (along with Topolanon's stuff, sans ponies). VQC's latest hint is supposed to return a list of BigIntegers. I wonder if these are roots we plug into the PSLQ algorithm?

There is no worse feeling than being late, having to rush to catch up, contributing next to nothing and knowing that you're the dumbass in the room. If you're reading this and feeling that way, I hope I can come back and tell you it gets better…but right now I couldn't say.

>>7010

It turns out that VQC's Sqrt function is one off when taking the root of numbers 1-5 (off by one). The smartest way to correct it, if so inclined, would be to just check if the input is one of those numbers, and return the right answer.

I found another BigInteger Sqrt function that seemed pretty clever & efficient, but it kept giving small errors:

https://stackoverflow.com/questions/4407839/how-can-i-find-the-square-root-of-a-java-biginteger

I'd expected that it would've been a faster method, but after testing both that function and VQC's through 1-100k, they both finished in about the same amount of time–and VQC's was rock solid for everything past 5. The calculation of the roots (both with the library function, casting to a double then back to an int), and running the BigInteger Sqrt functions through 100k trials, then outputting the formatted results to a txt file took less than a second. Very nice.

*********

pics related are the parts VQC has given to breaking RSA encryption. Part 3 is where the triangles come in—I think Teach was the first to submit one of the images that have been used since this part was introduced.

Early on, the equation c = (d+n)(d+n) - (x+n)(x+n) was given. Since c = ab = i^2-j^2, you can see that (d+n) = i, and (x+n) = j. Obviously you're not going to be handed a grid when you get your public key, so I had been trying to get away from tying 'i' and 'j' to anything–I'd thought of them as just crutches for putting together the grid, but knowing that you can derive them so easily helps to visualize movement and relationships in a familiar manner.

As far as I have seen, every odd and even mod 4 semiprime, as well as every prime, can be found in the spiral—but it will only show there if the semiprime is less than your iMax. For instance, with iMax set to 64, you'll find 55 and 57 towards the bottom, where a=1, b=55 or 57. You'll find the factored version in the same column above somewhere (not necessarily at t=1). The key is to figure out how to get from the "bigN line", the one just mentioned, to the one above. From there, your 'a' and 'b' will be the two prime factors you're looking for. This is where I'm at right now.

It's interesting to note that every 'c' value at t=1 along those "bigN" lines, with a = 1, is a difference of two consecutive squares. This is necessarily the case: 'a' = i - j, so 'j' has to be one less than 'i'. Since all primes are, by definition, numbers that are divisible only by 1 and themselves, all primes are therefore the difference of two consecutive integers squared (larger - smaller). All primes except 2, that is.

Similarly, VQC has told us that all odd squares are composed of 8 * (a triangular number) + 1. Triangular numbers are of the form n(n+1)/2; for n = 0, T(n) = 0; n = 1, T(n) = 1…then 3, 6, 10, 15, 21…etc.

So we have semiprimes formed by differences of consecutive integers squared, primes formed by the same, odd squares formed by eight triangles defined by consecutive numbers, plus one. You get the sense that it's all just staring you in the face.

>>7028

Hey, just want to say keep at it. You're doing a good job, and while we're a bit ahead you're getting a really good introduction to the VQC!

>>7077

Thanks, I appreciate it :)

I've been away from this board, but still working on board stuff. I'm working on a program that allows you to fill the grid with a slider–I think seeing it actually fill will help me to understand it better & imagine where certain values might land. I also hope to be illustrating the individual values for each 't' entry, though I'm not quite sure how yet. Finally, I'd like to have a 'cart' of cell values, which will be added to their own slider. Ideally it will help to identify patterns and trends.

Pic related shows values from i=9, j=0 through i=9, j=8. It shows the basic idea.

But yeah, still here…just working on this program, checking /qresearch, and dealing with matters irl.

I've gotten to the point where I've animated the grid as it fills up. I'm made a video of it here:

https://www.bitchute.com/video/MOFRI8PPLXIa/

The magenta cells are the ones with t values being added; the animation works as Chris's original program does—filling up as a difference of two squares represented by a nested loop.

The fill pattern is fascinating: it's very much like watching a ball being dropped midair. It accelerates slowly at first, but soon picks up…it travels to the left then reappears to the right one row down, then faster and faster through a few rows until it 'bounces' off the left side, arcs downward and bounces again, until finally it hits the bottom center. It really has to be seen to be understood, but I'm sure there is much to learn from it. Wish I could've embedded it, but it's worth the copy & paste.

I'll probably work on this program a little bit more, then move on. Java seems to have dropped its support for 3D shapes that use quaternions; while I could probably do some form of translation into their current system, C++ is better for graphics so I think I'll be switching to the Qt IDE. That should allow me to plot the complex plane, and perhaps more.

>>7279

Just wanted to point out that the 'bouncing' effect is just an optical illusion.

The filling pattern starts with a value added at e=0,n=0. I've left the upper n=-1 line, which adds a value every time one is added at 0,0 (corresponding with every perfect square), so when a value is added at 0,0, one is also added to the n=-1 line, at f = -(2*i + 1). Considering the positive 'e' side, the next iteration gives i^2 - 1^2, since j = 1; this adds the first value in a new cell at e = 2 * (i-1), n = 1. From there, then next cell 3 spots to the left has a tvalue added that is three less than i^2; then 5 cells to the left and 'c' decrease by 5, until the e=0 line is met and it drops a row, continuing onward until it hits the bottom.

This pattern of increasing or decreasing 2n+1 is ubiquitous throughout the grid and tied directly to the fact that the difference between every consecutive perfect square is that amount; ie:

(n + 1)^2 - n^2 = n^2 + 2n + 1 - n^2 = 2n + 1.

The progression drops to the next row (increases 'n' by 1) once 'c' has decreased by a value greater than or equal to 2i; for every 2i it decreases after that, it goes down another row, which explains why plotting the grid in an area 4i x i (width x height) gets everything—the 'e' and 'f' sides, and all the rows.

I've noticed something else, although I'm not sure if it's of any use: the ratio of (e - f) / (N - n_upper) seems to have a logarithmic relationship for all 'c' values with a particular 'a'. For example, take c = 15 and c = 21 (3 * 5 and 3 * 7); if you were to be given '15' as a key, you would be able to establish the bigN cell on both the 'e' and 'f' sides; so take e - f for one the side of the rectangle; since we know that 15 = 3 * 5, find the difference between N and the n at a=3,b=5; that would be the other part of the ratio.

As 'c' increases for all semiprimes involving 3 x (some prime), the ratio of these two lengths seems to increase in a predictable logarithmic pattern; I haven't figured out how to describe it yet, though.

Is this useful? I'm not sure yet; Obviously we wouldn't know what the 'a' part (!= 1) of a semiprime would be, or else we could just solve the damned thing. But I wonder if we 'move around' a bit and see how things behave, if we might be able to gather enough information about what 'a' is.

Doubtless VQC has some elegant, mathematically sound solution that would be more efficient. For now, I'll continue working towards whatever that might be.

So rather than start up with the imaginary plane, I've been working on extending the Grid upward. I could swear I've seen a few images where that has been done already, but I haven't relocated them yet and I don't remember the method being posted.

Chris recommended that we extend it upward where 'x' becomes negative. For that to happen, 'a' would have to be larger than 'd', since

x = d - a;

The way I've read his direction, it seemed as if the imaginary plane was to occupy the 'z' axis–extending out toward the viewer from the flat surface of the screen. So I was making an effort to keep 'c' positive for this base grid. A while back, I'd considered the effects of making both 'a' and 'b' negative:

-a = j - i;

-b = -j - i;

Since a * b = -a * -b, we'll end up with the same 'c', which we can take a real root from. However, that wouldn't give us a negative value for 'x'; in fact, it would make it even more positive:

x = d - (-a); // = d + a

So we're stuck with many options, if we want to keep this base grid 'real' (which may not even matter). We can:

1) redefine 'd' for the upper half of the grid, to give a result smaller than 'a'

—this might not be such a bad idea, since we did add 1 to 'd' for rendering 'f' side values

2) swap 'a' with 'b', because 'b' will always be >= 'd'

3) redefine 'x' to equal 'a - d' for the upper part of the grid

4) set an iMin < 0

5) solve for 'c' = -c, and let the upper half of the grid represent only the 'real' part of the complex root

—you can't well have x = (some complex root 'd') - a, unless you want a complex 'x' answer.

Our requirements are that n <= 0, and x <= 0.

Each of these options has ramifications. Most importantly to me, the answers shouldn't break the existing equations we've already been given; when Chris told us how to fill the 'f' side of the grid, all of the components are still conceptually the same. So options 2) and 3) are invalidated.

So we have to ask ourselves—what is the conceptual nature of 'n'?

So far, I see four squares being of fundamental interest in the Grid:

1) i^2

2) j^2

3) d^2

4) (d+1)^2

i^2 is the largest possible value of 'c' for each 'i'. It is the larger square in our difference of squares.

j^2 is the smaller square in our difference of squares. Prime numbers != 2 only result when j = i - 1.

d^2 is the largest perfect square <= 'c'. We derive the right side of the grid from this.

(d+1)^2 is the smallest perfect square >= 'c'. We derive the left side of the grid from this.

Since we established the 'f' side to examine the (d+1)^2 relationship, I decided to set 'n' = j - d for the upper part of the grid. I haven't messed with any of the other values. And my results were pretty interesting (pic related).

Here's a video of the grid filling:

https://www.bitchute.com/video/kuXh6yP9T7Bl/

>>7359

Note that I don't think this is the way to illustrate the 'prime object' that we're working towards. I think the upper part of the grid should represent the real parts of the complex roots when we solve for -c, although I'm not quite there yet. But graphing 'n' = j - d extends our understanding of what's going with each value 'c'; it shows us how far both 'd' and 'd+1' are from that fourth important square, j^2.

It's also trivially easy to find the first one: for each prime or semiprime along the 'bigN' diagonals, they're one cell up.

So, let's call the 'n' = j - d value 'nu', for 'n upper'.

For each prime, there is one occurrence in the column. For each semiprime, there are two: one just above the normal one in the 'bigN' diagonal, and another one located above the second normal one (the one that holds the factored 'a' and 'b'. This second 'nu' cell also contains the factored 'a' and 'b' values; if we can find a way to get to this cell, we will have found our two prime factors. Thus, we have just doubled our possible routes to success ;)

>>7360

So Bitchute isn't exactly reliable unless someone is seeding, and I don't feel like seeding at the moment. I don't want to upload to youtube b/c we all know how Google has been ever since they lost their idealism. So I'm uploading the video here:

https://ufile.io/hsp8d

it will stay up for 30 days; I'll repost again later after that.

First pic related is the grid showing only values generated by setting nu = j - d. Second pic has n = i - d, and nu - j - d values. iMax was set to 128 here.

I thought this was cool.

setting 'e' and 'f' as usual, then using n and nu, I plotted four t values for every difference of squares i^2 - j^2:

(e,n), (f,n+1), (e, nu), (f,nu+1)

Then I filtered for the center part:

int emax = sqrt(iMax) * 2 + 1;

int fmin = -emax;

if(e <= emax || f >= fmin){

{…add values to cells}

The idea is that if a value is created that would land in the center region where the spiral would be, all other related values will be stored as well, regardless of whether or not they're in that region. So you get every prime and semiprime that would lie along the bigN diagonals, but you also get the columns above (where some of the nu semiprimes reside). It's interesting that it renders to this kind of angelic, four-winged shape was surprising–thought I'd share :)

>>7279 some great work here by PA.

Attached is mp4 grabbed from the link that can readily be saved offline.

Was doing something similar, adding a "Sequence" counter to the inner-loop of the original VQC algorithm and then looking at how the sequence changed based on sorting other variables in the resulting list of elements.