Distributed computing ontdekt 44ste Mersenne-priemgetal

Sorry, maar geen enkele computer kan hier fatsoenlijk mee werken binnen afzienbare tijd.

10 mildoen getallen = 32Mbit!!! (zoals de beschrijving 2^32,582,657-1 ook al aan geeft)

Heel simpel gezegd (en natuurlijk in de praktijk niet waar) zou een 32bit processor 1 miljoen clockcycles nodig hebben voor een simpele +1 functie...

@knirfie: Je kan stoppen wanneer er geen overflow bit meer is. En dat gebeurt met 1/2 kans in de eerste bit, met 1/4 kans in de tweede bit, met 1/8 kans in de derde bit, enz. Een 64-bit processor doet er dus amper ooit meer dan één klokcyclus over.

Zo zijn er nog wel trucken genoeg om snel te werken met grote getallen.

Een miljoen clock cycles is niet zoveel hoor. Dat kan een oude C64 zelfs nog in 1 seconde (1 MHz, 8 bits welliswaar) Een redelijk moderne PC stampt die er dus in minder dan een milliseconde doorheen.
Goed, voor computerbegrippen nog steeds traag, maar ik kan niet eens zo snel met mijn ogen knipperen.

Heel simpel gezegd (en natuurlijk in de praktijk niet waar) zou een 32bit processor 1 miljoen clockcycles nodig hebben voor een simpele +1 functie...

1 miljoen clockcycles is voor een beetje pc ook maar een halve miliseconde, dus een beetej pc zou best makkelijk kunnen rekenen met dit soort getallen, en 2.000 berekeingen per seconde noem ik wel fatsoenlijk werken, helemaal met getallen van bijna 10 megebyte groot!

Heel simpel gezegd (en natuurlijk in de praktijk niet waar) zou een 32bit processor 1 miljoen clockcycles nodig hebben voor een simpele +1 functie...

ofte 1Mhz

het gaat niet om de grootte van 1 getal ,maar om de tijd die nodig is om alle combinaties na te lopen, zo is de sleutel te kraken.

Nee is ook een antwoord. dan weet je dat je iets anders moet proberen.

Misschien moet je in de politiek gaan, daar worden ook vooral zaken die binnen 4 jaar - voor de volgende verkiezingen - zichtbaar nut hebben belangrijk gevonden.
Aan de andere kant (@Vincenzo0): wie weet wordt in de toekomst kennis die met het zoeken naar en vinden van priemgetallen is opgedaan wel nuttig toepasbaar bij kankeronderzoek.

met een priemtest?

http://en.wikipedia.org/wiki/Primality_test

Nee, met een Lucas-Lehmer test. Een priemtest zou veel te lang duren.

Mersenne priemgetallen hebben ten opzichte van normale priemgetallen een belangrijke 'bijzondere algebraische' eigenschap waardoor ze veel sneller te vinden zijn dan priemgetallen.

Zie http://mersenne.org/math.htm
onder Lucas Lehmer testing.

Het zoekprogramma dat de LL-test bevat is overigens grotendeels met de hand geschreven in ASM (!), de meest low-level programmeertaal mogelijk, en is waarschijnlijk voor Intel processoren het best geoptimaliseerde programma ter wereld.

Daarom draait het ook iets van 25% langzamer op praktisch alle AMD procs*.

*Zie de benchmarks: http://mersenne.org/bench.htm

de meest low-level programmeertaal mogelijk,

Beetje mierenneuken, maar omdat je het zo stellig brengt: assembly is zeker niet de meest low-level. Heel flauw is machinecode nog 1 level lager (flauw omdat de binaire opcodes 1:1 mappen naar de assembly mnemonic, maar toch een cpu excute geen programma text in character format).

Een stapje lager is direct in de mirco-code van je CPU programmeren. Sommige architecturen staan dit theoretisch toe. Assembly is voor veel systemen vanuit het gezichts punt van de CPU ook maar een high-level taaltje; de zogenaamde ABI.

Binnenin de CPU wordt deze high-level assembly instructie stroom dan omgezet naar de native interne code. Het kan zelfs zijn dat de omzetting relatief zo groot is dat het een andere paradigma wordt. Bekenste voorbeeld is natuurlijk x86.

Zowel de AMD als Intel processoren, alsmede een handjevol andere architecturen hebben de x86 assembly instructies als high-level taal. Toch execute geen van beide CPUs X86 instructies direct. Zelfs binnen de intel familie zijn de netburst interne instructies anders als die van core.

Maar zelf hier kan het NOG lager. Microcode stuurt ook alleen maar je (data) paden binnen je CPU aan. Je kunt ook DIRECT de paden in de gewenste manier instellen voor jouw specifieke probleem. Dit kan 1 malig in hardware (een ASIC), maar kan ook dmv reconfigurable computing systemen.

Wat betreft het 1e deel van je betoog heb je gelijk. Bedacht ik me zelf ook net na mijn post, maar toen riep de plicht van de arbeid en kon ik het niet meer aanpassen. Vraag is dus hoever ze al zijn met het zoeken naar alle mogelijk priemgetallen (geen idee).

Je 2e argument (distributed computing) gaat minder op. zie linkje in de 1e regel van het artikel. In 2003 is via hetzelfde project al een Mersenne priemgetal gevonden dat vele malen groter is dan de wortel van het nu gevonden getal. Lijkt me niet dat ze stukjes meer dan 3 jaar open laten staan. Komt het binnen, zeg, een paar maanden niet terug, dan wijzen ze het wel weer toe aan een ander.

Hey! Oefening baart kunst hoor!

Dit lijkt op een lapsus

3*4 lijkt even
4*5 ook eigenlijk

Ik begin iets te vermoeden...

Helaas, oftewel M is even of M+1 is even. Je vermenigvuldigt dus altijd met een even getal. Gevolg is dat je altijd een even getal als antwoord krijgt. Delen door 2 kan dus prima en levert weer een geheel getal op.

ehhh.... inderdaad, stom van me

wie weet waar we met nanomechanica allemaal tegen aan gaan lopen