The Holy Grail Of Mathematics.

[Qfwfq]

I'm also concerned and very confused that this converged after only 7 iterations. I wasn't expecting that at all. :confused: I used:

[math]x_{n+1} = x_n - \frac{f(x_n)}{f'(x_n)}\,\![/math]

I was also thinking it might be a tad more than 7 iterations but of course it all depends on how much it differs from linear in the interval; once the second derivative has a consistently low value each iteratation improves precision muchly.

 

Anyway that's the right expression for the increment, the best way to be sure is to have each residue printed as well, this way you could hardly go too wrong, but as far as precision goes when reaching the numeric type's resolution one need to watch out for computational caveats.

 

Greater accuracy than that (I tried 500 digits) was getting into very significant calculation times.

If the natural log is computationally lightweight a trick migh improve times, although not in quasilinear cases. This place is closing...

 

Would that make a difference in how the computer performs the calculation, and if it does, then can the "intersection" result be used to verify the "Newtons method" result?

Er, no. The graphic interpretation is irrelevant to the method.

[modest]

@500 digits (took hours), x =

 

6.22071562877864521059396967031

3416058685026190653406984465260

6975787315898018449813080427575

5047236089986553666526211212228

2582152764102504185301445876882

1758023982143107611879667495337

3863345212891628638680669171900

8234079808915612501562283150922

3008738517287542763446572627235

8463586832147018101705513403268

8276829275105127873450791589259

6625179577008443871192357568135

7106032592021060326157333916052

5743623563530918921431489655185

9866630347739868615224858990142

0556594477955367710536794228194

67301

 

f(x) =

 

0.00000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

0000000000000000000000000000000

000005

 

once the second derivative has a consistently low value each iteratation improves precision muchly.

Indeed. I was incorrectly remembering the Newton method from college thinking the rate of convergence was linear. According to wiki, it's at least quadratic.

 

By the way, my hat's off to PERL. :shrug:

 

~modest

[Don Blazys]

To: Modest,

 

Hi5!, Yoodaman!

 

Very impressive. I too have been busy, simplifying my formula, and preparing several different versions. That way, you will be able to choose the one that you feel is the most "computer friendly". I should be posting it around Tuesday or Wednesday. (Thursday at the latest).

 

Don.

[modest]

been busy, simplifying my formula... I should be posting it around Tuesday or Wednesday. (Thursday at the latest).

 

Excellent. I'm rooting for your formula :shrug:

 

~modest

[CraigD]

All of my favorite hand-made calculators are exact precision integer and rational number based, but I could cobble together trig and logarithm approximating functions to some defined precision pretty quickly, and solve

 

[math]\sin x^{\frac12}-\ln\ln x = 0[/math]

 

Using a simple binary search. An answer to a couple of thousand decimal digits precision shouldn’t be too hard.

I was overoptimistic about the precision I could get in a reasonable amount of computing time using exact arithmetic. :( Though I’ve had some interesting, educational, and time-devouring experiences trying to optimize the approximating formulas

 

[math]\ln x = \sum_{n=0}^{\infty} \frac2{2n-1} \left( \frac{x-1}{x+1} \right)^{2n-1}[/math]

 

(a key to using this iteratively is to exploit that [imath]\ln x_n = \ln \frac{x_n}{x_{n-1}} +\ln x_{n-1}[/imath], allowing the input value to be increasingly close to 1, where the approximation converges most quickly).

 

and

 

[math]\sin x = \sum_{n=1}^{\infty} \frac{(-1)^{n-1} x^{2n-1}}{(2n-1)!}[/math]

 

(which presents more of a challenge, as I don’t yet know an optimization such as the above for it)

 

To avoid the [math]x^{\frac12}[/math] term, which doesn’t in general have an exact rational value, I’ve been using the substitution [imath]Y= x^{\frac12}[/imath] to solve

 

[math]\sin Y -\ln\ln Y -\ln 2 = 0[/math]

 

The main speed trouble I’m seeing is due to the size of the rational number returned by an iteration of the approximation is larger than that of the rational number of its accuracy (the difference between the returned value and the previous iteration’s, AKA the delta). For example, 128 iterations of approximating [imath]\sin \frac{74}{100}[/imath] results in a value with a 927 decimal digit denominator, while the delta is about [imath]10^{539}[/imath].) Also, with exact rational arithmetic, the computational effort of a calculation depends not only on the number or iterations (in a worse-than-linear way), but on the size of the input rational number (it’s numerator and denominator).

 

In summary, many thousands of digits of precision for an approximation of an expression involving sines and logarithms using exact rational arithmetic looks a lot harder than I’d guessed a few days ago. My hat is also off to the built-in high-precision calculators for these functions in packages like Perl’s and Ruby’s. And, or course, my hat is always off to that old genius Newton – for those who can be bothered to take a derivative, Newton's method is a much better (about 47 times better, from Modest’s results) approximating method than my usual choice of a binary search.

 

I’ll keep experimenting with exact arithmetic approaches to transcendental functions especially the trig ones), but must for the time being concede defeat at calculating them to arbitrary precision.

 

The “holy grail” of any transcendental number approximating method is, IMHO, a spigot algorithm for it, which allows calculating digits or precision – or in fact digits anywhere in the fractional expansion of a number – with a close-to-linear amount of effort. Recent astonishingly high precision estimates of numbers such as [imath]\pi[/imath] come mostly from spigot algorithms.

 

All of this approximation method discussion is, however, just preliminary to the prime generating algorithm we’re all eagerly awaiting. :) In the meanwhile, here’s a plug for a prime-generating algorithm of my own, 3313, and my own personal mathematical holy grail, 3203.

[Don Blazys]

Okay! It's on my website (donblazys.com)! If someone could post it here in LaTex, then that would be much appreciated.

 

Don

[halbower]

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]

Using exact arithmetic starting with Don’s estimated value of

 

[math]A = \frac{2566543832171388844467529}{1000000000000000000000000}[/math]

 

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

 

[math]A_n = \frac1{\frac{A_{n-1}}{\lfloor A_{n-1} \rfloor}-1}[/math]

 

to what Hal calculated using a spreadsheet:

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]

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:

 

[math]\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[/math]

 

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:

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]

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]

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]

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]

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]

Here’s a way to generate a starting value [math]A_1[/math] for Don’s generating formula

 

[math]A_n = \frac1{\frac{A_{n-1}}{\lfloor A_{n-1} \rfloor}-1}[/math]

 

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

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

Repeat steps 2 and 3 until you reach the desired [math]n[/math].

 

For example:

[math]2 \le A_1 <3[/math]

 

[math]A_2 = \frac1{\frac{A_1}{A_1 -2} -1} = \frac2{A_1 - 2}[/math]

 

[math]3 \le \frac2{A_1-2} < 4[/math]

 

[math]\frac{10}{4} < A_1 \le \frac{8}{3}[/math]

…

[math]A_{10} = \frac{-192139677A_1+493134904}{200096592A_1-513556674}[/math]

 

[math]\frac{15899835124}{6195037437} < A \le \frac{15386278450}{5994940845}[/math]

 

... etc.

 

We can chose any value for [math]A_1[/math] 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 [math]p_n[/math] using the generating formula.

 

To calculate the first 500 primes, [math]A_1= [/math]

150735014547857465033270917929625805913892065965260013354995838081281036675706516535131886363112189805088754668679404598405121140813129245153847730993931165092247526159405200033491545164257311855400825972040782136780779811983329268143206230141037016687595771322742390600315862122981380451503984941013348006847652668788987315510803820576543326377774863294319872616906040983812061918673795738599186489855274616712201322918797753182154374051901221643883084017662004776711187783279762106597356248623285865496306678022469048974107651812254311707567955376758134262077627499223084667550517509611291538649922084602380412181678762589277587938733011563903296953578742375209587436409911708233595934323619478186972886625439746358323543512860509390358963174892812656162422911198993745999692375322786844455401529845199841666718409736364597247811243052325396473422076268583872122010581309397796346550653512552762485957756100266486098172602986254978789973882570975357638984812676470789718853801244753419511495579061697513612836491589890200742469194942463622908742939936856460666907933807126046625282773007521246157872402453072926665892387658689190794389540698612524704527450013918513134098568308270445036996462945736234017908003319996992784983143664669091187042889855550457939901582834216559647707821156739686756147551693410894474070767164406309132429842346723176869332637076735529956252997967090900681776856164238961218463888662189822256436267233597158514906896824782659781043594073403139800623663367541651686138885872797450033244899419

/

58730738457846712369826340648262300633444774983907276382664707786152699714916652923222255506363237275494334029210373065724169110715321210800665911024464444770069930762507049531752637095218702389563004726718680348175236909543228267479783052324557139968722185211042114455577212162757123806991957431274048312379712629723341277003483291278684987121090006263923009800021927893526790792256690385388902826128425017866285432844953935690882637272114716855996664330689080391442436234172363357128809712568640285524188815990952547383365344367134403658887514467511763449660754212495509603849703300724470496452605975105655789135940034413587214516108465042554163865210284425592068817770897839659581296678176137062877660471494181948641759897980249486158987913446374818647330634494353063371357000253993696192631497701120322513229609206214333502935616961414719831744239424481229733511262582691148180748897999208207299660744328690074587438204488162872696499342308524534771432508459492288207789905349967177952554919214069000742288090526713502308948484450104254967930693306291594975237393982723807460588492750996826237514541777725045367304561449659050465114112640706671992471880204099592407002906644578362753893750071348805373121101080095139634333461592440688781377704280342530921967174481614225796376328207763375299513663620487384571252346365488167105920946483837885442930354015090055056827775381445045083954590638547452816838361540754188443491205015243228588194075458828428522892935170903116864785449833016379005974413756096393667894862622

 

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 [math]A_n[/math] that satisfies [math]p_n \le A_n < p_n +1[/math] will not satisfy [math]p_{n-m} \le A_n < p_{n-m} +1[/math] – it appears to for all calculations I can make in a few minutes. More importantly, we haven’t proven that the [math]A_1 = x [/math] as given by

 

[math]\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[/math]

 

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 [math]X[/math] to my big rational number above. To 500 decimals, it’s:

2.5665438321713888444675291063322857517829728287023146459697335254663997198904003462239885714780566589415300383386252694557180837585065234733899407590154521477163056174412378465009206511654428209869679944408646919502129002995825444683535957146252243194189226038317025371635511355609594950080639727211111880806309433690379118715226031469192311487269910138228161615957029092483549007751626381778170170501465893712305852748021584934680316196223087098420524922955575406332897900513351452478128278824588603694435884921287582688488499082757951311566642464820849280217151229993076859757596523704399063065354079256240471646093954799424643289145352443403354672891255594682830067586909327290064450778982781780646572326075380709000130766143755442519632323931974441018947934619264008517805956430490179231898172371368052997230780798015735735351912474123322442624555334814040204030157123671369216800571313500108714696094834011524274914368468088494367975660376792450000221102311268076302327835712866173550047160050758990823559294731332935283691934260732135205234475642016782140952781965845322346648945648788117142343108306142383815588227207565180119949919060997313844551046494747202015388384536230021753436402688469886081359485171994227626016304251316701623585280851128813381229455835114685529077513922917538380128873184842938429816881693161821371821961182096793893940762517574471742445970196513683339490300781148490252037349719426856590001962325248818060082590913466896412315136908706594026416435982690876451518198999891129443265858404.

 

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 [math]A_1[/math] 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]

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]

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. :hihi:

 

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! :eek:

 

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.

[modest]

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

 

It's just an image. It's nothing interactive. I graphed it using this website:

Graphing Calculator

 

EDIT: in case you mean you can't see them at all, I've changed the images to jpg format which any browser can view so long as "show images" is selected in your internet browser's settings. Private message me if you have continued trouble.

 

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

I believe you're correct. The site I used obviously misinterpreted that part of the function - it does look like an asymptote.

 

By the way, your LaTex rendition is almost correct, exept for the subtraction of unity at the end.

 

Fixed.

 

Here’s a way to generate a starting value [math]A_1[/math] for Don’s generating formula...

 

That is really clever thinking. I also checked it up to 500 primes successfully.

 

More importantly, we haven’t proven that the [math]A_1 = x [/math] as given by

 

[math]\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[/math]

 

Plugging your 500-digit [imath]A_1[/imath] into Don's [imath]f(x)[/imath] gives a value no closer to zero than Don's 25 digit approximation of x.

 

 

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 [math]X[/math] to my big rational number above. To 500 decimals, it’s...

 

Using an online derivative finder, I get,

[imath]f(x)[/imath] =

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

[imath]f'(x)[/imath] =

-(((-3*π^2*cos(√(x))*x^2-5*π^2*cos(√(x))*x-2*π^2*cos(√(x)))

*ln(3*x+2)+(3*π^2*cos(√(x))*x^2+5* π^2*cos(√(x))*x+2*π^2*cos(√(x)))*ln(x+1))

*ln(ln(3* x+2)-ln(x+1))^2+((-3*cos(√(x))*x^2-5*cos(√(x))*x-2*cos(√(x)))*

ln(3*x+2)+(3*cos(√(x))*x^2+5*cos(√(x) )*x+2*cos(√(x)))*ln(x+1))*ln(ln(3*x+2)

-ln(x+1))+(2*sin(√(x))^2-2*sin(√(x)))*√(x))/(√(x)*((((6*π^4*sin(√(x))^2-12*

π^4*sin(√(x))+6*π^4)*x^2+10*π^4*sin(√(x))^2-20*π^4*sin(√(x))+10*π^4)*x+4*π^4

*sin(√(x))^2-8*π^4*sin(√(x))+4*π^4)*ln(3*x+2)+((-6*π^4*sin(√(x))^2+12*π^4*

sin(√(x))-6*π^4)*x^2+-10*π^4*sin(√(x))^2+20*π^4*sin(√(x))-10*π^4)*x-*π^4*

sin(√(x))^2+8*π^4*sin(√(x))-4*π^4)*ln(x+1))*ln(ln(3*x+2)-ln(x+1))^2+(((12*

π^2*sin(√(x))^2-24*π^2*sin(√(x))+12*π^2)*x^2+(20*π^2*sin(√(x))^2-40*π^2*

sin(√(x))+20*π^2)*x+8*π^2*sin(√(x))^2-16*π^2*sin(√(x))+8*π^2)*ln(3*x+2)+

((-12*π^2*sin(√(x))^2+24*π^2*sin(√(x))-12*π^2)*x^2+(-20*π^2*sin(√(x))^2+

40*π^2*sin(√(x))-20*π^2)*x-8*π^2*sin(√(x))^2+16*π^2*sin(√(x))-8*π^2)*

ln(x+1))*ln(ln(3*x+2)-ln(x+1))+((6*sin(√(x))^2-12*sin(√(x))+6)*x^2+10*

sin(√(x))^2-20*sin(√(x))+10)*x+4*sin(√(x))^2-8*sin(√(x))+4)*ln(3*x+2)+

((-6*sin(√(x))^2+12*sin(√(x))-6)*x^2+(-10*sin(√(x))^2+20*sin(√(x))-10)*

x-4*sin(√(x))^2+8*sin(√(x))-4)*ln(x+1)))

 

Graphing [imath]f(x)[/imath] (green) and [imath]f'(x)[/imath] (red) gives:

 

 

Red does look like green's derivative to me. Unless it can be simplified algebraically I don't have much hope for Newton's method, but without any better ideas, I could give it a try.

 

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 [math]A_1[/math] 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.

 

I agree with both points.

 

~modest