I need advice on how to crunch numbers with Mathematica. Someone helped me before and used the monitor class. I want to see the process as the computer computation occurs. In the console Mathematica will indicate processing in the menu bar, but I need assurance it is doing something and how far along the process is.

In my posts, this one and previous, I have tried brute force the semiPrimes smallest factor after I estimate where it occurs. I will provide and example here as a notebook. I have criticism that it is trivial, that my attempts are futile because 10^37 is still to large to crunch. But I took the error of the equation I used to estimate the value and I feel it is close and that it is useful because it significantly reduced the number of values to try.

Either way I want to crunch large numbers. Anyone have any tips or resources?

4.08615746000780408833983218761558688141378368019671197 × 10^37

Thanks Daniel. Sorry for my late reply.

The computations work, but are the goal of the computations correct?

I mean it looks good and all, but what I am trying to do is factor large RSA numbers. The last one was a 2048 bit one. Mathematica gave me the values that would be close to zero in my equation. I claim that the smaller semiPrime factor will occur on the graph of the equation where y equals zero.

So did Mathematica give a correct number where the equation equals zero? And if that number is correct does my hypothesis of where the smaller SemiPrime factor occurs hold true? How do I use Mathematica to confirm?

Well I am confident that these equations will find the magnitude of the smaller factor of the SemiPrime. You find where the graph equals zero and test to see if the x value before zero is the factor. (I know that testing from largest x value before the y value equals zero can also be computationally intensive.)

I can not get it to work with a 128bit SemiPrime because the calculation is too large. I get the error that pnp is not a machine size real number.

Is there any way to analyze the graph to find where it equals zero visually without trial and error?

Thanks Daniel. Sorry for my late reply.

The computations work, but are the goal of the computations correct?

I mean it looks good and all, but what I am trying to do is factor large RSA numbers. The last one was a 2048 bit one. Mathematica gave me the values that would be close to zero in my equation. I claim that the smaller semiPrime factor will occur on the graph of the equation where y equals zero.

So did Mathematica give a correct number where the equation equals zero? And if that number is correct does my hypothesis of where the smaller SemiPrime factor occurs hold true? How do I use Mathematica to confirm?

105951 105950

105909 105910 105911

Ok on an odometer when there are at least 3 matching numbers say 555 or two sets of repeating numbers, say 5500, then we will try to predict when each occur chronologically on the odometer.

Sure you could just fill in the numbers with the corresponding numbers. But imagine these numbers were related to Prime distribution. The pattern is harder to see with the odometer as it moves linearly.

Imagine you have a regular odometer. It goes zero through nine. So in the single-digit place of the odometer (the start of counting), you note that 3, 5, 7 are Prime. So now you go to the tens-digit. And note that 3+1 or 3+3 or 3+5 or 3+7 are eliminated as Prime. To get another Prime number you would have to add an even number to 3, 5, or 7.

Of course adding an even number doesn’t always result in a Prime. This is just a graphical representation of a sieve. But just as repeating numbers in the odometer are hard to predict linearly throughout the revolutions of the odometer, are we not doing the same thing when looking for patterns in Prime numbers?

I study Prime numbers because I like finding patterns. Patterns can confuse or look like they could be there, but patterns are what we see in math. I might have stretched the truth when I claimed RSA was in trouble, but that one-way function is why I started all this math in the first place. The odometer sieve would require a lot of calculation. Again it would only show what is going on. It is the same with my graphs. I can only estimate where the semi-Prime factor is on a graph. Graphing 128-bit numbers and analyzing the graph is a challenge, but necessary to prove as the curve on the graph approaches zero x approaches the smaller Prime factor.

That is where I believe if the graph holds true, for larger N’s, it will be superior to brute force.

But as the graph becomes larger and more difficult to evaluate so does choosing an N. I have read that if N becomes too large, the enciphering of the message becomes too cumbersome.

In a future post I will be sending a graph. But It is important for anyone reading this to share if they had any results with the graph. I have tried to make the graph more useful (less test values) by inverting the equation.

Thanks. That was helpful. I don't need it to be exact though if I knew the rate of error I would get a better estimate.

Is there anyway to find the x intercepts? I have tried solve but it is just as computational demanding as factoring. I think my method works. If you look at the graph you get a fast estimate, but I can make the range of test numbers smaller but the RSA number is still safe because I can't crunch it.

This is the smaller factor of:

RSA-2048 = 2519590847565789349402718324004839857142928212620403202777713783604366202070 7595556264018525880784406918290641249515082189298559149176184502808489120072 8449926873928072877767359714183472702618963750149718246911650776133798590957 0009733045974880842840179742910064245869181719511874612151517265463228221686 9987549182422433637259085141865462043576798423387184774447920739934236584823 8242811981638150106748104516603773060562016196762561338441436038339044149526 3443219011465754445417842402092461651572335077870774981712577246796292638635 6373289912154831438167899885040445364023527381951378636564391212010397122822 120720357