mboost-dp1

unknown

Nyt tal på tronen som verdens største primtal

- Via NewScientist - , redigeret af Net_Srak

Verdens største Mersenne primtal hedder fra nu: 2^24,036,583-1.

Tallet er fundet igennem GIMPS (Great Internet Mersenne Prime Search) som er et system a la Folding@Home og Seti@Home. Mere end 200.000 computere leverer CPU timer til systemet i søgningen efter nye primtal. Det nye tal har over 7 millioner cifre, hvor den gamle rekord var på 6.3 millioner cifre.

Det nye tal blev fundet af Josh Findley fra Seatlle, USA. Hans computer brugte 14 dage på at verificere tallet inden det blev indrapporteret, siden har andre systemer bekræftet tallet.





Gå til bund
Gravatar #101 - bnm
5. jun. 2004 02:32
83 roben:
[Det ser uoptimeret ud i mine øjne. Nu kender jeg ikke lige Huffman-algoritmen]
At vide hvad der er tale om er som regel et godt udgangspunkt for diskussioner.

[men der skulle da ikke være brug for mere end 4 pladser til tallene?]
Jeg bruger ikke mere end højst 4 bit, så jeg ved ikke hvor du er på vej hen.

[Det smarte ville så være at bruge tallene 3, 5 og 7 som er de mest brugte primtal i "verdens hidtil største primtal".]
Hvad mener du lige med "mest brugte primtal" og tænker du på en primtalsfaktorering? i så fald burde du måske lige tænke over at primtal ikke har en primtalsfaktorering anden end 1*[tallet selv]...

Hvis man sorterer værdierne der optræder i primtallet efter hyppighed (lavest først) ser det ud som følger: 3, 0, 2, 1, 8, 4, 6, 5, 7, 9.

0-3 har altså den laveste frekvens, og du vil kunne bemærke, hvis du kigger på mine resultater, at det også er dem som har den længste repræsentation.
Gravatar #102 - bnm
5. jun. 2004 03:03
Rettelser til min #82: jeg var ikke helt konsekvent så kodningerne blev lidt uregelmæssige. Det ville dog fungere efter hensigten da ingen af dem er præfiks af en anden og de har alle den minimale længde.

Men her er hvordan det ser ud når det er gjort konsekvent: Huffman
Gravatar #103 - repsac
5. jun. 2004 05:56
#99 (amokk):
Modsat hacker/cracker, er der vedr. mb/MB ikke noget at diskutere ... :-)


#100 (Viper):
Jeg kan lide din "entusiasme" mht. præfiks-finurlighederne, men det hedder jo groft set ikke "kiloByte" med stort "B" ... ;-)


#102 (bnm):
/me er gået i max flueknepper mode: "karakterer" er sådan nogle man bliver vurderet med til eksaminer – "tegn" er ordet du har brug for ;-)
Uhm, så er det så lige jeg krydstjekker ... dendanskenetordbog.dk sig skam godt nok at "karakter" også kan betyde "tegn", men ... hmm ... nogen der har en "rigtig" retskrivningsordbog? (dendanskenetordbog.dk har ofte "for meget med" og ligger sig tættere på hvordan sproget bliver brugt end hvordan det jf. retskrivningsordbogen "bør" bruges.)

Nuvel, godmorgen :-)
Gravatar #104 - Viperaberus
5. jun. 2004 08:32
Lettere off topic start
#103
"...er der vedr. mb/MB ikke noget at diskutere"
Er Megabit og MegaByte det samme??? Siden hvornår? Og hvad med MiB nu vi er igang?

"...det hedder jo groft set ikke "kiloByte" med stort "B""
Det ved jeg! Jeg skrev også "persononligt ta'r jeg...". Dvs det står for egen regning! Jeg mener dog, at det underbygger forkortelserne (Så længe der er den forvirring der er)

Som sagt er jeg ret ligeglad om folk bruger m/M, men b/B er der trods alt en faktor 8 forskel på ;)

Ang karakter/tegn... Det er i mine øjne det samme!

Men det er vist også ved at blive for meget off topic
Slut herfra
Lettere off topic slut
Gravatar #105 - amokk
5. jun. 2004 12:10
"er der trods alt en faktor 8 forskel på ;)"

kommer sgu an på hvilken protokol man kører... hvis du fx. kører med paritet og start og stop-bit, er der faktor 11 til forskel
Gravatar #106 - repsac
5. jun. 2004 16:11
#104 (Viper):
Nej der er intet at diskutere. Der er netop én måde at gøre det rigtigt (præcist) på og utallige måder at gøre det forkert på :-)

Hvad med systemer som har 16 bit pr. byte? (De må findes. Var gamle systemer 4-bit-tingester?)


#107 (amokk):
Er det mest normale ikke at man så kun benytter sig af de første syv bit som information og den sidste som paritetstjek? (Summen skal være lige/ulige ...)
Har du et link til noget om sådanne protokol? Hvor bliver den brugt i praksis? (Jeg er ganske interesseret i den praktiske vinkel, fordi jeg udelukkende har en teoretisk idé om, hvorledes skidtet foregår.)
Gravatar #107 - Viperaberus
5. jun. 2004 16:33
Lettere off topic start
#106
Selvom et system kører med et andet antal bit er en Byte stadig 8 bit.
32 bit computere opereret blot med 4 Bytes af gangen
Hvis du kan finde noget der dokumenterer, at en Byte ikke er 8 bit ser jeg det da meget gerne! (Du nævner systemer der har 16 bit pr. Byte...)

#105
Stopbit+startbit bliver lagt på en Byte inden den sendes (serielt), men det ændrer ikke, at en Byte er 8 bit. Det gør blot at en Byte når den sendes kommer til at fylde 1 Byte+x startbit+x stopbit!
Paritetsbitten erstatter normalt den øverste bit i en Byte (dvs, at det kun er værdierne 0-127 der kan sendes)
Lettere off topic slut
Gravatar #108 - bnm
5. jun. 2004 16:47
#107 viper: det passer ikke. Man kan fint snakke om systemer hvor en byte ikke er 8-bit, men f.eks. 11, som f.eks. indenfor store dele af telekommunikationen.

Og på instruktionsniveau er en byte den mindste del af et word man kan adressere.

Her er der blandt andet referencer til 6- og 7-bit bytes: Wikipedia entry for byte, og det nævnes at den første byte var 6-bit.

En octet derimod er klart en gruppering af 8.
Gravatar #109 - amokk
6. jun. 2004 14:35
#106 når man måler datastørrelser osv. så er 1 byte=8 bit. uanset hvor lange instruktioner CPUen kan arbejde med eller hvor bred bussen er.

mht. seriel overførsel kan det gøres på mange måder, 7 eller 8 databit, med eller uden paritet, med eller uden startbit osv.

#107 hvis man kører med paritet, har man en ekstra bit, så man i alt har 9 databit... jeg tror det er signed chars du tænker på, hvor MSBen bruges til at afgøre om det er et positivt eller negativt tal..
Gravatar #110 - Viperaberus
6. jun. 2004 15:00
#108
OK, Jeg var ikke klar over, at en Byte kunne være andet end 8 bit, men man lærer jo noget hele tiden!

#109
Jeg tænkte rigtig nok på seriel kommunikation: 7 databit + 1 paritet, i modsætning til 8 databit uden paritet ;) Hvilke andre kombinationer der er har jeg ikke undersøgt :-O
8 Databit + 1 paritet bit gi'r 9 bit, MEN det er IKKE 9 databit (Jeg vælger at tolke det som en typo fra din side, men pointerer det dog)
Gravatar #111 - amokk
6. jun. 2004 21:16
#110 ja det var vist en typo... men 7+1 bit er ikke det samme som 8 bit... pariteten er en fejlkontrol, så hvis man kører 7 bit med paritet, er der kun 7 bits data man overfører hver gang, og bruger den sidste bit til at se om der er fejl i dataene. hvis man kører 8 bit uden paritet, overføres der 8 bits data hver gang, uden mulighed for kontrol.
Gravatar #112 - repsac
6. jun. 2004 21:38
Hvis man nu skal være pinligt korrekt må det være noget med at man, "ved at sende 8 bits hvoraf netop én er paritetstjekbit, sender maksimalt 7 bit information".

Strengt taget kan man jo godt sende et utal af bits uden at sende noget som helst information. Endvidere kan alle 8 bits betragtes som data, men kun de 7 indeholder information ... men det kommer jo an på hvorledes man definerer sin ordbrug. Jeg tror vi er enige om sagerne :-)

Lidt dansk og engelsk (mere teknisk) om entropi/information.
Gravatar #113 - amokk
6. jun. 2004 22:25
#112 var du i tvivl om hvad jeg mente i 111?
Gravatar #114 - repsac
6. jun. 2004 22:42
#113 (amokk):
Nej, men andre kunne måske være. Notationen "7+1 bit" er jeg ikke særlig glad for, da det jo reelt er 8 bits der bliver sendt af sted. At så én af dem er en paritetstjekbit er en "detalje", som kun vedrører afsender og modtager – ikke kanalen (det som informationen bliver transmitteret igennem). Derved forstår jeg at der sendes data i form af 8 bit (uanset om det er paritetstjek bits eller ej). Der er bare kun infomation i maksimalt (det behøver ikke være alle) 7 af dem.
Maksimalt syv af de otte bits indeholder så information, men i princippet kunne man jo ikke vide om man, ved at tilføje en enkelt bit og ændre nogle af de andre på en snedig måde kunne opnå faktisk at, kunne rette de fejl der måtte ske under transmissionen (forudsat at der er sket "få nok" fejl) ...
(Det viser sig så at det ikke er muligt, og man vil så bare (idet man antager at der maksimalt sker 1 fejl) vide om der er sket en fejl eller ej – altså om man skal retransmittere eller ej.)

Hvis man skal forklare noget for nogen, som ikke allerede kender til stoffet, mener jeg, at det er at foretrække, at være så præcis som mulig. Det var så hvad jeg forsøgte af bedste evne :-)
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login