Kahden ja kolmen potenssien erotus mahdollisimman pieneksi

jep, tämä on ehdottomasti oikea lähestymistapa. Rust:lla ja 38 desimaalin tarkkuudella tuohon n=72057431991 arvoon asti pääsee alle 5 minuutissa.

Hyvin hitaasti kyllä nuo ysit lisääntyy joten ei taida ratketa tälläkään tavalla:

...
n=000171928773 xxx.99999999741870669289526386837853126375
n=000397573379 xxx.99999999984730012412922500905572056625
n=006586818670 xxx.99999999998539541730156128556871836250
n=072057431991 xxx.99999999999204946618794913220018142125
n=137528045312 xxx.99999999999870351507433697883164448000
n=890638885193 xxx.99999999999887513933240971962132993875

Tässä vielä Rust-ohjelma jota käytin:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d0b404f7fc6736844ae82f8eb43e4608

malaire kirjoitti:

Hyvin hitaasti kyllä nuo ysit lisääntyy joten ei taida ratketa tälläkään tavalla:

...
n=000171928773 xxx.99999999741870669289526386837853126375
n=000397573379 xxx.99999999984730012412922500905572056625
n=006586818670 xxx.99999999998539541730156128556871836250
n=072057431991 xxx.99999999999204946618794913220018142125
n=137528045312 xxx.99999999999870351507433697883164448000
n=890638885193 xxx.99999999999887513933240971962132993875

Tässä vielä Rust-ohjelma jota käytin:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d0b404f7fc6736844ae82f8eb43e4608

Lue lisää

Jos oikein ymmärsin, niin korvaat hitaat tarkan liukuluvun ja peräkkäisten isojen konaislukujen kertolaskut nopealla kokonaislukujen (desimaaliosa) jatkuvalla summaamisella.

Virhe tietysti kasvaa koko ajan, mutta jos desimaaliosa on kokonaislukuna riittävän tarkka, se ei ehdi haitata mitään. Jos lähtee liikkeelle jostain muusta kuin 1:stä, pitää tietysti laskea vaikka tarkalla taskulaskimella sille tarkka lähtöarvo.

Pitää joskus tutkia Pythonilla, montako kertaa nopeammaksi ohjelman saa. Ei tarvitsisi käyttää hitaita gmpy2:n liukuluja. Gmpy2:n kanssa ei voi käyttää Pypyä, joten pelkästään Pypyllä nopeus lisääntyy moninkertaiseksi.

Jotta laskennan saisi todella nopeaksi, pitäsi keksiä (muodostaa) joku jaksollisuus.

Anonyymi kirjoitti:

Jos oikein ymmärsin, niin korvaat hitaat tarkan liukuluvun ja peräkkäisten isojen konaislukujen kertolaskut nopealla kokonaislukujen (desimaaliosa) jatkuvalla summaamisella.

Virhe tietysti kasvaa koko ajan, mutta jos desimaaliosa on kokonaislukuna riittävän tarkka, se ei ehdi haitata mitään. Jos lähtee liikkeelle jostain muusta kuin 1:stä, pitää tietysti laskea vaikka tarkalla taskulaskimella sille tarkka lähtöarvo.

Pitää joskus tutkia Pythonilla, montako kertaa nopeammaksi ohjelman saa. Ei tarvitsisi käyttää hitaita gmpy2:n liukuluja. Gmpy2:n kanssa ei voi käyttää Pypyä, joten pelkästään Pypyllä nopeus lisääntyy moninkertaiseksi.

Jotta laskennan saisi todella nopeaksi, pitäsi keksiä (muodostaa) joku jaksollisuus.

Lue lisää

n*lg(3)/lg(2) on sama kuin lg(3)/lg(2) lg(3)/lg(2) lg(3)/lg(2) ... joten otin vakioksi tuon lg(3)/lg(2) (ilman kokonaislukuosaa) ja sitten vaan summaan sitä, jättäen aina kokonaislukuosan pois.

Kun kokonaislukuosa pysyy pienenä (se on tässä aina joko 0 tai 1) niin lähes koko 128 bitin tarkkuus voidaan käyttää desimaaliosalle.

Tuon alkuarvon lg(3)/lg(2)-1 = 0,5849... laskin https://www.wolframalpha.com/ sivustolla että on varmasti tarkka arvo.

Viimeisessä arvossa tuossa tarkka luku olisi xxx.999999999998875139332409728...
eli ohjelman antamassa arvossa xxx.999999999998875139332409719... on vielä paljon oikeita desimaaleja ysien jälkeen.

malaire kirjoitti:

n*lg(3)/lg(2) on sama kuin lg(3)/lg(2) lg(3)/lg(2) lg(3)/lg(2) ... joten otin vakioksi tuon lg(3)/lg(2) (ilman kokonaislukuosaa) ja sitten vaan summaan sitä, jättäen aina kokonaislukuosan pois.

Kun kokonaislukuosa pysyy pienenä (se on tässä aina joko 0 tai 1) niin lähes koko 128 bitin tarkkuus voidaan käyttää desimaaliosalle.

Tuon alkuarvon lg(3)/lg(2)-1 = 0,5849... laskin https://www.wolframalpha.com/ sivustolla että on varmasti tarkka arvo.

Viimeisessä arvossa tuossa tarkka luku olisi xxx.999999999998875139332409728...
eli ohjelman antamassa arvossa xxx.999999999998875139332409719... on vielä paljon oikeita desimaaleja ysien jälkeen.

Lue lisää

Sama virhe tulee tietysti myös kertolaskua käytettäessä. Eihän se eroa mitenkään jatkuvasta summaamisesta.

Kokeilin Pypyllä. Sain lasketua alle tunnissa 100 miljardia lukua. Helppo kopsata viimeinen arvo putkelta, ja laittaa se uudeksi alkuarvoksi. Tarkalleen samat luvut tulivat kuin kertolaskutavalla. Ei nopeutunut tosin kovinkaan paljoa.Käytin hiukan vajaita vajaita 128 bitin lukuja (125 ja 126 bittiä), jottei Python tai Pypy vahingossakaan tulkitsisi lukuja yli 128 bittisiksi. Ei voi aina oikein tietää onko luvuissa etumerkkibitti mukana vai ei.

Anonyymi kirjoitti:

Sama virhe tulee tietysti myös kertolaskua käytettäessä. Eihän se eroa mitenkään jatkuvasta summaamisesta.

Kokeilin Pypyllä. Sain lasketua alle tunnissa 100 miljardia lukua. Helppo kopsata viimeinen arvo putkelta, ja laittaa se uudeksi alkuarvoksi. Tarkalleen samat luvut tulivat kuin kertolaskutavalla. Ei nopeutunut tosin kovinkaan paljoa.Käytin hiukan vajaita vajaita 128 bitin lukuja (125 ja 126 bittiä), jottei Python tai Pypy vahingossakaan tulkitsisi lukuja yli 128 bittisiksi. Ei voi aina oikein tietää onko luvuissa etumerkkibitti mukana vai ei.

Lue lisää

Kertolaskussa vaan erona on että siinä kokonaislukuosa kasvaa paljon suuremmaksi (koska sitä ei voi "nollata" kesken laskun kuten summaamisessa voi) ja siten desimaaliosalle on käytössä vähemmän bittejä kun minulla tuossa oli tasan 128 bittiä käytössä yhteensä.

Rust:ssa on muuten hyvin nopea 128-bittinen kokonaislukutyyppi (ei ole BigInt), noin tunnissa pääsin 1000 miljardiin.

malaire kirjoitti:

Kertolaskussa vaan erona on että siinä kokonaislukuosa kasvaa paljon suuremmaksi (koska sitä ei voi "nollata" kesken laskun kuten summaamisessa voi) ja siten desimaaliosalle on käytössä vähemmän bittejä kun minulla tuossa oli tasan 128 bittiä käytössä yhteensä.

Rust:ssa on muuten hyvin nopea 128-bittinen kokonaislukutyyppi (ei ole BigInt), noin tunnissa pääsin 1000 miljardiin.

Lue lisää

Pythonilla 128 bittiä ei ole mikään raja kokonaisluvuille eikä liukuluvuille. Ja esim. gmpy2:lla voi valita mielivaltaisen tarkkuuden.

Tottakai summaustapasi on parempi ja älykkäämpi myös Pythonilla. Rustin kiinteät 128 bitin muuttujat ovat paljon Pythonin lukuja nopeampia, kun ei koko ajan tarvitse tarkkailla luvun tyyppiä ja suuruutta ja vaihtaa niitä tarvittaesa lennosta.

Ei sinulla ole ihan kaikki 128 bittiä desimaaliosan käytössä. Pari kolme ylimmäistä bittiä on ylivuotoluetta. Katsoppa hiukan tarkemmin koodiasi. Ei 10- ja 2-järjestelmän luvut mene tasan. ONE vakiosi on "vain" 10**38 ja LOG:ssa on "vain" 38 numeroa.

Kokeilin 99 ja 999 alun muodostumista 4- ja 6 numeroisilla desimaaliluvuilla. Ylivuodoissa vähensin aina 10^4 tai 10^6. Ei tule aina kaikilla summattavilla luvuilla 100 tai 1000 pituisissa silmukoissa. Tulee kyllä aina, jos jatkaa summaamista pitempään. Tulos on tietysti silloin jo täysin väärin.

Anonyymi kirjoitti:

Pythonilla 128 bittiä ei ole mikään raja kokonaisluvuille eikä liukuluvuille. Ja esim. gmpy2:lla voi valita mielivaltaisen tarkkuuden.

Tottakai summaustapasi on parempi ja älykkäämpi myös Pythonilla. Rustin kiinteät 128 bitin muuttujat ovat paljon Pythonin lukuja nopeampia, kun ei koko ajan tarvitse tarkkailla luvun tyyppiä ja suuruutta ja vaihtaa niitä tarvittaesa lennosta.

Ei sinulla ole ihan kaikki 128 bittiä desimaaliosan käytössä. Pari kolme ylimmäistä bittiä on ylivuotoluetta. Katsoppa hiukan tarkemmin koodiasi. Ei 10- ja 2-järjestelmän luvut mene tasan. ONE vakiosi on "vain" 10**38 ja LOG:ssa on "vain" 38 numeroa.

Kokeilin 99 ja 999 alun muodostumista 4- ja 6 numeroisilla desimaaliluvuilla. Ylivuodoissa vähensin aina 10^4 tai 10^6. Ei tule aina kaikilla summattavilla luvuilla 100 tai 1000 pituisissa silmukoissa. Tulee kyllä aina, jos jatkaa summaamista pitempään. Tulos on tietysti silloin jo täysin väärin.

Lue lisää

> Ei sinulla ole ihan kaikki 128 bittiä desimaaliosan käytössä.

En väittänytkään noin, vaan että lähes 128 bittiä. Ja totta että yksinkertaistin hiukan kun en lähtenyt selittämään 10-järjestelmän ja 2-järjestelmän eroja kun en ollut varma minkä tasoista tietämystä tässä keskustelussa on.

Osaan kyllä tehdä tuon niin että ihan kaikki 128 bittiä ovat desimaaliosaa.

Tuo koodi antaa siis ln(3)/ln(2):n konvergentit:

1
2
3/2
8/5
19/12
65/41
84/53
485/306
1054/665
24727/15601
50508/31867
125743/79335
176251/111202
301994/190537
16785921/10590737
17087915/10781274
85137581/53715833
272500658/171928773
357638239/225644606
630138897/397573379
9809721694/6189245291
10439860591/6586818670
103768467013/65470613321
217976794617/137528045312
1193652440098/753110839881
8573543875303/5409303924479
9767196315401/6162414764360
18340740190704/11571718688839
83130157078217/52449289519716
683381996816440/431166034846567

Ei liene mikään paras, vaan siinä on ysejä eniten siihesti lasketuista luvuista.

Listassasi on hiukan pienempi 65470613321, joka tuottaa paljon nollia ja 2^m - 3^n tulee negatiiviseksi. Jostain syystä halusin lausekkeen pysyvän positiviisena. Matemaattisesti itseisarvo on tietysti parempi kriteeri.

Listasi ln(3)/ln(2):n konvergentit ovat juuri niitä mitä hainkin. Ei tarvitsekaan käydä tyhmästi läpi biljoonittain lukuja.

Pitää yrittää muokata Saga-koodisi Pytoniksi ja katsoa kuinka pitkälle pääsee. Lähes varmasti lauseketta 2^m - 3^n ei saa pienentymään lukujen kasvaessa. Jossakin äärettömän kaukana voi olla poikkeuksia, mutta niitä lienee mahdoton löytää.

Pieni Python 3 ohjelma. Ovatko 99. ja 100. luvut oikeita? Tulostin vain sen jälkimmäisen luvun. En kyllä ihan ymmärrä, miten noin pieni ohjelma voi toimia oikein?

import gmpy2
from gmpy2 import log
gmpy2.get_context().precision=500

a = log(3)/log(2)
q = [0, 1]
for n in range(0,101):
__a = 1/(a % 1)
__q = [int(a)*q[-1] q[-2]]
__print( str(n) ':', int(q[n]))

...
99: 369453385948632514681028093549461626727914417886
100: 59056372703456398495750803805975750939488054341

Nuo tulivat oikein jo 330 bitin tarkkuudella. Jos laskee pitemmälle, tarkkuutta pitää lisätä kunnes viimeiset luvut eivät muutu.

Onko noista käyttämistäsi kirjasto-ohjelmista hyötyä suorituskyvyn kannalta? Samat löytyvät jostain kyllä Pythonillekin. Ainakin tuhanten asti pystyy laskemaan paljon alle sekunnissa, ja siitäkin ajasta yli 99 % kuluu monisatanumeroisten lukujen tulostamiseen.

Anonyymi kirjoitti:

Pieni Python 3 ohjelma. Ovatko 99. ja 100. luvut oikeita? Tulostin vain sen jälkimmäisen luvun. En kyllä ihan ymmärrä, miten noin pieni ohjelma voi toimia oikein?

import gmpy2
from gmpy2 import log
gmpy2.get_context().precision=500

a = log(3)/log(2)
q = [0, 1]
for n in range(0,101):
__a = 1/(a % 1)
__q = [int(a)*q[-1] q[-2]]
__print( str(n) ':', int(q[n]))

...
99: 369453385948632514681028093549461626727914417886
100: 59056372703456398495750803805975750939488054341

Nuo tulivat oikein jo 330 bitin tarkkuudella. Jos laskee pitemmälle, tarkkuutta pitää lisätä kunnes viimeiset luvut eivät muutu.

Onko noista käyttämistäsi kirjasto-ohjelmista hyötyä suorituskyvyn kannalta? Samat löytyvät jostain kyllä Pythonillekin. Ainakin tuhanten asti pystyy laskemaan paljon alle sekunnissa, ja siitäkin ajasta yli 99 % kuluu monisatanumeroisten lukujen tulostamiseen.

Lue lisää

Samat tulee Sagella (paitsi indeksointi yhdellä jäljessä)! Suorituskyvystä en ole varma. Melko yksinkertainen algoritmihän ketjumurtoluvun laskeminen on, joten vaikeudet tullee suuren tarkkuuden käytöstä. En tiedä miten paljon "overheadiä" tuolla RealField()in käytöllä sitten on.
Itse asiassa en ollut varma toimiiko continued_fraction()-funktio ihan suoraan myös suuren tarkkuuden luvuilla mutta näyttää toimivan sillä saatiin sama vastaus.

Joo, ei sitä |2^m - 3^n|:ää saa pienentymään, jos tuohon mathoverflow:ssa olleeseen vastaukseen on uskomista. Siellähän oli että se on suurempaa kuin max(2^m, 3^n) jaettuna (e * max(n, m))^C jollekin vakiolle C. (Kommenteissa laskettu C=821013300.694... mutta että paljon pienemmänkin pitäisi jo toimia.)

Anonyymi kirjoitti:

Pieni Python 3 ohjelma. Ovatko 99. ja 100. luvut oikeita? Tulostin vain sen jälkimmäisen luvun. En kyllä ihan ymmärrä, miten noin pieni ohjelma voi toimia oikein?

import gmpy2
from gmpy2 import log
gmpy2.get_context().precision=500

a = log(3)/log(2)
q = [0, 1]
for n in range(0,101):
__a = 1/(a % 1)
__q = [int(a)*q[-1] q[-2]]
__print( str(n) ':', int(q[n]))

...
99: 369453385948632514681028093549461626727914417886
100: 59056372703456398495750803805975750939488054341

Nuo tulivat oikein jo 330 bitin tarkkuudella. Jos laskee pitemmälle, tarkkuutta pitää lisätä kunnes viimeiset luvut eivät muutu.

Onko noista käyttämistäsi kirjasto-ohjelmista hyötyä suorituskyvyn kannalta? Samat löytyvät jostain kyllä Pythonillekin. Ainakin tuhanten asti pystyy laskemaan paljon alle sekunnissa, ja siitäkin ajasta yli 99 % kuluu monisatanumeroisten lukujen tulostamiseen.

Lue lisää

Ohjelma jätti tulostamatta viimeksi lasketut arvot. Silmukka pitää alkaa 1:stä
ja tulostuksen indeksi pitää olla q[n 1]. Sadannen luvun viimeinen 1:n oli pudonnut pois tulostuksen kopionnissa. Eli:

for n in range(1,101):
__a = 1/(a % 1)
__q = [int(a)*q[-1] q[-2]]
__print( str(n) ':', q[n 1])

...
98: 369453385948632514681028093549461626727914417886
99: 590563727034563984957508038059757509394880543411
100: 1550580840017760484596044169668976645517675504708


(Python 3:ssa ei tarvita tulostuksessa ollutta int-komentoa Python 2:n tavoin gmpy2:n kokonaislukujen loppuun jostain syystä lisätyn .0:n poistamiseen.)

Anonyymi kirjoitti:

Ohjelma jätti tulostamatta viimeksi lasketut arvot. Silmukka pitää alkaa 1:stä
ja tulostuksen indeksi pitää olla q[n 1]. Sadannen luvun viimeinen 1:n oli pudonnut pois tulostuksen kopionnissa. Eli:

for n in range(1,101):
__a = 1/(a % 1)
__q = [int(a)*q[-1] q[-2]]
__print( str(n) ':', q[n 1])

...
98: 369453385948632514681028093549461626727914417886
99: 590563727034563984957508038059757509394880543411
100: 1550580840017760484596044169668976645517675504708


(Python 3:ssa ei tarvita tulostuksessa ollutta int-komentoa Python 2:n tavoin gmpy2:n kokonaislukujen loppuun jostain syystä lisätyn .0:n poistamiseen.)

Lue lisää

Jos lausekkeessa n on 99. luku, saadaan m:n desimaaliarvoon 48 peräkäkkäistä 9:iä. Pitäisi tietysti olla todella paljon enemmän, jotta lausekkeen arvo pienenisi järkeväksi.

Vasta 205. luku tuottaa 100 peräkkäistä 9:iä. Tarkistakaa:

205: 911103872450681792581904018794276516086007868645731660155183922765510884785143299405304437390578757

Anonyymi kirjoitti:

Pieni Python 3 ohjelma. Ovatko 99. ja 100. luvut oikeita? Tulostin vain sen jälkimmäisen luvun. En kyllä ihan ymmärrä, miten noin pieni ohjelma voi toimia oikein?

import gmpy2
from gmpy2 import log
gmpy2.get_context().precision=500

a = log(3)/log(2)
q = [0, 1]
for n in range(0,101):
__a = 1/(a % 1)
__q = [int(a)*q[-1] q[-2]]
__print( str(n) ':', int(q[n]))

...
99: 369453385948632514681028093549461626727914417886
100: 59056372703456398495750803805975750939488054341

Nuo tulivat oikein jo 330 bitin tarkkuudella. Jos laskee pitemmälle, tarkkuutta pitää lisätä kunnes viimeiset luvut eivät muutu.

Onko noista käyttämistäsi kirjasto-ohjelmista hyötyä suorituskyvyn kannalta? Samat löytyvät jostain kyllä Pythonillekin. Ainakin tuhanten asti pystyy laskemaan paljon alle sekunnissa, ja siitäkin ajasta yli 99 % kuluu monisatanumeroisten lukujen tulostamiseen.

Lue lisää

Jos haluaa laskea yli 100000 arvoa, ei aikaisempia arvoja ole mitään tarvetta tai järkeä säilyttää q-listassa. Tarvitaan vain kaksi viimeistä arvoa ja ne kannattaa pitää muuttujissa q0 ja q1. Lukujen määrän ja koon kasvaessa, muistin tarve kasvaa räjähdysmäisesti. Ei tietysti haittaa juuri mitään pienissä alle 100000 luvun laskuissa.


import gmpy2
from gmpy2 import log
gmpy2.get_context().precision=5000

a = log(3)/log(2)
q0,q1 = 0,1
for n in range(1,1001):
__a = 1/(a % 1)
__q0,q1 = q1,int(a)*q1 q0
__#print(str(n) ':',q1)

print(str(n-1) ':',q0)
print((q0*log(3)/log(2)) % 1)
print(str(n) ':',q1)
print((q1*log(3)/log(2)) % 1)

Jotta lauseke 2^m - 3^n menisi jollakin arvolla todella pieneksi, ysejä tai nollia pitäisi kait siinä kohtaa tulla ehkä tuplamäärä edellisiin lukuihin verrattuna. Vaikea arvioida päässälaskuna. Löytyisikö sen jälkeen enää mitään parempaa? Jonkun paremman (???) luvunhan ohjelma aina tuottaa.

Onko vaadittavalle tarkkuudelle varmasti toimivaa kaavaa? Mikä olisi log(3)/log(2):a "parempi" suhdeluku testaukseen?

Anonyymi kirjoitti:

Jos haluaa laskea yli 100000 arvoa, ei aikaisempia arvoja ole mitään tarvetta tai järkeä säilyttää q-listassa. Tarvitaan vain kaksi viimeistä arvoa ja ne kannattaa pitää muuttujissa q0 ja q1. Lukujen määrän ja koon kasvaessa, muistin tarve kasvaa räjähdysmäisesti. Ei tietysti haittaa juuri mitään pienissä alle 100000 luvun laskuissa.


import gmpy2
from gmpy2 import log
gmpy2.get_context().precision=5000

a = log(3)/log(2)
q0,q1 = 0,1
for n in range(1,1001):
__a = 1/(a % 1)
__q0,q1 = q1,int(a)*q1 q0
__#print(str(n) ':',q1)

print(str(n-1) ':',q0)
print((q0*log(3)/log(2)) % 1)
print(str(n) ':',q1)
print((q1*log(3)/log(2)) % 1)

Jotta lauseke 2^m - 3^n menisi jollakin arvolla todella pieneksi, ysejä tai nollia pitäisi kait siinä kohtaa tulla ehkä tuplamäärä edellisiin lukuihin verrattuna. Vaikea arvioida päässälaskuna. Löytyisikö sen jälkeen enää mitään parempaa? Jonkun paremman (???) luvunhan ohjelma aina tuottaa.

Onko vaadittavalle tarkkuudelle varmasti toimivaa kaavaa? Mikä olisi log(3)/log(2):a "parempi" suhdeluku testaukseen?

Lue lisää

Oletetaan :

2^m - 3^n = d

Arvioidaan hiukan d:n arvoa. Jollakin pienen pienellä positiivisella x:n desimaaliarvolla:

2^(m-x) - 3^n = 0 => 3^n = 2^(m-x)

2^m - 2^(m-x) = d
2^m(1 - 2^(-x) = d

Otetaan molemmilta puolilta 10-logaritmi:

m lg(2) lg(1 - 2^(-x)) = lg(d)

Lukuun x voidaan helposti saada miljoonia etunollia ja lausekkeen lg(1 - 2^(-x)) arvoksi itseisarvoltaan iso negatiivinen luku. Jos luvussa on miljoona etunollaa, lauseke ei kasva paljoakaan yli miljoonaksi. (Tarkistakaa jollakin vanhalla likiarvokaavalla!) Siinä vaihessa m:n arvo on kasvanut monimiljoonaiseksi luvuksi ja myös d:n arvo valtavaksi.

Vaikka laskuja tekisi triljoonan bitin tarkkuudella, ei d:n arvoa saa mitenkään pienenemään.

Anonyymi kirjoitti:

Oletetaan :

2^m - 3^n = d

Arvioidaan hiukan d:n arvoa. Jollakin pienen pienellä positiivisella x:n desimaaliarvolla:

2^(m-x) - 3^n = 0 => 3^n = 2^(m-x)

2^m - 2^(m-x) = d
2^m(1 - 2^(-x) = d

Otetaan molemmilta puolilta 10-logaritmi:

m lg(2) lg(1 - 2^(-x)) = lg(d)

Lukuun x voidaan helposti saada miljoonia etunollia ja lausekkeen lg(1 - 2^(-x)) arvoksi itseisarvoltaan iso negatiivinen luku. Jos luvussa on miljoona etunollaa, lauseke ei kasva paljoakaan yli miljoonaksi. (Tarkistakaa jollakin vanhalla likiarvokaavalla!) Siinä vaihessa m:n arvo on kasvanut monimiljoonaiseksi luvuksi ja myös d:n arvo valtavaksi.

Vaikka laskuja tekisi triljoonan bitin tarkkuudella, ei d:n arvoa saa mitenkään pienenemään.

Lue lisää

Kaavasta

m lg(2) lg(1 - 2^(-x)) = lg(d)

näkee suoraan, että jos m on miljoona ja d menisi sattumalta pieneksi, niin sen laskemiseksi tarvittaisiin n. 300000 desimaalin tarkkuutta. Vastaa yli miljoonan bitin tarkkuutta. (Onnistuisi tietysti vielä kokonaislukuina helpommin.)

Ja 2 ja 3 korvataan alkuperäisessä lausekkeessa joillakin hiukan isommilla luvuilla x ja y), joilla ei ole yhtään yhteistä tekijää (esim. 3 ja 4 tai 4 ja 5 tai 5 ja 6), tilanne vain pahentuu.

Ihan tilastollisestikin voi päätellä, ettei kokonaislukulausekkeen x^m - y^n arvoa saa millään pieneksi isoilla n:n arvoilla. Todennäköisyys on luokkaa n/y^n. Eli mitättömän pieni. Ei tietysti todista mitään!

Joissakin vastausten linkeissä tulee vastaan myös Collatz conjecture. Eli asiaa on pohdittu paljon. Matemaatikoilla riittää töitä ikuisesti.

Ymmärtääkö joku Li Jiang:n Collatzin konjektuurin todistuksen eli kaikki luvut päätyvät ykköseen.

https://www.researchgate.net/publication/343287191_The_Collatz_Conjecture_and_Linear_Indefinite_Equation

Ei näyttäisi ihan aukottomalta. Jos ihan suhteellisen yksinkertaiseen peruskaavaan pohjautuvaa todistusta ei kukaan matemaatikko ymmärrä, niin jossakin on jotain vikaa. Luulisi Li Jiangilla olleen riittävästi aikaa kirjoittaa todistus selkeämpään muotoon. On saanut varmasti kyselyjä ja kommentteja.