This is explainable with algebra. If d=t, depending on the parity of e, 2t will be within 1 of 2d. The square root of a number is very close to the square root of itself plus or minus 1.
Since I couldn't find any triangle visualization tools written in Java, I've been putting one together myself. It isn't finished. If anyone did already write one I must have missed it. Nobody will probably use this so it doesn't matter. Here it is, anyway. https://pastebin.com/3nDs75dy It relies on this GridCell object https://pastebin.com/HEC87GAQ
With colours now (that was fucking horrendous to get my head around): https://pastebin.com/4CE3tirj
I just wasted another 8 hours straight doing something that probably isn't going to solve the thing. I haven't even eaten dinner and it's already past midnight. I have a problem, and I think the only way I'm ever not going to keep doing this is either if I quit altogether or if we finally solve it. I don't know which of those is going to come sooner than the other.
We've been on the verge for almost a year but okay
I've been avoiding talking about this because I know I'm not going to get an answer that actually explains jack shit but what was the point of the rm2dnm1 thing from RSA #10? n0 is somewhere between f/8 and 1. We want some number between them that is greater than n and less than x+n. That divided f value is a staircase number. You put it into the rm2dnm1 function and it gives you a number that isn't 0 because it isn't going to equal the correct u value. We never seemed to do anything with that value aside from checking whether it was zero. What was the point of that entire thing? If n0 is never going to equal n, we're never actually going to use that function for the sake of checking that a number gives a remainder of 0 and is thus u. So we do want the remainder, and we do want a specific value from the staircase number, but what are we even using them for?
Now you put a and b in through terminal and you can iterate through all cells with the same x+n. For even n odd x, it takes one away from n (to make it an odd square in the center) and adds the difference to f.
Triangles - https://pastebin.com/Kjm6jhZE
GridCell - https://pastebin.com/KRg2QTH9
Max x+n is 649, by the way, because I needed to make it all actually fit on the screen so the minimum button size is one pixel. I don't know if that's big enough for what we're doing but VQC has never elaborated about what "big enough" is. It takes a very long time to load this since it has to make a maximum of 421201 squares and figure out whether they're fs or not (which was pretty complex, and works in a while loop iterating f by 8 each time). It's not very useful for iterating a and b at that scale (a-b=(x+n)*2 so to get the next (x+n) you just add or subtract one to a and b). In fact I haven't successfully waited through one with an x+n of 649. It might take a few hours. I don't know. x+n of 135 took a little over 10 seconds.
Here's a version that displays the (d+n)(d+n) square beside it in the fashion of VQC's diagrams. It doesn't work with very big numbers, or numbers that are quite far apart. That's because of how much larger (d+n)(d+n) usually is than (x+n)(x+n) (pic two is a good example of why it might not be super useful for bigger numbers (note that this is before I scaled them the same)). I might turn it into a bitmap generator at some point (I would be super grateful if someone else did but I know nobody will). So while this working with big numbers would obviously be ideal, it seems like the only way we'd get it working is with bitmaps. But I'm not sure.
(x+n)(x+n) and (d+n)(d+n) visualization in Java - https://pastebin.com/TV4Ud7j7
Now you can view the na transform and bign cells (if their x+ns are odd), and go back to the original. https://pastebin.com/rBEFuU05
Would definitely not recommend the bign button for large numbers (because of what I explained in that quoted post about (d+n)(d+n)) unless you remove the (d+n)(d+n) functionality, but even then it depends on the (x+n)(x+n) size.
The bign thing probably isn't working when you view a BigN cell for an even a even b cell, by the way..
"when something happens that justifies the amount of time I've put into this" != proof. If I didn't think this was real, why would I have spent all that time? That would be fucking moronic. What I mean is finding the solution. That would justify me destroying a friendship and completely neglecting university because I was spending too much time doing Grid Patterns.
Super constructive, thanks Topol
>I give you guys presents but I'm not sure anyone opens them.
>I have the barest understanding of the math you guys do.
I don't mean to be patronizing, but, I mean, duhhhh. I don't know who you are because your IP hash only has three posts associated with it, but chances are if you're complaining about nobody reading your posts because they aren't the same kind of math that the rest of us are doing, it's because you haven't done the following:
(a) read all of the threads so you understand the grid (it's not difficult, it's just time consuming - I was going to work on a simple guide in June (before that too) but nobody ever wanted to help me so it never happened). VQC explained it pretty well at the beginning of the first thread. We're finding a and b, the factors of c, c being any arbitrary number of your choice. c has a bunch of variables associated with it. You can grid these sets of variables with e as the x axis and n as the y axis, and they create infinite sets. Relationships between cells of variables (different a and b pairs) can be used to factor any arbitrarily large number. Understanding the multitude of patterns will lead us to the solution. Go read the threads. You don't turn up to a calculus class with a chemistry textbook and pass the class, man.
(b) figure out just how related your math is to the grid - if VQC is taking you seriously, maybe it's important stuff, but if you don't even understand the grid, how do you actually know it's related? Intuition is a strong thing, but you have to back your shit up with facts, anon. If we're all talking about (x+n)(x+n) and you're trying to relate the golden ratio to the Mandelbrot set, we're in completely different worlds. Apply it to the concepts we're all studying or we're not going to have a use for it (at least with our current objective).
(c) now that you'll know how the math we're doing works, you'll have the terminology and the context to apply your math to it in such a way that you can explain where you're coming from. We're working explicitly on what VQC is trying to explain to us. If you post something that seems like it doesn't have anything to do with that (like weird graphs with lots of geometric shapes in seemingly arbitrary places like that one anon), obviously you're not going to get very much attention. If it is related, explain in terms that we understand (i.e. with our math). Let's say you found out that f divided by d is equal to a (that's definitely not true but it's an example). Let's say you found it because you're super into geometry and you were messing around with the grid and found this weirdly shaped line. If you didn't understand the grid (which you said you don't), you'd be telling us "hey guys, there's this weird shape here and you really need to know about it" then all you're doing is showing us a weird line. What are we meant to do with that? We've seen lots of weird lines and none of them got us anywhere. If you understood the grid, you would be able to say "hey guys, f/d=a, isn't that neat". Then we'd actually know what you're talking about.
tl;dr: read the threads
Without seeing your code, it doesn't take into account
>(e,1)
>(0,n)
>triangles
>diagonals
etc so if you generate triangle diagrams and output the respective (e,1) cells, just as an example, during your process, it might display some patterns.
Well for a start, if you're starting in whichever column is odd, chances are it's different for odd e and even e, so you might just have to add one or divide by two somewhere. Just in general, you aren't utilizing every concept. While (0,n) and (e,1) might not be used in one particular solution, VQC said the three solutions he's aware of involve either (0,n) or (e,1) or diagonals. So as much as you could potentially find another solution, I think it's far more likely that you've found something that you're meant to use in conjunction with the other concepts. So maybe if you run your algorithm and every time you calculate a new cell you also find that cell's (e,1), for example, it'll have some important value in it, or its triangle configuration will have something in common with the solution cells, or something. My point is to start analyzing this at a deeper level. One other idea is that you could work backwards. If you're taking a cell and setting the square root of its d to x, you could take xx and xx+1 as potential d values in the cell that leads to the solution cell.
What does that picture with the mini yellow and green triangles represent? Is it c? All I've ever seen going through past threads is the picture itself and not an explanation, so I haven't been taking note of it since I have no idea what it is. It doesn't look like (x+n)(x+n) because of the whitespace. But if it's c, I haven't ever seen anyone break it down into smaller parts that aren't dd+e.
>introducing the diagonals
Other than a code comment mentioning diagonals, have they really been introduced to any significant degree?
Those aren't valid cells though
Getting back into it a bit. I found a pattern in regards to f/8 being less than or greater than the x+n triangle base u. It seems that there are specific j values which always seem to create an f/8 value which is greater than u. In this image, the numbers are the j values which, together with every i within a range of i values, create a cell with an f/8 greater than its u. The i constraints are the blue text beside each block.
HOW DO I TURN CAPS LOCK OFF?
Another joke answer would have been to say UTF-8. I don't know if you're VQC or someone else but I don't see how this question is meant to help other than in hindsight.
What about with 8?
VQC, please read this post and respond to it
As far as I can tell. I've finished getting all of the patterns and concepts together in the Grid Patterns thread >>6506 here. I have a couple things I wanted to ask about.
For whatever range of reasons, none of the other anons have been helping, and none of them have been proofreading or checking that I'm correct and that I haven't missed anything. That means it's probably likely that I missed something or that maybe something is incorrect. I know you of all people will know if anything is right or if anything important has been missed. There's a lot of information in that thread, but would there be any chance you might have the time to go through and check everything?
Secondly, in your explanations of (x+n)(x+n)=nn+2d(n-1)+f-1, you introduced us to n0 and the guess triangle base made of f/8 or f/(8*something). As far as I could tell going through the threads, you never actually seemed to do anything with either of these values. If n0=n and guess base=u, you can construct the (x+n)(x+n) square, but you even said yourself that we know n0 won't equal n and we know the guess base won't equal u. After explaining that, you stopped talking about n0 altogether, and only mentioned the guess base a bit cryptically. So what was the point of those variables?
Thirdly, with the grid patterns thread done, do you have any newer advice as to what we should be looking into? Is there anything specific (as in looking at this concept and that concept at the same time) that we should be doing that we can now that everything's in one place?
I'll "calm my feckin' tits" when getting a giant two-month-long set of work done doesn't get a response of "you have more work to do". I'll calm down when I'm not the only one who does that work (I'm not the only one who is meant to work on it by the way, don't know if anyone realizes that). I'll calm down when suggesting that we work on something together for once rather than hiding off in our own little research corners completely ignoring everyone else doesn't get a response (this is a direct quote) of "who cares" on Discord. This is ridiculous. Give me one good reason not to ditch this board and all of you lazy pricks and figure this out by myself, Topol. I might as well considering how little interaction there is between any of us that isn't just mindless chatting on Discord. I'm over being told to calm down when every time I do anything useful here I either get completely ignored or I get this bullshit.
>you're going about this as if I've earned the solution
How am I doing that? Topol told me to calm down. I told him why I'm not calm. Everything I'm saying is backed up with facts. I'm not just having a big emotional rant. These are genuine issues (to varying degrees).
>point 2: nobody helped me with grid patterns
Now if everyone explicitly told me "we don't think this is useful, maybe you should do it yourself", maybe I wouldn't mind so much. You actually said multiple times that you would help me with it (so did a couple of the others) and yet you didn't do anything. So this isn't me putting people down because they don't do what I want them to. This is people saying they will do something and never doing it.
>point 3: nobody is working together
I'm not the only one who has complained about this. Several other anons have. Isee was one. I think he was complaining about it on Discord. I suggested we work together on something for once and the only response I got was "who cares". That's a thing that happened. Do you think that's a useful outlook for everyone to have in regards to working together?
Now how am I acting entitled? Are any of the things I said objectively incorrect?
When did I say I was the only one doing anything? I said I was the only one working on one thing in particular. And then when I said I was done, someone told me to do more work (that they could do themselves, might I add). Also, I can admit I did snap that one time (that was generally a shitty period) but the only snapping I've done today is calling people lazy pricks. Nothing else I'm saying isn't based purely around facts. They might be angry facts, but they're facts.
>And yeah, when you finish one thing and there's more that needs to be done… what kind of response do you expect?
When it's something VQC told all of us to do, and it therefore isn't just my job, I don't expect a response of "there's more work to do, go do more work".
>But you're not uniquely frustrated and we don't deserve to be the butt of your anger
All I'm doing is pointing out things that I think are problems. If there's a bit of anger in there, it isn't for the sake of making people upset.
>and frankly, neither does Chris.
Would you like to point out where I got angry at Chris? Because as far as I'm aware I didn't do that.
No offense to whoever posted these if they're new and they're just firing off whatever ideas come to them, but is there anything we can actually use any of these posts for?
I don't think VQC posted any of those. They're the kinds of musings we all had at the beginning, which makes me think it's a newfag with a dynamic IP or a VPN. When VQC has crumbs, he posts more specific stuff like >>7746 this. Whatever the case, I really don't see how I was acting pissy towards VQC.
Maybe read my post again because I never said they were unwelcome. I said I don't think VQC posted them because they're musings and VQC posts more specific hints about variables.
I'm going to take that break I mentioned now. Good luck people. See you in a month or two (or earlier if something happens).
Before I take a break properly I suppose I should apologize for getting angry and calling you all lazy pricks. That's quite obviously not true. I stand by most of the rest of what I said, but it's inconsequential at this point, so I promise I won't mention it again. All I'll say is that >>7999 was pretty unnecessary.
Would you mind responding to this (or telling me you aren't going to respond)? >>7986 The red text was just to get your attention since you miss questions semi-often (whether intentional or not).
One last thing: based on >>8040 this, when you take the cells in (e,1) and (-f,1) where the two x values add together to make na, b-a in the (-f,1) cell is na+3 and b-a in the (e,1) cell is na+1. This is only tested on odd na so far.
Here are some test cases:
Find the element/cell where the x is equal to one of the staircase numbers for na/(n-1)a
(30:1:6) = {30:1:75:10:65:87} f=-121
(-17:1:6) = {-17:1:63:11:52:76} e=108
na=65 (so where x=32 and 33)
(30,1,17) = (30:1:559:32:527:593} f=-1089
(-17,1,17) = (-17:1:569:33:536:604} e=1120
b-a=604-536=68, b-a=593-527=66, na=65
(13:7:7) = {13:7:26:13:13:53} f=-40
(-40:6:8) = {-40:6:27:14:13:53} e=13
na=91 (so 45+46)
(13,1,23) = {13:1:1064:45:1019:1111} f=-2116
(-40,1,24) = {-40:1:1084:46:1038:1132} e=2127
b-a=1132-1038=94, b-a=1111-1019=92, na=91
(13:13:7) = {13:13:20:13:7:59} f=-28
(-28:12:8) = {-28:12:21:14:7:59} e=13
na=91
(13,1,23) = {13:1:1064:45:1019:1111} f=-2116
(-28,1,24) = {-28:1:1090:46:1044:1138} f=2151
94, 92, 91
(69:5:10) = {69:5:62:19:43:91} f=-56
(-56:4:11) = {-56:4:63:20:43:91} e=69
na=215 (107, 108)
(69,1,54) = {69:1:5866:107:5759:5975} f=-11664
(-56,1,55) = {-56:1:5912:108:5804:6022} f=11767
218, 216, 215
It might be useful to look into d[t]-d and a[t]-a in these cells, as well as comparing them to the cells where cBigN and cshadowN show up in (e,1) and (-f,1), and where x=f-1.
Man, I've been angry for a while, huh? I've just been reading through older things. I'm really sorry everyone. I've had a shitty year and I didn't realize I was taking it out on you guys. This is the last I'll post about this whole thing, I swear. Don't mind me. Back to math.
Gaps?
That's only useful when it's happening actively and throughout multiple threads. Since VQC keeps IP hopping, without trips, there's no way to prove any of the posts in this thread other than the ones with his trip before he posted those passwords are actually him. 90 days from now, there'll be nothing tying him to any of the IDs in this thread, since the hashes will reset. I'm not sure what you actually wanted to achieve with me screenshotting his posting history.
At risk of coming across as frustrated (my intention with this is to understand your perspective, not to figure out how to use the VQC), surely you realize that since you figured out something so monumentally unheard of, and since you're posting about it so cryptically, obviously we're not going to figure out what everything you post means, right? As much as you're probably completely sure you've given us enough information to solve this, and that connecting two tiny, obvious dots would solve it, O(log t) where t is the length of c in bits is extremely vague.
I hope you've at least got the will to get out of Amsterdam instead of giving up.
Wut
So if this was Jan then it isn't necessarily what the hint was about.
I found a hole in the whole “each pair of e and f only has one set of n and n-1 values” thing from >>8111 here.
>//given two columns, which values of n are separated by 1
That was the code comment. So the idea is that for your given semiprime c (which has a unique set of d, e and f), in that specific pair of e and f columns, there will only be two pairs of n and n-1 values (prime n and BigN). This isn’t true. Take 13*43=559, for example. e=30 and f=-17. Starting from n=1 (ignoring it though obviously), these are the n values that appear in the e=30 column:
3, 5, 11, 13, 15, 17, 23, 29, 31, 33, etc
These are the n-1 values that appear in the f=-17 column:
2, 4, 8, 13, 16, 17, 19, 26, 32, 34, etc
The valid pairs of n and n-1 are [3,2], [5,4], [17,16], [33,32] and so on. So there are actually probably infinite valid pairs. The only thing unique to [5,4], the correct one, in this case, is that there are two cells within these that share a d value. But that’s not what the comment said:
>//given two columns, which values of n are separated by 1
It doesn't say anything about d.
I have a life outside of this board, gosh well, occasionally
You talk a lot like VQC for someone who isn't VQC.
>I think VQC recognised AA is about to unleash the solution.
If I am, I'm not consciously aware of it. As much as VQC (totally not you) did seem to think I would be the one to figure it out first in that one post, it would be pretty great if someone else did. I wouldn't want to get delusions of grandeur.
Thanks.
If anyone didn't see, very important post in Grid Patterns by some anonymous stranger: >>8262
O(log n) means you divide the search area by two each time (e.g. binary search). So what does O(log n) where n is the length of c in bits mean? The only way it could translate is that your search area (for lack of a better term, not knowing the context) is c in base 2, and you’re dividing the search area (c in binary) by two each time you don’t successfully factorize. So what's the deal with this, anyway?
There's nothing in row zero in positive (e) space, and in negative (f) space there are only cells in row zero where f is a square (so (-1,0), (-4,0), (-9,0) etc). It's not row one but it does have a relationship with row one in that all of the cells in (e,1) are also in (f,0). So I don't know if that was just an arbitrary thought or not but I guess that might actually be worth looking into.
All cells in (e,1) are in (f,0); (e,1) doesn't have gaps but (f,0) does (every f value that isn't square).
Definitely a 145 fluke. All odd numbers are the difference between two squares, but it's a series that scales linearly with the squares (well, linear with their square roots). https:// math.stackexchange.com/questions/136/why-are-the-differences-between-consecutive-squares-equal-to-the-sequence-of-odd
d and na don't scale linearly so it's not going to be the case for all of them (it also wasn't in the test cases I tried, for the record). 145 always seems to get everyone's hopes up.
Based on your wording, it seems like you're implying a row. But all that boils down to is "use d to find n".
>The problem I think we are solving is find a base b where last digit of a number is 0.
And how did you come to that conclusion? Have you read through all of the threads?
Okay, first of all, obviously you figured it out in that second post but you should really be quoting people you're responding to on this website. Secondly (and don't take this personally because it's an ongoing issue with this board that multiple people have contributed to now), do you actually understand specifically how we're working? Keep in mind, I have no malicious intent with this message, and for all I know you could be onto something useful, but people keep coming to this board, completely ignoring the specifics of the work we're doing, going through their own personal idea of what the point of this board is in relation to factorization, posting what they're working on, and wondering why nobody is responding to them or helping them with it. This has happened multiple times and you're doing the exact same thing. Another recent example is when that person who was messing with the Fibonacci sequence thought they'd solved it and all they'd done was iterate squares (which doesn't come close to solving the problem). You're welcome to keep working on your thing. Who knows, maybe you'll figure it out on your own. That is a genuine possibility. All I wanted to say is that there is a very slim chance of any of us working with you if you aren't actually going to get up to speed on the rest of our research. For example, do you know what (d+n)(d+n)-(x+n)(x+n) means? Do you know what d[t]-d=a(n-1) means? Because that's what the rest of us are working on.
Actually, one last thing.
>The problem I think we are solving is find a base b where last digit of a number is 0.
In base 2, everything that ends with a 0 is divisible by 2. In base 10, everything that ends with a 0 is divisible by 10. So if you take any number, the final digit will be 0 in any base for which the base is a factor. So if you take a prime number n, it'll only end with a 0 in base n. If you take a semiprime a*b=c, it'll only end in a 0 in bases a, b and c. So effectively you've rearranged the iteration method (the one we're trying to avoid because it's O(n)) into iterating bases. I would very strongly recommend reading all of the threads and getting a complete grip of the issue.
Why does what work the way it works?
Hey Jan, in relation to >>8185 this, if you didn't already figure it out, taking the square root of a number halves its number of bits. So O(log t) where t is the length of c in bits refers to taking the square root of c over and over.
Okay what's the deal with this crumb?
>if a number at position t has a factor s at (e+1), then s is a factor at (s+1-t), (2s+1-t), etc for a at (e,1)
No matter how I interpret this in my testing, it doesn't work out. Before anyone says it, yes, my t calculation is right ((x+2)/2 for evens, (x+1)/2 for odds).
Here's an example.
(30,1,31) = {30:1:1875:60:1815:1937} f=-3721
This is the cell in (e,1) where t=(e+1). It's divisible by 11. So 11 should be a factor of a at (33+1-31)=3
(30,1,3) = {30:1:27:4:23:33} f=-25
23 is not divisible by 11.
But if interpreted differently (since it's a very poorly worded crumb in my opinion), maybe it refers to (e+1,1).
(31:1:5) = {31:1:65:9:56:76} f=-100
If a number at position t has a factor s at (e+1). (e+1) is 32.
(32:1:5) = {32:1:56:8:48:66} f=-81
48 is divisible by 12. So s should be a factor at (12+1-5)=8
(32:1:8) = {32:1:128:14:114:144} f=-225
114 is not divisible by 12.
What is this supposed to mean? I would really appreciate some help.
I took it from Grid Patterns, but I don't remember where it was when I originally put it into Grid Patterns. I remember it being VQC who said it but I might be wrong. He seemed to be the only one using s as a variable in this sense.
It's basically the same wording as
>If an integer p is a factor of a[t], then p will be a factor of a[p+1-t] for ALL cells in row n=1
(which was VQC at the start of Grid Patterns), just without the (e+1). But I've found I have the same problem with this pattern as well. Whenever I try to apply it, the cell in question isn't a[p+1-t] away, it's a[p+2-t] away. The more I try to figure out why, the more I think I've done something wrong, but my t values are definitely as they should be. I have also seen several people in old threads and in Grid Patterns mention that they haven't been able to get this crumb to align with their grid. So have either of you tested with this one? I'm trying to sort Grid Patterns at the moment so it would be useful to figure out if I'm wrong or the crumb's wrong (I don't think I ever actually saw anyone use it, so I haven't seen confirmation, only confusion).
I'm trying to verify if it's me or the crumb. That's why I'm asking someone else to check. VQC isn't often wrong.
Anyone ever figure out what this means?
>Each value of a in cell (1,1) is also the long side of an integer right angled triangle.
Don't worry, I figured it out. https:// en.wikipedia.org/wiki/Kepler_triangle
The values of a in (1,1) are the only valid whole integers that work as hypotenuses based on a^2+b^2=c^2 (whatever that's called, something something Pythagoras, it's been a long time since I learned about that). So it boils down to a in (1,1) being the sum of two squares, which was already a well established pattern.
No you didn't.
This is not finished, but if anyone's brave enough to trust a pdf and has a spare minute or two to critique my formatting, it would be useful to know if I've structured the enumerated patterns well or if I should do anything differently. There are a couple of sections I'm going to add (like a list of the numbers that would solve the thing if we found them and such).
Already with the new IP huh? You don't waste time.
>Offset of 1 doesn't seem helpful at first does it. What about offset of 1 in a and b. Doesn't that give the factorization.
Yes it does. It gives 2(BigN-n). It also gives a cell for which (e+2n,n) is the solution record. The real question is how to get there with d and e, of course. If anyone reading this has time before me (I'm going to sleep soon), it would be useful to look at the cells in (e,1) and (f,1) where the x values add up to 2d+1 (maybe compare them to all the other (e,1)/(f,1) cells, since this is another calculatable).
Maybe it would just be easier if I showed you my (e,1). There's nothing wrong with d or x, so I don't see why there would be anything wrong with t.
>>8349 (thanks)
Pretty much all of the main points (other than specific hints like switching e and f for the totient value) that Not-VQC has been making for the past month or two have been "the fractal is based around d and e". It's been rephrased in very many ways, but that's the point. This only addresses the fractal. It doesn't address how you actually use the factors of d and e to factor c, which is the entire point of this board. So this is my thinking as to the logic behind it:
>you're meant to be able to factor c using d and e
>if you can't use d and e to directly factor c, you have to factor them, and so on, recursively (and since taking the square root of something halves the number of bits, this creates an algorithm that factors numbers in O(log n) time where n is the number of bits in c)
>there are three types of c for which a solution is already directly calculable (GCD(d,e)>1, e=0, f=(x+n)(x+n))
>if these don't work, we're meant to rely on factoring d and e to factor c (hence the decision tree wherein if you can't automatically factor c you bit trim and factor d and e - bit trimming turns numbers into the difference of two squares, meaning we can apply them to the grid and then multiply them by two to get them back to the original number)
>if we're meant to factor d and e to find c, and recursion stops once c is directly calculable, that means that in one particular layer of c, we're using both d, e and their factors/records/n values/incalculables (not just d and e, but also a layer down)
So something that would be useful to research would be finding all calculables and all incalculables for c but also for d, d's d, d's d's d and so on. It would also be useful to keep in mind the thing about bit trimming when doing this. We have a finite number of knowns and unknowns (although there are probably infinite knowns and unknowns, Not-VQC said a few days ago in Grid Patterns that the information required to factor c is definitely in that thread), and we have to bridge the gap between them. That doesn't mean a known is directly used to calculate an unknown. Otherwise we would be done already. It means that the solution lies in the application of everything: the big list of cells in (e,1) and (0,n), the concept that the a values in (e,1) are the sum of squares and the difference of squares (plus or minus a constant based on e), the various movements we can do horizontally from (0,n) (or from other origin points), the idea of triangle numbers and doubled squares turning up in (0,1), the idea of consecutive squares turning up in (1,1), the relationship between smooth numbers, (a-1)(b-1) and ab and (a-1)(b-1) having the same (x+n)(x+n), and the application of all of this to d and e recursively, comparing everything to the next value up in the tree. We wouldn't have learned about all of these things if it was going to be as simple as moving around throughout some records in (e,1). It also wouldn't be as hidden as it is if that were the case. Apologies for the wall of text.
It's the same as yours. I have a spreadsheet for (e,1) and (f,1) so I just use these >>8356 formulas for it.
I actually think this might be a problem of odd versus even. I've discovered that this works when e is odd but it's p+2-t for even e. Go to your (30,1).
(30:1:4) = {30:1:39:6:33:47} f=-49
33/11=3r0. 11+1-4=8.
(30:1:8) = {30:1:127:14:113:143} f=-225
113/11=10r3, so it doesn't work. However, at t+1,
(30:1:9) = {30:1:159:16:143:177} f=-289
143/11=13r0. p+2-t. Is yours like that?
But then using (3,1) (and I've now tested this on a couple other cells)
(3:1:4) = {3:1:33:7:26:42} f=-64
26/13=2r0. 13+1-4=10.
(3:1:10) = {3:1:201:19:182:222} f=-400
182/13=14r0. So it seems to work for odd e.
I find it odd that VQC would neglect to mention that when he brought up that idea many times. Usually when he misses something out it's just the once.
Hey Not-VQC, I'm curious about something. I'm not asking for a hint right now, but I think the perspective of someone who figured it out already would be useful. If you were in our position, and you had this giant set of information but absolutely no idea what to do with any of it, what would you do? When you enumerated all of the patterns, what was your next step?
The a values in (-1,4) are the sequence of triangle numbers. The a values in (-1,2) are two times the sequence of triangle numbers.
Every d value in (-1,1) is two times a square minus 1 (this is also the sequence of ns in (0,n) where a and b are both squares but with each value minus 1).
Every a and b value in (-1,1) is four times the triangle numbers. They add together to make every even square (so every even (x+n)(x+n) is in here (4T(u)+4T(u-1)), as well as 2(x+n)(x+n) for odd (x+n)(x+n)). So since a+b only comes up in the n equation n=((a+b)/2)-d, you could rearrange it such that the a+b you want, which comes from (x+n)(x+n), equals 2(d+n) for (-1,1). For example, 4+12=2(7+1). Since d here is two times a square minus 1, but a+b=2(d+1), and if you add 1 to d you’ll have a square multiplied by 2, you’ll by multiplying twice a square by 2, making it 4*square. All a+b values in (-1,1) are equal to 4 times a square, and all a+b values in (-1,1) represent every possible even square.
4+12=16, 16/4=4 (2*2)
12+24=36, 36/4=9 (3*3)
24+40=64, 64/4=16 (4*4)
>metacognition
>Metacognition is "cognition about cognition", "thinking about thinking", "knowing about knowing", becoming "aware of one's awareness" and higher-order thinking skills
I tried to start a discussion about where recursion actually comes in on Discord a little while ago but everyone ignored me. Maybe if I bring it up here it'll gain traction. We need to take a step back and put all of the patterns and such into context within the algorithm. What we have is a big list of patterns and cells. What we need is a recursive algorithm.
How is it that we can actually use the grid recursively around d and e? The idea that we need to bit-trim d and e in order to factor c means that we don't have enough information about c just from d and e in order to find the correct record/the lookup x/the na record/the triangle base/etc. We have a giant list of rules, movements and patterns that are meant to be used. However, the fact that we need to factor d and e through the factor tree unless c is immediately factorable (through GCD, e=0 or f=(x+n)(x+n)) means that there isn't enough information just from that big list of patterns. We've been taking an incorrect approach to this for quite some time, I think. Everything I see any of us looking into (including myself of course) is related to finding connections between the finite set of cells that we're aware we can generate with our prime solution record. If there was any possibility that we could bridge a gap between the BigN cell and the prime solution record entirely with patterns revolving around c, not only would it completely bypass the bit-trim factor tree, but it wouldn't be recursive at all. It would be O(1). Where c is immediately factorized is the recursion termination point. We factor d and e recursively (that's what VQC said a bunch of times).
So what is the missing link between a factorization of d and e and a factorization of c? Looking into anything else isn't going to solve it; it's just going to expand our list of patterns. This idea of metacognition is actually extremely useful right now (thanks Chris).
>it would be O(sqrt)
O(sqrt) is O(log n) where n is the length of c in bits, which is what VQC has always said. Taking the square root of something halves its number of bits.
>I see the bit trimming as a means to simplify.
>I suspect that VQC has been giving us hints related to all the keys he knows. The recursive one I suspect is one method. The triangle one is another and I suspect the (n-1)naa is a third.
If the recursive solution was one of several methods, there would be one O(log n) method and several O(1) methods. The only way anything VQC has said makes any sense is if every method relies on factoring d and e. That means we have to know the factors of d and e to solve. That means there isn't enough information purely from c to solve.
If we only calculate d and e for one c, it isn't O(log n). It's O(log n) if we calculate d and e continually, because in the worst case we would halve the number of bits log n times (but we wouldn't always have to do that). If we were only meant to calculate d and e for one c, it would be O(sqrt), which is different, and definitely not what VQC said.
>If we need to go recursive and we need to factor d and e, does that mean the other approaches VQC has talked about in the past (triangle, -f and e … ) are just approaches that won't work (or will, but with a too high complexity)? Or do you think it all ties in together?
My theory is that we use those approaches in conjunction with factored d and e. We wouldn't have learned those things for no reason. My theory is that we use a fully factored d and e in order to apply those approaches that we currently can't use. So the cells and numbers for 5*29=145 could be used to factor other numbers for which d=145, maybe.
Crap, missed our anniversary by a day
I wrote a program (in Java) that creates the factor tree and generates every relevant cell and value that we've studied throughout the tree for each c/d/e/d's d/d's e/etc. You need the GridCell class I wrote for it to work (also below). I didn't bit-trim throughout the tree. I just divided each number by two until it was the difference of two squares (so it has evens that are divisible by 4 and odds). It also isn't done with BigInteger. I'll have to rewrite both programs with BigInteger at some point because it isn't completely functional without BigInteger (for example, generating the cells in (e,1) and (f,1) where cBigN and c(BigN-1) creates integer overflows). Either way, here it is. My thought is that it'll be quite useful to look for patterns that occur between all relevant information for c and all relevant information for d and e.
everything.java - https://pastebin.com/mbH8eZ7s
GridCell.java - https://pastebin.com/Cn36RwPA
>Got a present for you AA anon.
>Where a value, c first appear in row 1 at e for the value a[1], t=1?That is a column e.
If c is semiprime and the difference of two squares, it'll be odd. Any odd number c appears as a[1] at (2c,1), since for even e in (e,1) a[t]=e/2+2(t-1)(t-1), and a[1] is e/2+2(1-1)(1-1)=e/2. So for example c145 appears as e[1] at (290:1:1) = {290:1:145:0:145:147} f=-1. It'll also appear as a[1] at (2c-1,1), since for odd e in (e,1) a[t]=(e-1)/2+(t-1)(t-1)+tt, and a[1] is (e-1)/2+(1-1)(1-1)+(1*1)=(e-1)/2+1. (289:1:1) = {289:1:146:1:145:149} f=-4
To simplify: since all a values in (e,1) are twice a square or the sum of consecutive squares (based around t) plus either e/2 or (e-1)/2, but we're choosing t, we can just take 2(t-1)(t-1) and (t-1)(t-1)+tt away from c to find e/2 or (e-1)/2 and therefore calculate the columns in which c will appear as an a value in (e,1).
>Where does it next appear in row 1 at a different e for the value a[t], t=2?
2(2-1)(2-1)=2, and 145-2=143, and then 1432=286, so it'll appear in (286:1:2) = {286:1:147:2:145:151} f=-9. (2-1)(2-1)+(22)=5, 145-5=140, and (140*2)+1=281, so it'll appear in (281:1:2) = {281:1:148:3:145:153} f=-16
>And so on back towards the origin.
Where c145 appears as a[t] in (e,1) with t increasing from 1 upwards, to begin with for even e is 290, 286, 274, 254, 226, 190, etc. -4, -12, -20, -28 etc. The gap between cells increases by 8 each time for even e. For odd e, 289, 281, 265, 241, 209, 169, etc. -8, -16, -24, -32, etc. The gap between cells also increases by 8 each time, but the first started at 4 and this one starts at 8.
>Every column that c appears in has what in common?
They're all in (e,1) so they follow the (e,1) patterns of every factor of this particular number having a valid n in this column. So in every column that follows the above pattern, there'll be a valid cell at the a and b we're trying to find. There are probably other things but I'm assuming that's your point.
>How many columns do you need to create a lookup?
That depends on what other information is required for the lookup, and we don't know that.
I've rewritten my program that outputs everything from Grid Patterns (unless I missed something) down the recursive d/e factor tree for BigInteger. Pic related is a small section of example output. You need the following two java files:
https://pastebin.com/mvrvxVr4
https://pastebin.com/NjGYV8ip