Pi is berekend tot record van 62,8 biljoen decimalen met twee EPYC-cpu's

Een team van de Zwitserse Fachhochschule Graubünden heeft pi berekend tot een recordaantal cijfers achter de komma. Met twee AMD EPYC 7542-cpu's kwamen de studenten en onderzoekers na 108 dagen tot 62,8 biljoen decimalen.

De Zwitserse hogeschool gebruikte een systeem met twee AMD EPYC 7542-cpu's, die per stuk over 32 cores en 64 threads beschikken. Het berekenen van pi tot ver achter de komma vereist vooral veel geheugen; het gebruikte systeem was voorzien van 1TB ram en 510TB aan hdd's, die grotendeels ingezet werden als swapgeheugen. De configuratie bestond uit 38 hdd's in JBOD met een capaciteit van 16TB per stuk en een toerental van 7200rpm. Daarvan werden er 34 gebruikt als swapgeheugen en 4 voor de opslag van pi.

Het team gebruikte y-cruncher van ontwikkelaar Alexander Yee voor het berekenen van pi. Dat programma kan overweg met eigenschappen van moderne processors en is ook voor eerdere wereldrecordpogingen gebruikt. De Zwitsers gebruikten Ubuntu 20.04 en maakten diverse aanpassingen om de berekening van pi te versnellen. Zo werden beveiligingsfuncties en stroombesparingsfuncties uitgeschakeld.

Het doel van de onderzoekers en studenten van de Zwitserse hogeschool was om te laten zien dat ze met een beperkt budget, relatief eenvoudige hardware en een klein team het irrationale getal pi kunnen berekenen tot een recordaantal decimalen. Na 108 dagen en 9 uur kwam het team tot 62,8 biljoen cijfers achter de komma. Dat is 12,8 biljoen meer dan het vorige record.

Pi-berekening door Fachhochschule GraubündenPi-berekening door Fachhochschule GraubündenPi-berekening door Fachhochschule Graubünden

Afbeeldingen: Fachhochschule Graubünden

Naar eigen zeggen was de berekening van de Zwitserse hogeschool bijna twee keer zo snel als die van Google in 2019 en zo'n 3,5 keer sneller dan het laatst geregistreerde wereldrecord uit 2020. De onderzoekers zijn in afwachting van een bevestiging van het Guinness Book of Records. Als die binnen is, publiceren ze het volledige getal. Vooralsnog geven ze alleen de laatste tien cijfers van de uitkomst: 7817924264.

In het Guinness Book of Records staat de meest nauwkeurige berekening van pi momenteel nog op naam van de Amerikaan Timothy Mullican. Hij kwam begin 2020 na acht maanden tot 50 biljoen cijfers achter de komma. Hij gebruikte daarvoor een server met vier Intel Xeon E7-4880v2-cpu's, met 15 cores en 30 threads per stuk. Mullican verbrak met zijn poging het record van Google, dat in 2019 werd gevestigd door een medewerker van Google Cloud. Emma Haruka Iwao rekende op de datacenterhardware van Google pi uit tot 31,4 biljoen cijfers achter de komma. Daarvoor werd een instance met 96 Intel Skylake-cores gebruikt.

Fachhochschule Graubünden
Fachhochschule Graubünden vs. Google vs. Mullican

Door Julian Huijbregts

Nieuwsredacteur

17-08-2021 • 09:55

154

Reacties (154)

154
152
64
9
0
49
Wijzig sortering
Anoniem: 532949 17 augustus 2021 10:01
Hoe test je de precisie van dit nummer? met andere woorden, hoe bewijs je dat je daadwerkelijk het getal pi hebt to 68 miljard decimalen?
Behalve dit algoritme, zijn er ook andere algoritmen die je ter controle kunt gebruiken. Bovendien zijn er algoritmen die de n-de decimaal kunnen bepalen zonder dat je eerst alle voorafgaande decimalen hoeft te berekenen. Dat is handig als je wilt controleren of het miljoenste getal na de komma klopt.
Toch vraag ik me af of het echt nodig is... als we het er over eens zijn dat het gebruikte programma de juiste berekeningen uitvoert om tot een oneindig aantal getallen achter de comma Pi te berekenen is het dan echt nodig om de uitkomst van dat programma te controleren?
Dat voelt een beetje als zeggen ja leuk hoor die discrete logica en zo maar toch vertrouwen we het niet helemaal en willen we toch die berekening die de computer net gedaan heeft voor het lanceren van deze satelliet even met een andere berekening controleren omdat we na al die jaren nog steeds niet geloven dat een computer altijd de formule geheel juist toepast of zo.

Natuurlijk wil je fraude uitsluiten en zul je heus wel willekeurige cijfers controleren maar ik neem aan dat als je kunt bewijzen dat de laatste paar honderdduizend en een paar miljoen willekeurig gekozen andere getallen allemaal correct zijn dat je voldoende zekerheid hebt om te kunnen stellen dat het getal juist is berekend. Ik kan me niet voorstellen dat je nu die hele cijferbrij gaat controleren voor het geval dat er iets fout is gegeaan.
Natuurlijk kun je zeggen dat de uitkomst moet kloppen als je zeker weet dat het algorithme goed werkt. Er zijn echter nog wat andere schakels die roet in het eten kunnen gooien. Helaas zitten er bugs in processoren (de Pentium div bug is waarschijnlijk de bekendste, maar er zijn veel meer hardware fouten in cpu's). Ook in compilers zitten fouten, waardoor het gecompileerde programma.niet exact doet wat de broncode voorschrijft. Compilers zijn immers ook 'maar' software en in software zitten, zoals we weten, bugs. Je kunt je zelfs afvragen waarom compilers zo'n betrouwbare programma's zijn.

Kortom. Dit resultaat is verkregen via een van de mogelijke combinaties van hardware, compilers, programmeertaal, algorithme (etc). Het zou kunnen zijn dat de gekozen combinatie 100% betrouwbaar is, maar dat kun je pas aantonen als andere combinaties hetzelfde resultaat geven.

Edit: typo

[Reactie gewijzigd door slowdive op 22 juli 2024 15:06]

"... en in software zitten, zoals we weten, bugs. "
Je brengt dit met een stelligheid alsof het een natuurwet is, maar software kan ook gewoon foutloos zijn, ook complexe software.
Er is geen reden waarom een compiler niet foutvrij zou kunnen zijn. Ik weet overigens niet hoe compilers getest worden, misschien zijn er wel foutloze testen die foutloze compilers opleveren ...
Zelf toevallig gisteren dit filmpje gezien hierover, de historie van pi: https://youtu.be/gMlf1ELvRzc

In het kort: Ipv de daadwerkelijke cirkel te meten maak je een bijv. een 6-hoek aan de binnenkant van deze cirkel en een vierkant er om heen. Als je de straal/diameter van deze 6-hoek en vierkant weet kan je uitrekenen wat pi is d.m.v. het verschil in afstand tussen 3 van de zijden van de 6-hoek en 2 zijden van het vierkant. Het filmpje illustreert het heel duidelijk, mijn uitleg waarschijnlijk wat minder :+
Goeie video inderdaad. Maar is het hele idee van de video niet dat de manier die jij noemt de oude aanpak is?

Ludolph van Ceulen (https://nl.wikipedia.org/wiki/Ludolph_van_Ceulen) is 25 jaar van z'n leven bezig geweest met het berekenen van PI op de 'oude' manier. En toen kwam Newton met een manier waarop het veel sneller kon.
Die manier werkt nog steeds, je hebt alleen een betere liniaal nodig.
De video net gezien, en doet de volledige uitleg, van Archimedes over van Ceulen tot Newton. Net een serieus "ah nu snap ik het eindelijk"-moment gehad :D
Je in het kort uitleg klopt niet, dat is de oude manier van berekenen, nieuwe manier is vanaf 10 minuten te zien.
Er staat biljoen.
Dat is een factor 1000 meer.
Ik neem aan Nederlands biljoen en niet Amerikaanse.
Uitgaande van 1 byte per karakter, is het:

62.8 * 10^12 / 1024^4 = 57.1 TeraByte
Beetje raar om een getal als string op te slaan? Je kan dit getal prima met een paar honderd bits beschrijven.

Klopt wat AndrewF zegt onder mij, was even niet aan het opletten, goede beschrijving hieronder @AndrewF Ik ga er zeker vanuit dat ze het als integer hebben opgeslagen en niet als string.

[Reactie gewijzigd door nitrane op 22 juli 2024 15:06]

Alle 62,8 biljoen digits met een paar honderd bits? echt?
Ik hoop dat je geen floats bedoeld want zijn al na een 10-tal cijfers na de komma inaccuraat.

Volgens mij is log2(10^68biljoen) meer dan een paar honderd 🤔

Update: als je het als binaire integer zou willen opslaan heb je log2(10^62831853071796) = 2.08 * 10^14. Oftewel 10^14 bits nodig. Dat zou ongeveer 23TB zijn. Wat iets meer is dan een paar honderd bits 😅 [wolfram alpha]

[Reactie gewijzigd door AndrewF op 22 juli 2024 15:06]

Je bedoelt tebibyte.
We hebben het hier over opslag op HDD, en de HDD schijven worden ook alleemaal in duizendtallen verkocht. Ik ben het dus eens dat dit hierboven tebibyte genoemd dient te worden, maar de vraag is waarom je sowieso de binaire notatie nodig hebt. Dus de correctie van Nimja is overbodig.
Nederlandse biljoen inderdaad, Duits eigenlijk :P

ik controleer dit ook altijd in bronartikelen omdat het vaak mis gaat met vertalen van billion naar miljard inderdaad
Het is geen vertaalprobleem. Of ten minste: het is niet dat 1.000.000.000 in het Engels altijd "billion" en nooit "milliard" heet. Al gebruiken zowel de VS als het VK, en daarmee effectief toch een enorm deel van het Engels taalgebied, eigenlijk alleen nog maar de korte schaal (o.a. 109 = billion) Het is meer regionaal bepaald en een aardige lappendeken daarbij.

[Reactie gewijzigd door Bacchus op 22 juli 2024 15:06]

De vertaling is geen probleem , het vertalen dat door mensen verkeerd gedaan wordt is het probleem.

Patato / Patato ;)
Ai, tnx. Ik fix het..
En eigenlijk vind ik de 'Engelse' variant fijner. Million, Billion (Bi=2), Trillion(Tri=3), Quadrillion (Quad=4). Vind ik zelf fijner te onthouden dan miljoen, miljard, biljoen ,biljard. Al is die ook compleet logisch natuurlijk. :+

Hier overigens een completere lijst t/m sextillion(triljard): https://www.languagelab.n...b/billion-is-geen-biljoen

[Reactie gewijzigd door MN-Power op 22 juli 2024 15:06]

Wat is standaardisatie toch mooi...
Ik zou met beide varianten kunnen leven, als wij onze biljoen en biljard l nu eens zouden inleveren en de Amerikanen hun inches en gallons zou de wereld toch weer een stukje mooier worden...
Anoniem: 532949 @bartje17 augustus 2021 19:25
My bad, ben (helaas) zo gewend geraakt aan de Amerikaanse biljoen.
Je bewijst dat het algoritme dat je draait daadwerkelijk een generator is van de decimalen van pi.
Dat je bewijst dat het algoritme daadwerkelijk een generator is voor pi lijkt me noodzakelijk voordat je z'n experiment start. Echter lijkt me dat de kans aanwezig is dat ondanks een perfect algoritme je toch niet goed uitkomt. Ze werken namelijk met gigantisch veel data, alleen al 4*16TB aan opslag. Hoe groot is dat er onderweg een paar bit zijn geflipt? of een stuk geheugen 2 x is beschreven etc.
Dat staat op hun website. Ze hebben gebruik gemaakt van de Bellard's formule (https://en.wikipedia.org/wiki/Bellard%27s_formula)

Dit is een formule die een willekeurig getal in PI kan berekenen (bijvoorbeeld het 1024e decimaal) zonder alle voorgaande getallen te berekenen.
Gezien het een vaste formule is vraag ik me af of het mogelijk zou zijn hier dedicated hardware voor te maken en wat het zou schelen in vergelijking met de general purpose CPU's die ze nu gebruiken.
Natuurlijk kun je dat met dedicated hardware oplossen maar zo als gezegd je hebt nog al wat storage nodig, als het even kan RAM maar als je over honderden TB's praat (hun swap size) kan ik me zo voorstellen dat je dat met disks doet en dat zelfs SSD's te duur worden voor de meeste clubs met zo'n hobby.

En dat is denk ik waar de schoen wringt zelfs als ik dedicated hardware zou gebruiken dan nog kom ik al snel op een punt waarbij storage mijn bottleneck is als dat nu al niet het geval was. Je kunt de berekeningen nog zo snel maken als je de data niet sneller aan kunt leveren of weg kunt schrijven dan heeft het geen zin om de berekeningen nog verder te versnellen.

Ook ging het deze club het er om te bewijzen dat je met een bescheiden budget toch dit soort record pogingen kan ondernemen. Even wat dedicated hardware bouwen gaat al snel flink in de papieren lopen helemaal als die hardware honderden TB's aan ultra snel geheugen moet kunnen adresseren om de berekeningen mogelijk te maken.
Daar naast vraag ik me heel erg af wat het praktisch nut is van zo'n onzinnig groot getal, en daar mee wat de waarde zou zijn om dit heel erg veel sneller te kunnen berekenen. Als er geen economische waarde achter zit maar het meer een kwestie is van leuke school projectjes en een uit de hand gelopen hobby van een relatief hoog geplaatste persoon binnen Google (je moet het budget er maar voor vrij kunnen maken) dan denk ik niet dat het de moeite waard is om er nog heel erg veel meer geld tegen aan te gooien en dus dedicated hardware hier voor te maken.
Dank u, was me niet bewust dat z'n formule bestond!
Het is trouwens wonderbaarlijk dat er in een non stop berekening van 108 dagen, die ook nog eens enorm veel geheugen gebruikt. Er geen fout is in geslopen! Wat gebeurt er als er een paar bits waren geflipt. Dan was de hele berekening waarschijnlijk in accuraat geworden.

[Reactie gewijzigd door Anoniem: 532949 op 22 juli 2024 15:06]

Er zijn reeksen en series die je ver genoeg door kan rekenen, die pi benaderen, en bij genoeg iteraties vanzelf nauwkeurig worden. Die kun je doorrekenen.

Als simpel voorbeeld:

4 * (1 - 1/3 + 1/5 -1/7 + 1/9 - 1/11... etc ) = pi

Maar hier staan er veel meer. Vooral die laatste van Ramanujan is bekend onder number nerds.

Het is typish dat we bij genialiteit automatisch denken aan Einstein en Tesla, maar zelden aan Ramanujan.
Ramanujan is nochtans redelijk gekend bij STEM studenten, het bredere publiek iets minder, Maar ik vermoed dat Tesla ook niet gekend is (behalve de wagens).
Ik vraag me af wat het nut hiervan nou is om dit zover te weten. 3.14159265359 lijkt mij al ver genoeg, laat staan 62,8 biljoen decimalen.
Het gaat niet zozeer om het nut van het weten van de getallenreeks, maar meer om een proof of concept van de manier waarop ze het gedaan hebben. Dat kan dan mogelijk weer op een nuttige manier toegepast worden bij andere problemen die zware rekenkracht en grote hoeveelheden aan opslag vereisen. Zoals misschien eiwitten vouwen of zo.
Maar dan denk ik dan weer: Had dan eiwitten gevouwen. Is ook niet iets nieuws en een heel stuk potentieel zinvoller.

Ik vraag me om eerlijk te zijn ook af hoeveel stroom in kWh dit heeft gekost. Het zal in de praktijk wel loslopen met twee CPUs, maar op zich zou het een leuk wistjedatje zijn.
Omdat het ook fout kan gaan, bijvoorbeeld door data corruptie?

Musk stuurt ook een Tesla en een Franse kaas de ruimte in. Ik weet niet hoeveel energie de komende starship launch per plakje kaas gebruikt maar....
De vraag is of dit echt betrekking heeft op eiwit vouwen en of de opgedane kennis hier ook maar iets in gaat helpen al is het maar omdat als je het zo leest men simpel weg een hele grote swap file heeft gemaakt, een flinke storage disk waarschijnlijk booten van af een SSD of wat er dan ook in de server zat als boot disk en dan het programma er op los laten. Ik vind het moeilijk om daar echt iets in te zien dat zeer nuttig is voor welke andere tak van sport dan ook. Het is een hele simpele truck om veel "geheugen" na te bootsen en dus de berekeningen redelijk efficient uit te voeren.

Er is geen algoritme uitgevonden nog heeft men meer dan 1 systeem gebruikt, en het aanmaken van een swap partitie (van welke grote dan ook) is niet iets wat de wereld nog niet kon.

Ik denk eerder dat zo als beschreven dit simpel weg een leuke manier was om de naam van het instituut in de pers te krijgen met minimale kosten en zeer weinig werk.
Miss heb je wel gelijk. Aan de andere kant, als het enige wat ze bereikt hebben een heel leerzame ervaring was voor de studenten uit het team (team van een Hogeschool, dus zou zo maar een afstudeerproject of iets dergelijks kunnen zijn) is het al geen "zinloos" project geweest.

Hoe dan ook, het punt dat ik wilde maken was dat ook al lijkt een project niet direct zinnig, er vaak wel weer iets uitgehaald kan worden dat toch zinvol is/blijkt.
Als het geen men geleerd heeft een paar kleine aanpassingen maken op een enkele server en vervolgens het ding een schop geven en een paar maanden wachten op een resultaat dan is het toch wel echt het meest dood eenvoudige afstudeer project waar ik ooit van gehoord heb.

Anders dan het bewijs leveren dat je echt geen Google hoeft te zijn en met moderne hardware een heel eind kunt komen om zo iets te bereiken heeft het voor zo ver ik uit het verhaal op kan maken helemaal niets opgeleverd. Media aandacht en een leuk verkoop praatje voor het komende studie jaar (misschien langer als niemand anders hun systeem van wat meer storage voorziet)
Met zo'n 38-39 cijfers achter de komma kunnen we de omtrek van het zichtbaar heelal berekenen met een nauwkeurigheid van de diameter van een waterstofatoom. :)

https://www.jpl.nasa.gov/...-of-pi-do-we-really-need/
Omdat het kan. :Y)

Hoe rond wil je een cirkel kunnen tekenen/berekenen? Kan me voorstellen dat het in de takken van sport zoals de ruimtevaart of wetenschap wel fijn is om behoorlijk precisie te hebben. Maar dit is natuurlijk altijd overkill.
Dat dacht ik ook altijd, maar NASA gebruikt 15 decimalen...
En toch...als de afstanden werkelijk groot worden in de toekomst, hoe belangrijk zou mogelijk meer decimalen dan 15 worden voor een goede berekening van "een reis"?
Zoals in het artikel van @latka staat:
How many digits of pi would we need to calculate the circumference of a circle with a radius of 46 billion light years to an accuracy equal to the diameter of a hydrogen atom (the simplest atom)? The answer is that you would need 39 or 40 decimal places.
Zo'n 39 a 40 is voldoende:
How many digits of pi would we need to calculate the circumference of a circle with a radius of 46 billion light years to an accuracy equal to the diameter of a hydrogen atom (the simplest atom)? The answer is that you would need 39 or 40 decimal places.
Ongeacht over wat voor afstanden het gaat kun je je afvragen of de fout die ontstaat door een x aantal decimalen van Pi relevant is.

Het verschil tussen 15 of 16 decimalen gebruiken is 0.0000000000000002, wat ongeveer 6*10^-15 % van Pi is. Op een afstand van 1 lichtjaar is dit een verschil van 60 cm, hoe relevant is 60cm meer of minder ten opzichte van 9.460.730.472.580 kilometer?
15 decimalen is genoeg.

Ja, ook voor een verre reis. De onzekerheid door andere factoren domineert al heel veel eerder je traject. Je precieze moment van lancering is ook niet met 15 cijfers nauwkeurig bekend. De aarde draait tenslotte in 24 uur om z'n as, dus je weet om dezelfde reden niet precies in welke richting je vertrekt.

Je lost dit op door koerscorrecties - bijsturen op basis van voortschrijdende metingen. En dan kom je erg ver met 6 cijders.

Die 6 en 15 cijfers zijn niet helemaal random gekozen: dat zijn de decimalen die je krijgt met 32 en 64 bits floating-point. 128 bits floating point is vooral theoretisch; er zijn eigenlijk geen engineering problemen waar het nodig is. En in theoretische problemen zijn er eigenlijk ook geen bijzondere grenzen waardoor 64 bits te weinig is maar 128 bit wel voldoende.
Er zijn maar 62 decimalen nodig om de omvang van het huidige bekende heelal met een nauwkeurigheid van minder dan een Planck lengte te berekenen, dus ja, de rest is overkill, maar gewoon omdat het kan...

Quote:
The magnitude of such precision (152 decimal places) can be put into context by the fact that the circumference of the largest known object, the observable universe, can be calculated from its diameter (93 billion light-years) to a precision of less than one Planck length (at 1.6162×10−35 meters, the shortest unit of length that has real meaning) using π expressed to just 62 decimal places.[29]
Hooguit als je met heel veel complexe zeer grote getallen aan het rekenen gaat, en het antwoord invoer is voor de volgende berekening kunnen veel decimalen uiteindelijk uitmaken.

Of je redelijkerwijs een praktisch nut zou kunnen hebben voor meer dan 100 decimalen lijkt mij ook zeer onwaarschijnlijk.

Dus je zou kunnen stellen dat meer dan bijvoorbeeld 500 decimalen zwaar overkill is.
Wat een benadering is, 3.14159265358 zijn de juiste decimalen, gevolgd door 979.
Dus met de notitie die je nu neerzet heb je al een afrondfout.

Het staat me bij dat je zo'n 40 decimalen nodig hebt om de omtrek van het universum tot een halve atoom accuraat te berekenen. De vraag is dan alleen: is dat precies genoeg?

Mijn mening is dat dergelijke mega-projecten voornamelijk als hobby of proof of concept dienen.
Je kan er zelf vrijwel niks nuttigs mee, maar door de technieken/technologie die ze erbij ontwikkelen gaan we als mensheid toch weer een stapje vooruit in ons kunnen, wat iemand anders weer kan gebruiken voor het volgende doel, waarvan we het nut wel direct in kunnen zien.
Maar hier is niets nieuws ontwikkeld. Er is een oude techniek gebruikt met een redelijk snelle computer, en toen hebben ze een tijd lang gewacht. Dit levert geen nieuwe ontdekkingen op.
De afronding was gewoon goed hoor. De laatste 2 getallen van mij waren 59. Nu zet jij er een extra getal bij en wordt het dus 589. Maar jouw 9 rond af naar boven dus is is mijn 59 goed afgerond.
Ik bedoel te zeggen dat je überhaubt afrond. Je geeft ongeveer de waarde van Pi weer, maar je geeft niet de daadwerkelijke decimalen weer.
In dezelfde zin kan je claimen dat Pi ongeveer gelijk is aan 3.142, wat vrij nutteloos is in een thread over de decimalen van Pi.
Het nut is educatie en motivatie van studenten. Je engineering studententijd is nu net de tijd dat je meer bezig kan zijn met de uitvoering dan het doel/resultaat. Je hoeft niet aan te tonen dat je kosten effectief een nuttig resultaat hebt, je moet aantonen dat je iets geleerd hebt. Dat hebben de studenten denk ik wel. Het wereldrecord was daar leuke motivatie bij. Misschien heb je juist door dit een project een paar studenten die doorgaan in dit veld en met betere techniek voor eiwitten vouwen gaan komen :)
Ik vraag me bij dit soort dingen altijd af waarom er bij een bepaalde hoeveelheid decimalen wordt gestopt. Is dan het geheugen vol oid, of wordt er gewoon gezegd "jongens, we kappen er mee, het is goed geweest"?
Ze hadden gewoon niet meer ruimte om meer decimalen op disk te saven.
Opslagruimte: 4x 16 TB = 64 TB. Trek er wat filesystem overhead van af en je komt rond de 62 biljoen cijfers uit als je 1 byte per cijfer gebruikt.
(De andere schijven waren nodig als werkruimte voor de berekening zelf. Werden niet gebruikt voor de eigenlijk opslag van het eindresultaat.)
Hoe kun je 64TB nodig hebben voor een 32 trillion (=biljoen) getal?

Als je het getal in zn geheel opslaat heb je ~45 bits nodig

Als je elk decimaal los opslaat heb je veel meer nodig, hoezo zou je elk los decimaal als een byte van 8 bits opslaan, elk decimaal zit tussen 0-9 dus een 4 bits zou genoeg zijn

[Reactie gewijzigd door maykoga op 22 juli 2024 15:06]

Het is floating point. Geen integers, dus 45 bits is een beetje kort door de bocht.

D'r bestaan gewoonweg geen standaard math libraries die met dit soort krankzinnig grote getallen kunnen omgaan.
En het algorythme is zwaar parallel en genereerd per thread verschillende stukken van de output die in de correcte volgorde aan elkaar geplakt moeten worden.
Je zou daarvoor een compleet nieuw binair math systeem voor moeten ontwikkelen.

Botweg wegschrijven als ascii characters is veruit het simpelste en maakt verder verwerken van de cijfers makkelijker omdat je dan de output gewoon als tekst-files kunt behandelen en daarvoor kun je gebruik maken van legio kant en klare Linux tools.

Wegschrijven als BCD (1 decimaal per nibble) is uiteraard 2x zo efficient, maar vereist conversies van en naar BCD en je kunt dan NIET gebruik maken van al die handige tekst manipulatie tools.
Het is floating point.
Ik mag toch hopen van niet...

[Reactie gewijzigd door ZinloosGeweldig op 22 juli 2024 15:06]

Wegschrijven als BCD (1 decimaal per nibble) is uiteraard 2x zo efficient, maar vereist conversies van en naar BCD en je kunt dan NIET gebruik maken van al die handige tekst manipulatie tools.
Tenzij je een handige tool mee levert om van een willekeurige positie tot een willekeurige positie van BCD naar ASCII te dumpen. Zo'n tool lijkt me dood eenvoudig om te maken. Ik zou gewoon de 3. weg laten uit mijn opslag en een special stukje code gebruiken als men van positie 1 tot x of 2 tot x wil hebben. De rest van het getal sla je op in BCD en als iemand 15 tot 21 wil hebben dan lees je van af byte (even door 2 delen en de integer gebruiken, onhouden om het eerste getal de vergeten) tot byte (even door 2 delen en naar boven afronden). Alle andere opties zijn niets anders dan dit verhaal de tool kan in een paar regels in welke taal dan ook geschreven worden, het enige waar je echt op moet letten is dat je een stream leest en weg schrijft en niet probeert alle opgevraagde ditgits eerst in je geheugen op te slaan.

Als iemand de hele file wil hebben dan is dat geen probleem duurt vast even een paar TB lezen en weer schrijven is niet binnen een seconde gedaan maar het duurt ook niet zo heel erg lang omdat de berekening relatief simpel is heel weinig geheugen vraagt etc... de beperking (mits goed geschreven) zal zijn hoe snel je de data kunt weg schrijven en als dat snel genoeg kan hoe snel je de data kunt lezen als is dat altijd twee keer minder data dan wat je weg schrijft.
Het getal heeft 32 triljoen cijfers. Door zul je bij opslag in een .txt file 32 triljoen bytes voor nodig hebben. Het kan efficiënter met 3,x bit per cijfer, of misschien makkelijker met 4 bit per cijfer. Dan zouden het 16 triljoen bytes zijn.
Het getal is idd veel langer dan het getal 32 trillion zelf is, enorm veel langer.

Dus met 4bits per decimaal is het getal pi met 32trillion decimalen dus 16TB aan data, dat is idd flink meer dan ik eerst dacht

https://www3.wolframalpha...PStoreType=image/gif&s=11

[Reactie gewijzigd door maykoga op 22 juli 2024 15:06]

Om te beginnen, laten we zorgvuldig zijn en het over biljoenen hebben, niet trillions en zekere geen triljoenen. Daarnaast gaat het om 62,8 biljoen, en tot slot gaat het om het aantal decimalen, niet het getal zelf: 10 schrijf je met 2 cijfers, 1 miljard met 10 (1.000.000.000) snapt u?

Wat betreft hoeveel bits of bytes je nodig hebt om een cijfer op te slaan, dat ligt natuurlijk compleet aan de gebruikte codering, in ASCII gebruik je 1 byte per karakter.
We hebben het juist wel over "trillions", 1 biljoen in het Nederlands, of Duits, is een trillion in het Engels/Amerikaans.

Om het bestand, of de betanden, zo makkelijk mogelijk leesbaar te houden verwacht ik dat ze ASCII, of een andere simpele codering aangehouden.
Trillion ja, triljoen werd echter genoemd en dat is toch wat anders (net als dat je billion en biljoen niet moet verwarren).
Ik bedoel dus idd de NL terminologie gebruiken als je Nederlands schrijft, dan niet ineens "trillions" zeggen/schrijven, dat is inconsequent en leidt tot verwarring met biljoen.

Wat betreft ASCII, dat is ook wat ik zeg, standaard gebruiken we dus 8 bits/1 byte per karakter, ook al zou je theoretisch maar met 4 bits toe kunnen.
Je hebt het over een getal met ongeveer 62.800.000.000.000 cijffers achter de komma (!!).
Als je dat getal in bits wilt uitdrukken moet je weten dat je ongeveer 3.3 bits nodig hebt per cijfer van 0-9.
Dus om dit getal in bits uit te drukken heb je 62800000000000 x 3.3 bits nodig.
Dat gaat niet passen in de 45 bits die jij voorstelt.
Wat ik me dan weer afvraag is of ze dan ook compressie gebruiken?
Je zou volgens mij toch makkelijk kunnen zeggen dat elke 50mb aan ASCII een file dump gedaan word met
een compressie van 11:1 of wellicht wel meer aangezien het alleen maar over 0123456789 gaat.

Dan zou er een stuk meer data op die schijf passen toch?
Proton_ Moderator Wonen & Mobiliteit @dutchruler18 augustus 2021 09:38
Door de onvoorspelbaarheid van de data (het is een irrationaal getal zonder herhaling) is het per definitie niet comprimeerbaar.
Een zipje van het resultaat is dus groter dan de ruwe data :)
Random binaire waarden kun je niet comprimeren. Daar zit geen redundantie in. Met de ASCII- en BCD-representatie lukt dat wel, maar dat wordt niet kleiner dan de binaire versie.
Hier ben ik ook benieuwd naar, ik kan me voorstellen dat er een crash kan zijn, of de software / hardware ergens een limiet raakt
Kan me weinig voorstellen bij zo'n getal. Ook al is het geen SI eenheid, ik vraag me af hoeveel A4-tjes dit is. :+ :+
Op 1 A4tje (Calibri, gewone marges) gaan ongeveer 3478 getallen. Dubbelzijdig dus 6956 getallen. 62.831.853.071.796 tekens (plus twee voor de 3 en de komma) zou betekenen dat je 9.032.756.335 A4tjes nodig hebt. Voor iedere inwoner op de wereld dus iets meer dan 1. Met een dikte van 0,11 mm per A4tje, zou deze stapel een hoogte hebben van 993,6 km, meer dan twee keer de hoogte van het ISS.

Ter vergelijking: dit getal is nog niet heel groot. Het grootst bekende priemgetal (2^82,589,933 − 1) zorgt voor een stapel van 2.3545×10^24862036 km.

[Reactie gewijzigd door tristandb op 22 juli 2024 15:06]

Kijk, hier kan ik wat mee. :)
Numberphile heeft daar een leuk filmpje over:
A million digits of Pi on one piece of paper (1,05 miles)
https://youtu.be/0r3cEKZiLmg
En met de nieuwe berekening hebben dus 68 miljoen miljoen digits, dat zou dan ongeveer 68 miljoen mijl (meer dan 108 miljoen km) zijn.
dat hangt af van de puntgrootte van je lettertype.

Vroegah, heel lang geleden... tijd matrix printers ... beetje het standaard lettertype was ongeveer 1KB (1024 bytes) +/- gelijk aan 1 A4...nu mag jij weer rekenen (maar het komt neer op een paar bossen hout)

[Reactie gewijzigd door Drumar op 22 juli 2024 15:06]

enkelzijdig of dubbelzijdig?
Wat ik bijzonder vind is dat je met twee "betaalbare" CPUs, een relatief korte tijd en standaard software het wereldrecord kan verbreken.

Ik had eigenlijk verwacht dat er wel een Distributed computing effort zou zijn om de decimalen van Pi te berekenen. Is er wellicht een technische / wiskundige reden waarom dat er blijkbaar niet is? Of gewoon geen interesse / praktisch nut?
De CPU's zijn niet het doorslaggevende, dat is de 1TB RAM en 510TB aan harde schijven, en dat is alles behalve betaalbaar.
De CPU draagt wel heel erg bij. Het vorige record had 8 maanden nodig om de berekening te doen (pi tot 50bjn getallen) gebruikmakend van een hele bak vol Xeon CPUs . Dit nieuwe record had maar 108 dagen nodig om op 64bjn getallen te komen. Dat is pure rekenkracht van de CPU + mogelijkheid tot supersnel wegschrijven. Prijskaartje van zowel de Epyc als de gebruikte Xeons bij vorige record zal relatief hetzelfde zijn, het laat wel zien dat AMD de ontwikkeling op CPU gebied in de afgelopen 2-5 jaar totaal op zijn kop heeft gezet.
Het wereldrecord is alleen op basis van hoeveel decimalen je hebt berekend. Niet hoe snel dat gaat. De beperkende factor hierin is de opslag, niet de rekenkracht.
Het zou mooi zijn als straks ook de snelheid gaat meespelen in het record.
Toch heeft dit nieuwe record het ook sneller gedaan
Hoe kan een organisatie als "Guinness Book of Records" zonder enig kennis van zaken dit bevestigen nog ontkrachten?

Mooi prestatie wel!
Guinness is een scam (https://www.youtube.com/watch?v=HIbeF0bf1Gk). Ze hebben daar helemaal geen autoriteit over, maar willen wel dat iedereen gelooft van wel.
Hoeft niet, ze nemen het gewoon op in de volgende druk, kan iedereen het verifiëren als ze willen.
Waar blijft Matt Parker met een filmpje hierover? Ongetwijfeld dat hij weer een manier heeft gevonden om Pi met de hand uit te rekenen, of weer wat leuke feitjes heeft gevonden.

Of een nieuwe mile of Pi? Er zijn wat meer cijfertjes bekend nu. Gewoon een kleiner lettertype nemen dan en printen maar.

Voor de mensen die geen idee hebben waar ik het over heb. Matt Parker op youtube _/-\o_
Alstublieft: https://www.youtube.com/watch?v=0r3cEKZiLmg

Tenminste, dat gaat niet over deze nieuwe berekening, maar is een filmpje van Numberphile waar ze de eerste miljoen cijfers op een heel erg lang stuk papier hebben uitgeprint.

*edit* Oh, oeps, je verwijst zelf al naar die video.

[Reactie gewijzigd door jj71 op 22 juli 2024 15:06]

No problems. Sowieso is numberphile (en de andre kanalen van Brady) een aanrader.

Computerphile, periodic videos etc etc. Dus lekker je link laten staan :D
Vooralsnog geven ze alleen de laatste tien cijfers van de uitkomst: 7817924264
Hoe kan een getal eindigend op 4 een priem getal zijn?

Ouch, ik let niet op...

[Reactie gewijzigd door 2400baud op 22 juli 2024 15:06]

pi is geen priem getal maar een oneindig lang getal. En dit is niet het volledige getal. Het zijn de laatste cijfers als je pi op 62,8 biljoen cijfers berekend.
Die fout heb ik ook eens gemaakt, het is: irrationaal ;)
Ik geef de Nederlandse taal de schuld van die verwarring.
Pi eindigt altijd op 42 :+
Omdat dit over pi gaat :) Dus, 3.14......7817924264
Pi is geen priemgetal, dat zijn alleen maar gehele getallen, geen breuken.
En 4 is niet het laatste cijfer, dat gaat oneindig door, zolang je maar blijft rekenen.
Waarom moet het een priemgetal zijn?
Niet, maar wat heeft dit met het artikel te maken?
Ik kan nergens vinden dat ze aangeven dat het om een priemgetal gaat - waar zie je dat staan?
Pi is geen priemgetal. Is hoeveel keer de diameter van een cirkel is z'n omtrek kan. Het getal begint met 3,1415 en gaat dan tot in het oneindige door.
Pi is helemaal geen priemgetal.
En het eindigt ook niet op 4.
Pi is een fractie, dus met een "drijvende komma"; als een geheel getal eindigt op 4 is het inderdaad sowieso deelbaar door 2 en dus niet priem. Bij een fractie werkt dit anders, kijk maar naar 1,4 of 2,4 :)
Of pi überhaupt een priemgetal is hangt af van de definitie je hanteert. Vaak gaat het bij priemgetallen namelijk alleen over positieve gehele getallen.
Daarnaast eindigt pi niet op een 4. Het heeft een oneindig aantal decimalen en toevallig zijn die in dit geval berekend tot aan deze 4.
Het getal 'eindigd' niet, het is afgekapt. De afgepakte versie hoeft zeker geen prime te zijn (zoals bijvoorbeeld 3.14 = 2x0.207), er komt altijd nog een cijfer achter.

De open discussie of Pi an sich een priem getal zou moeten zijn, daar zijn ze het volgens mij nog steeds niet over eens :P
Waarom zou het een priemgetal zijn? Vergeet ook niet dat pi geen laatste getal heeft.
Als ik 47 pak, wat een priemgetal is, en ik kijk naar alles voor het laatste cijfer, is dat (4) ook geen priemgetal.
en wat heb je hieraan? serieuze vraag.
Idd veel mensen weten niet eens waar PI voor nodig is. :)

Op dit item kan niet meer gereageerd worden.