The Holy Grail Of Mathematics.

halbower · 11-12-2008

I've reviewed the formula you have on your website. Unfortunately I cannot confirm the claims you have made.

The formula does indeed return prime numbers. However, it stops at 31. From then on, it is inaccurate.

I typed in your original value (2.566,543,832,171,388,844,467,529) into cell E4.

Here are my results using Excel

<Column E> ..... <Column F>
2.56654383217138 ..... 2
3.53017698972142 ..... 3
5.65848774684910 ...... 5
7.59315571766559 ...... 7
11.80128555035950...... 11
13.72794005216370...... 13
17.85861344125680...... 17
19.79936393159150...... 19
23.76889830664600...... 23
29.91292840834680...... 29
31.76590818607170...... 31
40.47482526462880...... 40
84.24151573163120...... 84
347.80343057844900...... 347
431.89792535625600...... 431
479.99535484443000...... 479
481.23541336079800...... 481
2043.21453281222000 ...... 2043

The formula stopped identifying correct prime numbers after 31. It missed 37 but picked 40.

Here is the Excel formula I used:

(Column E formula) (Column F formula)
=(E4/F4-1)^-1 ..... =int(E4)

I dragged this formula down. Above you can see the results. If there is an error in my logic, please post it.

CraigD · 11-13-2008

Using exact arithmetic starting with Don’s estimated value of

$A = \frac{2566543832171388844467529}{1000000000000000000000000}$

, I get a slightly different, but similar behavior for the generating function

$A_n = \frac1{\frac{A_{n-1}}{\lfloor A_{n-1} \rfloor}-1}$

to what Hal calculated using a spreadsheet:

Code:

Prime     A
  2       2.5665438321713888444675290
  3       3.530176989721365539402422
  5       5.658487746849688216649061
  7       7.593155717658844724384335
 11      11.801285550493624044601748
 13      13.72794004986556753523763
 17      17.85861349763730877250927
 19      19.79936263147479092664292
 23      23.76893696537426002453788
 29      29.91142451944074443786296
 31      31.81832327464107973441092
 37      37.88233936471712759962716
 41      41.93397855694896393020755
 43      43.89822410263364625518520
 47      47.87224020589233116148280
 53      53.88423932134315471134298
 59      59.93852424419815301864134
 61      62.86465199458734434295017
 67      71.70514887852601938925004
 71     100.6879570572559038006540
 73     145.3579099818760320973203
 79     405.129801745018365638482
 83    3120.14295295257072632134
 89   21825.36242793846740266
 97   60218.86748657202264851
101   69416.63645535693254109

with failure at the 18th prime, 61.

I’m guessing, however, that Don believe that a higher precision estimate may increase the number of correct primes the algorithm generates. Unfortunately, I don’t have such an estimate handy. When I do, I’ll retry the algorithm, and see if does, though based on trying it with +/- an additional digit of precision, I don’t think it will.

modest · 11-13-2008

Don,

I'm quite sleep-deprived and at the moment, so whatever I'm about to say may not make too much sense... We'll see...

First, the latex. I wish you'd invest some time in it—it's really not difficult once you get the basics and it would help everybody out. If i've followed your parentheses correctly, this might be right:

$\frac{\left[\left(sin(x^{(1/2)})\right)-1\right]^{-1}}{\pi^2+\left[\ln\left(\ln\left(2\left[\left[2(x^{-1}+1)\right]^{-1}+1\right]\right)\right)\right]^{-1}}-1=0$

I put your value of x,

2.566,543,832,171,388,844,467,529

in your equation,

((sin(x^(1/2)))^(-1)-1)^(-1) / ((pi)^2 + (ln(ln(2*((2* (x^(-1) +1))^(-1) +1))))^(-1))-1

using PERL at 100 digit accuracy and got:

-0.000000000040019755626388018650144802402308556

Solving recursively gives these results:

2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 62 71 100

Which has diverged by 62.
The incriminating x is shown here:

Code:

int = 2, x = 2.566543832171388844467529000000000000000000000000000000000000000000000
int = 3, x = 3.530176989721365539402422018201306850039197136533050911036155166398856
int = 5, x = 5.658487746849688216649061411000589507461664004153497197119476215483240
int = 7, x = 7.593155717658844724384335263645162617947202893363521789006038087166225
int = 11, x = 11.80128555049362404460174832837998655716729063627250228160779891806179
int = 13, x = 13.72794004986556753523763397429744246725502028275445142599165199144844
int = 17, x = 17.85861349763730877250927709413576433988653038229942139918833510613291
int = 19, x = 19.79936263147479092664292299016437987747272027540063908052642739544050
int = 23, x = 23.76893696537426002453788600930707468800883412711664132116378903885593
int = 29, x = 29.91142451944074443786296806872299704308061095064639403832115527561836
int = 31, x = 31.81832327464107973441092377400036596929785102069880661037360711858067
int = 37, x = 37.88233936471712759962716274091303887571471394483018993191178809579994
int = 41, x = 41.93397855694896393020755651340059733680483703198842232377858911936599
int = 43, x = 43.89822410263364625518520937029838556476463991279448629612635446175649
int = 47, x = 47.87224020589233116148280327819598753456306848077071626646202280455230
int = 53, x = 53.88423932134315471134298755419452646380031791291086201039183094297123
int = 59, x = 59.93852424419815301864134307323740915524877993867733325427721822943831
int = 62, x = 62.86465199458734434295017417326336564096459114688595539499977255560361
int = 71, x = 71.70514887852601938925004856643131493693668265094361525152064731910683
int = 100, x = 100.687957057255903800654040248040422266009951714500281856818692090863
int = 145, x = 145.357909981876032097320383702656272557004669693397154358459436022770

This is pretty much what Hal got above.

~modest

EDIT: and nearly exactly what CraigD reported while I was posting

Don Blazys · 11-13-2008

To: Halbower,

Don't mistake the constant: 2.566,543,832,171,388,844,467,529 for the formula.

I don't know a lot about computers, number crunching machines, or calculating devices, but doing it by hand, the above constant returns:

2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, and 59,

before it "breaks down".

However, in theory, if you can calculate the second root ("zero") of the equation (the one involving sin and ln) to an infinite number of decimal places (instead of just the 24 decimal places that I calculated by hand), then that constant will return all of the primes in sequence!

Most hand held calculators are accurate to only about 10 to 14 decimal places, and the computers here at my school can't do much better. That's probably why the largest prime that you were able to generate was only 31. Your machine was simply not powerfull enough.

Anyway, now that my formula is "on line", a lot of very good mathematicians will be checking it using very sophisticated equipment. If it is demonstrated that my formula stops working after some finite number of primes have been generated, then I will be quite surprised, because in my humble opinion, it's simply too beautifull to be a mere "curiosity".

Don.

Don Blazys · 11-13-2008

To: CraigD and Modest,

Please don't trust my calculation of the second root. It has a good chance of being wrong. The equation is the important thing.

Also, thanks Modest, for putting it in LaTex.

Don.

modest · 11-13-2008

Quote:

Originally Posted by Don Blazys

Please don't trust my calculation of the second root. It has a good chance of being wrong.

I understand. How did you approximate it? What method did you use? I'm quite sure I would not be able to find its derivative.

Here's the graph,

The 4 zeros shown are 0.6445..., 0.8818..., 2.5665..., 2.8816...

Off to bed...

~modest

Don Blazys · 11-13-2008

To: Modest,

I used a method that I developed while researching "cohesive term derivatives". I performed that calculation about five or six years ago, and the notebook that has those details is probably in storage somewhere. (I moved several times since then.) If it will help, I will try to find that notebook and pass on the method, but that might take a few days because my stuff is scattered in several different locations.

I can't get your graph no matter how many times I click on it.

Also I don't calculate .8818 as a "zero" but as -6501.971... , so it's probably an asymptote, and not a zero.

By the way, your LaTex rendition is almost correct, exept for the subtraction of unity at the end. That subtraction is performed on the entire term, not just the denominator. Thanks again for putting it up!

Some of the teachers here at my school are also busy working on it, so I will keep you posted as to how they fare.

Don.

CraigD · 11-13-2008

Here’s a way to generate a starting value $A_1$ for Don’s generating formula

$A_n = \frac1{\frac{A_{n-1}}{\lfloor A_{n-1} \rfloor}-1}$

so that $\lfloor A_n \rfloor = p_n$ , where $p_n$ is the nth prime (tested for for the first 500 primes):

Begin with $n=1$ and the required inequality $p_n \le A_n < p_n +1$
Find algebraically $A_n = \frac1{\frac{A_{n-1}}{\lfloor A_{n-1} \rfloor}-1}$ , in terms of $A_1$
Solve the inequality $p_n \le A_n < p_n +1$ for $A_1$

Repeat steps 2 and 3 until you reach the desired $n$ .

For example:
$2 \le A_1 <3$

$A_2 = \frac1{\frac{A_1}{A_1 -2} -1} = \frac2{A_1 - 2}$

$3 \le \frac2{A_1-2} < 4$

$\frac{10}{4} < A_1 \le \frac{8}{3}$
…
$A_{10} = \frac{-192139677A_1+493134904}{200096592A_1-513556674}$

$\frac{15899835124}{6195037437} < A \le \frac{15386278450}{5994940845}$

... etc.

We can chose any value for $A_1$ that satisfies the greatest calculated inequality – choosing the equal value is a simple approach – and apparently be assured that we can calculate the primes up to $p_n$ using the generating formula.

To calculate the first 500 primes, $A_1=$
15073501454785746503327091792962580591389206596526 00133549958380812810366757065165351318863631121898 05088754668679404598405121140813129245153847730993 93116509224752615940520003349154516425731185540082 59720407821367807798119833292681432062301410370166 87595771322742390600315862122981380451503984941013 34800684765266878898731551080382057654332637777486 32943198726169060409838120619186737957385991864898 55274616712201322918797753182154374051901221643883 08401766200477671118778327976210659735624862328586 54963066780224690489741076518122543117075679553767 58134262077627499223084667550517509611291538649922 08460238041218167876258927758793873301156390329695 35787423752095874364099117082335959343236194781869 72886625439746358323543512860509390358963174892812 65616242291119899374599969237532278684445540152984 51998416667184097363645972478112430523253964734220 76268583872122010581309397796346550653512552762485 95775610026648609817260298625497878997388257097535 76389848126764707897188538012447534195114955790616 97513612836491589890200742469194942463622908742939 93685646066690793380712604662528277300752124615787 24024530729266658923876586891907943895406986125247 04527450013918513134098568308270445036996462945736 23401790800331999699278498314366466909118704288985 55504579399015828342165596477078211567396867561475 51693410894474070767164406309132429842346723176869 33263707673552995625299796709090068177685616423896 12184638886621898222564362672335971585149068968247 82659781043594073403139800623663367541651686138885 872797450033244899419
/
58730738457846712369826340648262300633444774983907 27638266470778615269971491665292322225550636323727 54943340292103730657241691107153212108006659110244 64444770069930762507049531752637095218702389563004 72671868034817523690954322826747978305232455713996 87221852110421144555772121627571238069919574312740 48312379712629723341277003483291278684987121090006 26392300980002192789352679079225669038538890282612 84250178662854328449539356908826372721147168559966 64330689080391442436234172363357128809712568640285 52418881599095254738336534436713440365888751446751 17634496607542124955096038497033007244704964526059 75105655789135940034413587214516108465042554163865 21028442559206881777089783965958129667817613706287 76604714941819486417598979802494861589879134463748 18647330634494353063371357000253993696192631497701 12032251322960920621433350293561696141471983174423 94244812297335112625826911481807488979992082072996 60744328690074587438204488162872696499342308524534 77143250845949228820778990534996717795255491921406 90007422880905267135023089484844501042549679306933 06291594975237393982723807460588492750996826237514 54177772504536730456144965905046511411264070667199 24718802040995924070029066445783627538937500713488 05373121101080095139634333461592440688781377704280 34253092196717448161422579637632820776337529951366 36204873845712523463654881671059209464838378854429 30354015090055056827775381445045083954590638547452 81683836154075418844349120501524322858819407545882 84285228929351709031168647854498330163790059744137 56096393667894862622

is precise enough. (Its denominator is 1520 digits)

Because each calculation requires only a few multiplications and additions, it's an easy calculation to make, much easier than the calculations to approximate the Sine and logarithms and iteratively approximate the zero of the function containing them.

Although I’ve not proven that this method will always be successful – its possible that some $A_n$ that satisfies $p_n \le A_n < p_n +1$ will not satisfy $p_{n-m} \le A_n < p_{n-m} +1$ – it appears to for all calculations I can make in a few minutes. More importantly, we haven’t proven that the $A_1 = x$ as given by

$\frac{\left[\left(sin(x^{(1/2)})\right)-1\right]^{-1}}{\left[\pi^2+\left[\ln\left(\ln\left(2\left[\left[2(x^{-1}+1)\right]^{-1}+1\right]\right)\right)\right]^{-1}\right]}-1 = 0$

If modest or someone else with a working program like the one in post #28 can modify it to use the new equation (it shouldn’t be hard to differentiate, needing only the product and chain rules, and some carefulness), it would be interesting to compare A few hundred digits of the estimated zero of $X$ to my big rational number above. To 500 decimals, it’s:
2.566543832171388844467529106332285751782972828702 31464596973352546639971989040034622398857147805665 89415300383386252694557180837585065234733899407590 15452147716305617441237846500920651165442820986967 99444086469195021290029958254446835359571462522431 94189226038317025371635511355609594950080639727211 11188080630943369037911871522603146919231148726991 01382281616159570290924835490077516263817781701705 01465893712305852748021584934680316196223087098420 52492295557540633289790051335145247812827882458860 36944358849212875826884884990827579513115666424648 20849280217151229993076859757596523704399063065354 07925624047164609395479942464328914535244340335467 28912555946828300675869093272900644507789827817806 46572326075380709000130766143755442519632323931974 44101894793461926400851780595643049017923189817237 13680529972307807980157357353519124741233224426245 55334814040204030157123671369216800571313500108714 69609483401152427491436846808849436797566037679245 00002211023112680763023278357128661735500471600507 58990823559294731332935283691934260732135205234475 64201678214095278196584532234664894564878811714234 31083061423838155882272075651801199499190609973138 44551046494747202015388384536230021753436402688469 88608135948517199422762601630425131670162358528085 11288133812294558351146855290775139229175383801288 73184842938429816881693161821371821961182096793893 94076251757447174244597019651368333949030078114849 02520373497194268565900019623252488180600825909134 66896412315136908706594026416435982690876451518198 999891129443265858404.

I’d be wonderstruck if they match, but have no clue why they should, other than Don’s “just so beautiful” argument.

From a practical computational perspective, like so many candidate prime number generators, this one’s not very useful, because in order to generate many primes, its $A_1$ must be very precise, and arithmetic on very precise numbers take a lot of computing time and CPU. From a math insight perspective, however, it’s wonderful if true, and a nifty (and maybe not easy) exercise to prove true or not.

halbower · 11-13-2008

Quote:

Originally Posted by Don Blazys

To: Halbower,

Don't mistake the constant: 2.566,543,832,171,388,844,467,529 for the formula.

I don't know a lot about computers, number crunching machines, or calculating devices, but doing it by hand, the above constant returns:

2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, and 59,

before it "breaks down".

However, in theory, if you can calculate the second root ("zero") of the equation (the one involving sin and ln) to an infinite number of decimal places (instead of just the 24 decimal places that I calculated by hand), then that constant will return all of the primes in sequence!

Using your logic, if we calculated the second root zero of the equation to an infinite number of decimal places, it's entirely possible that the returned values it is currently giving would be off. For example, using the constant
.566,543,832,171,388,844,467,529 gives us accurate values to 59. However, we may find that using the true number (to infinite decimal places) gives us INACCURATE results before reaching 59.

Feral_Squirrel · 11-13-2008

wow!!! I wonder if we have a Ramanujan Jr. in our midst

excellent work Don!!

my first impression mental inclinations on this discovery are similar to Craig's.. namely that the need for so many accurate decimal places will detract some from its practical applications.. but the over-arching excitement of this is still intact and palpable IMO...

IMO it would be like finding a triple relationship between Planck's Constant, PI, and who knows what else... Making such a discovery I would feel like I was at the entrance to a labyrinth of unknown depth, and be intensely wondering what goodies are at its center and various side rooms. And whether any indwelling minotaurs were open to bribery.

Should it hold up to the ultimate scrutiny of your peers, I hope you are financially rewarded in some way, in addition to other deserved accolades.

Applying it to the Mersenne challenge might indeed be one road to cash, but then again if the test of primality involves searching for every possible composite pair... not sure how that would fit in.. or trump the Lucas–Lehmer test in speed... oh well in any case good luck sir, may the cash make its way into your bank acct with all due haste hahaha!

oh hey! idea! well on second thought this may be very trivial and obvious... but gonna mention it just in case this has some relevance or research value:
I wonder if the GIMPS team and other Mersenne researchers have numbered their primes... one of the very nice properties of your method is that X tells you which prime in the infinite sequence it is... and from what I understand the Mersenne research proceeds as a huge leapfrog, from one primal vista to the next as (2^n-1)'s n is each time bumped to a higher prime... I would presume that by doing so they are leaping over hundreds if not thousands of interval plain-jane primes that lie between the Mersenne milestones, if you will, and thus have no freakin idea what sequence # their primes have.

and since your method has the very nice property of knowing what X you are at... i wonder if there is a relationship just waiting to be unearthed in how the X proceeds from Mersenne to Mersenne... like just for example.... gonna throw out some random numbers that for sure do not correspond to reality but just to make the point... say Mersenne Prime #43 has an X of 111 and say that MP #44 has an X of 222 and MP #45 has an X of 333... always this bumping of X by 111.. that might be a cool track to search for patterns on.... but then again if the test for Mersenne primality somehow authoritatively goes through all the smaller numbers that would imply there is a pretty strong chance that they do already know what X they are at... hmm... but if Lucas-Lehmer is strongly oriented for speed and weakly oriented for authority, like I suspect it is, that leaves a door open for somebody to leap thru yay... and even if these science teams do know every sequence #... it still remains possible that nobody amongst them has bothered to search for any occult properties or patterns in their values.

well i'll stop babbling lol.. not sure if i'm making sense haha... gonna first look into the matter of if the sequence numbers have already been established or not.

The Holy Grail Of Mathematics.

Hypography?

Share the love!

Sponsors

Friends