Gå til innhold

256GB lagret på et A4 ark


Anbefalte innlegg

Videoannonse
Annonse
Det var jo noen som skrev ett helt kapittel eller en bok da på ett frimerke for ikke så fryktelig lenge sida. Kanskje ett par år siden?

Selv bibelen tar bare ca 5 MB, man må få plass til ca 340 bibler på et frimerke for at det skal bli like mye som 256 GB på et A4-ark (om man forutsetter et frimerke på 2x2cm).

Lenke til kommentar
Det var jo noen som skrev ett helt kapittel eller en bok da på ett frimerke for ikke så fryktelig lenge sida. Kanskje ett par år siden?

Selv bibelen tar bare ca 5 MB, man må få plass til ca 340 bibler på et frimerke for at det skal bli like mye som 256 GB på et A4-ark (om man forutsetter et frimerke på 2x2cm).

7375275[/snapback]

 

Høres helt kurant ut. Jeg tar med i regnestykket at teknologien har gått framover siden den frimerke greia. Å ta utgangspunkt i at det er forbløffende at de har fått til så mye data på ett ark sammenlignet mot den frimerke saken, som er GAMMEL, er helt uholdbart.

Lenke til kommentar

Det hele koker vel ned hvor mange forskjellige nivåer man kan beskrive med farger/figurer på et punkt. Vi beskriver jo 10 forskjellige nivåer med symbolene 0-9. Vi ser jo ikke på tallene 0-1-2-3-4 som "mindre enn 5" og 5-6-7-8-9 som "mere enn fem", hvis dere skjønner hvor jeg vil...

Lenke til kommentar
Gå helt fint ann det.

Er bare å printe ut datane på samme ark flre aganger oppå hverandre

7374660[/snapback]

 

Skal helst kunne lese dem ut også... Og hvorfor akkurat fire?

 

Det var jo noen som skrev ett helt kapittel eller en bok da på ett frimerke for ikke så fryktelig lenge sida. Kanskje ett par år siden?

7374749[/snapback]

 

Er ikke snakk om tekst her, bruker mer avanserte kodingsteknikker.

 

Det hele koker vel ned hvor mange forskjellige nivåer man kan beskrive med farger/figurer på et punkt. Vi beskriver jo 10 forskjellige nivåer med symbolene 0-9. Vi ser jo ikke på tallene 0-1-2-3-4 som "mindre enn 5" og 5-6-7-8-9 som "mere enn fem", hvis dere skjønner hvor jeg vil...

7375920[/snapback]

 

Jupp.

Bruker farger/figurer og intrikate mønstere. Antagelig ser det bare ut som fargerik støy (størst mulig entropi)

Lenke til kommentar

Jeg er nesten sikker på at dette er tull. 256GB er akkurat 274877906944 bytes. Hvis det er sant som han sier at det går 2.7GB per kvadrat inch så må han ha litt av en skriver/scanner for å få til det.

 

En vanlig skriver har kanskje 400 dpi (dots per inch). En inkjet skriver har fire grunnfarger og den kan bare skrive en prikk med en av fargene per dot. Dvs at per dot så har du 5 kombinasjoner (cyan, magenta, gul, svart og hvit). Dvs 400 * 400 * 5 kombinasjoner med data per kvadrat inch. Det er 800000 bits som er 100000 bytes som er 97 kB per kvadratinch. Hvis man regner med at scanneren klarer å scanne så detailjert...

 

Hvis du bretter papiret så ødelegger du data eller hvis det blir utsatt for fuktighet, elding eller får rusk på seg.

 

Bruken av små figurer vil heller ikke bruke mindre plass enn fargekoding. Dessuten lagrer en harddisk veldig mange bits per kvadratinch. Mye mer og mye mer til å stole på enn på papir :p.

 

Det er mulig å lagre data på papir, men det er lite til å stole på og du får ikke lagra på nærheten så mye som 256GB uansett hvordan du vrir og vender på det. Jeg tror det ikke før jeg får se det, fordi det er så godt som umulig med dagens skrive/scanne teknologi. Jeg kunne enkelt skrivi programmer for å skrive ut og lese inn data fra ark, men da kanskje på noen hundre kilobyte per ark.

Lenke til kommentar
Haha! Er sikkert bare en spøk som denne studenten nå ler ganske godt av :)

7380222[/snapback]

 

Fotopapir. En noenlunde kapabel maskin kan skrive 4800x2400 punkter per kvadrattomme.

 

Den kan skrive ut kanskje 16 unike farger, som er "lett" å skille fra hverandre.

Dermed får vi:

 

(4800x2400)^16

 

16 farger:

1: 0000

2: 0001

3: 0010

4: 0011

5: 0100

6: 0101

7: 0110

8: 0111

9: 1000

10: 1001

11:1010

12:1011

13:1100

14:1101

15:1110

16:1111

 

(11520000)^16 = 1 fantasillion "en" eller "null" per tomme.

Mer nøyaktig:

 

55 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 00 000 000 000 0000 000 000 000 000 000 000 tegn per tomme.

 

Uh...

 

Dette ble uhyggelig.

 

Værsåsnillåsiatjeggjordenoegalt, please... :dontgetit:

Endret av Andre1983
Lenke til kommentar
Haha! Er sikkert bare en spøk som denne studenten nå ler ganske godt av :)

7380222[/snapback]

 

Fotopapir. En noenlunde kapabel maskin kan skrive 4800x2400 punkter per kvadrattomme.

 

Den kan skrive ut kanskje 16 unike farger, som er "lett" å skille fra hverandre.

Dermed får vi:

 

(4800x2400)^16

 

16 farger:

1: 0000

2: 0001

3: 0010

4: 0011

5: 0100

6: 0101

7: 0110

8: 0111

9: 1000

10: 1001

11:1010

12:1011

13:1100

14:1101

15:1110

16:1111

 

(11520000)^16 = 1 fantasillion "en" eller "null" per tomme.

Mer nøyaktig:

 

55 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 00 000 000 000 0000 000 000 000 000 000 000 tegn per tomme.

 

Uh...

 

Dette ble uhyggelig.

 

Værsåsnillåsiatjeggjordenoegalt, please... :dontgetit:

7382452[/snapback]

 

Hvis du ganger med 16 istedet for å opphøye så får du mer riktig tall. I eksempelet ditt har du 16 forskjellige måter å representere en pixel på hvis jeg forstår deg riktig.

 

Men du skal ha cred for å bruke eksempel med en høyoppløslig printer :)

Det blir for dumt når folk tilbakeviser teknologien ved å bruke eksempel med en elkjøp-printer til 299,-

Endret av gaardern
Lenke til kommentar
Hvis du ganger med 16 istedet for å opphøye så får du mer riktig tall. I eksempelet ditt har du 16 forskjellige måter å representere en pixel på hvis jeg forstår deg riktig.

 

Men du skal ha cred for å bruke eksempel med en høyoppløslig printer :)

Det blir for dumt når folk tilbakeviser teknologien ved å bruke eksempel med en elkjøp-printer til 299,-

7382670[/snapback]

 

Det er faktisk ikke *opphøyd* i 16... Det er 16 opphøyd i 11520000

Eksempler:

 

Vi har to koder og hver av disse har fire muligheter.

 

11

12

13

14

21

22

23

24

31

32

33

34

41

42

43

44

 

Regnestykket er 4^2= 16...

 

------------------------------------

 

4 tall som er 1 til 10:

10^4 = 10000 muligheter: fra og med 1111 til XXXX -- eller 0000 til 9999.

 

Dermed er 11520000 punkter med 16 muligheter i hvert punkt 16^11520000...

Det er jo fremdeles sykt...

 

Dette siste stemmer: For hvert punkt har 16 muligheter: 2 punkter har 16^2 muligheter likesom to tall fra en til ti har hundre muligheter: 10^2

Men jeg tror uansett at vi er i mål: Det går lekende lett å skrive ut noen gigabyte på ett fotopapir.

Endret av Andre1983
Lenke til kommentar

"Antall muligheter" er bare forvirrende i denne sammenhengen. 32 bits/4 bytes gir over 4 milliarder forskjellige tall/kombinasjoner, men det er 4 bytes som er det interessante. Hvis en pixel kan lagre 4 bits betyr det at man trenger to for å lage en byte. Altså vil antall bytes (tegn) et ark kan lagre være = antall pixler det er plass til på et ark / 2.

 

Det er ca 97,5 kvadrattommer på et A4-ark, så med en oppløsning på 4800x2400/kvadrattomme vil det være plass til ca 535 MB, eller litt over 1/500-del av det man påstår å ha fått plass til.

Endret av HeltNils
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...