The Simpsons er propfyldt med matematik

I et afsnit af den animerede tv-serie The Simpsons kan man se en ligning på en tavle bag hovedpersonen Homer Simpson.

[latex] 1782^{12} + 1841^{12} = 1922^{12} [/latex]

Regn selv efter med Googles regnemaskine på nettet eller din egen lommeregner. Både højre og venstre side giver resultatet [latex] 2,5412103 \times 10^{39} [/latex].
Hvordan kan det være? Fermats sidste sætning siger jo, at ligningen [latex] x^n + y^n = z^n [/latex] ingen heltalsløsninger har for n > 2.

Højresiden og venstresiden er dog ikke identiske. Hvis vi havde taget flere cifre med, end Googles regnemaskine tilbyder, ville vi opdage en lille, men betydningsfuld relativ forskel på omkring [latex] 2 \times 10^{-10} [/latex]
Det er dog et godt eksempel på, at manuskriptforfatterne til tv-serien om den dysfunktionelle familie i Springfield lister matematik ind i fortællingen.

Det er ikke så overraskende, for flere af manuskriptforfatterne er højt uddannede i matematik.

Den britiske forfatter Simon Singh, der skrev en berømmet populærvidenskabelig bog om Fermats sidste sætning og Andrew Wiles' moderne bevis herfor, er nu aktuel med bogen ’The Simpsons and their matematical secrets', der fortæller om manuskriptforfatterne og den mere eller mindre skjulte matematik i tv-serien.

Simon Singh har selv skrevet om sin nye bog i the Guardian, hvorfra denne artikel henter flere af sine eksempler.

Talmystik på Springfield Stadium

I en episode fra 2006 er Homer og Marge på et baseballstadion, hvor man et kort øjeblik ser et spørgsmål på en storskærm til tilskuerne om, hvor mange der er til stede. Der er fire muligheder: 8128, 8208, 8191 eller ’no way to tell’.

Hvis du tror, at de firecifrede tal er tilfældigt valgt, kan du godt tro om igen. Det første er et perfekt tal, det andet er et narcissistisk tal og det tredje er et Mersenne-primtal.

Perfekte tal eller fuldkomne tal er tal, hvor summen af alle de tal, der går op i tallet, giver tallet selv. 6 er det første perfekte tal (1+2+3=6), det næste er 28 (1+2+4+7+14=28). Det tredje perfekte tal er 496, og det fjerde er 8128.

Et narcissistisk tal er et tal, som er forelsket i sig selv.

8208 indeholder fire cifre, opløfter man hver af dem til fjerde potens, får man tallet selv [latex] 8^4 + 2^4 + 0^4 + 8^4 = 8208 [/latex]Hvis man ser bort fra encifrede tal, er 8208 det sjette narcissistiske tal – i titalssystemet bør man rettelig tilføje.

8191 er et Mersenne-primtal af formen [latex] 2^p – 1 [/latex]hvor p er et primtal, som i det aktuelle tilfælde er 13.

I sin artikel i the Guardian giver Simon Singh mange flere eksempler på indlejret matematik i tv-serien.

Matematikere som manuskriptforfattere

Forklaringen på de mange matematiske hentydninger skal findes i manuskriptforfatternes uddannelsesmæssige baggrund.

Al Jean, der var med som manuskriptforfatter på The Simpsons fra begyndelsen af 1989, blev allerede som 16-årig optaget på Harvard University i 1977, og han fik sin bachelorgrad i matematik i 1981.

Det fortælles, at han i begyndelsen ved Harvard blev anset som noget af en matematisk troldmand, men at det hurtigt blev hans komiske talenter, som blomstrede op.

Jeff Westbrook har en ph.d.-grad i matematik og var ansat ved Yale University og AT&T Laboratories, før han blev manuskriptforfatter. Han fortsatte dog sideløbende en matematisk karriere og publicerede så sent som i 2008 en artikel med titlen Linear-Time Algorithms for Dominators and Other Path-Evaluation Problems.

David S. Cohen, som har ændret sit navn til David X Cohen for at fremhæve sin matematiske interesse, er en anden af de kendte manuskriptforfatter til The Simpsons. Han var desuden sammen en anden matematiker, Ken Keeler, med til at skrive til science fiction-serien Futurama.

David X Cohen skrev i 1995 en videnskabelig artikel med titlen: On the problem of sorting burnt pancakes.

Den relaterer til et sorteringsproblem, som kaldes pandekagesorteringsproblemet. Sorteringsproblemet for brændte pandekager er en særlig svær variant heraf.

Selvom det er en lidt anden historie, er det værd at notere, at det i øvrigt er inden for samme område, man skal finde den eneste videnskabelige artikel, som Bill Gates er medforfatter til.

Simon Singh spurgte Davis X Cohen om, hvordan en hjerne, der er velegnet til at studere pandekagesortering, også kan skrive underholdningskomik og fik svaret:

»Hvis man forsøger at lave en vittighed ud af den blå luft, er der ingen garanti for, at den vil opfylde de ting, du ønsker – eller at den bliver morsom. På samme måde er der ingen garanti for, at der findes et matematisk bevis for noget, som du søger at bevise«.

Men hvad siger anmelderen?

Så meget for smagsprøver på bogens indhold, men hvordan er bogen modtaget?

Thomas Jones har skrevet en anmeldelse i the Guardian, hvori han bemærker, at bogen er en letlæselig og ufarlig introduktion til en lang række matematiske begreber. Han noterer dog også, at det ikke er helt klart, hvem bogen er skrevet for.

Der er fem eksaminationer placeret med passende mellemrum i bogen. Hver af disse består af en række matematiske vittigheder, som giver point, hvis man forstår pointen.

Eksaminationerne hedder grundskolen, gymnasiet, indledende universitetsniveau, kandidateksamen og ph.d., og Thomas Jones beretter, at han klarede det med bravur til og med det indledende universitetsniveau, slap lige igennem kandidateksamen og dumpede på ph.d.-niveauet.

»Eksaminationerne må dog være navngivet som en smiger til læseren, da jeg opgav matematikken midtvejs i mit sidste år i gymnasiet,« skriver han.

Smagsprøve på bogens matematiske vitser

Afslutningsvis er her nogle få af matematikvitserne fra bogen

Hvad er de 10 forskellige slags personer i verden? De som forstår binære tal, og de som ikke gør.

Hvorfor forveksler programmører ofte halloween og jul? Fordi Oct. 31 = Dec. 25

Nogle af vittighederne er vanskelige at oversætte, så vi snupper lige to på engelsk:

What’s a polar bear? A rectangular bear after a coordinate transformation.

What do you get if you cross a mosquito with as mountain climber? You can’t cross a vector with a scalar.

Er det god matematikværkstedshumor? Det synes jeg.

Emner : Matematik
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Hvis vi havde taget flere cifre med, end Googles regnemaskine tilbyder, ville vi opdage en lille, men betydningsfuld relativ forskel på omkring [latex]2×10^{-10}[/latex]

Hvordan kan heltalsoperationer give en forskel på [latex]2×10^{-10}[/latex]?

  • 1
  • 0

Jeg får helt lyst til at bidrage med denne, som desværre, må fortælles på engelsk, men som til gengæld må siges at være specielt relevant i ingeniørkredse.

An airplan runs into serious trouble. The pilots can't controle it. It moves completely erratic, and is on the verge of crashing. The a man stands up and says "Will all passengers with a Polish passport please move to seats to the left of the aisle". His fellow passengers complies and immediately the plan goes back to calm, controlled flying.

"Wow, how did you do that another passenger asks". Well he says "I just made sure that all poles were placed in the left half of the plane"

  • 6
  • 0

Og til dem der vil se en måde man kan beregne differencen eksakt:

python -c "print abs(1782 ** 12 + 1841 ** 12 - 1922 ** 12)" 700212234530608691501223040959

Altså forudsat man har Python installeret.

Python har i øvrigt ingen problemer med at beregne tal som fx 1922 ** 1922 – resultatet kommer øjeblikkeligt (9 ms på min computer) og er på 6312 helt eksakte cifre. :-) Fuldstændig ubrugeligt men ret sjovt.

  • 0
  • 0

Hvis man udelader "abs" ses, at resultatet er negativt.

Er der en logisk forklaring paa at følgende, indtastet i IDLE giver lidt forskellig resultat?

print 1782 ** 12 + 1841 ** 12 - 1922 ** 12 -700212234530608691501223040959

1782 ** 12 + 1841 ** 12 - 1922 ** 12 -700212234530608691501223040959L

  • 0
  • 0

Jeg kan ikke forstå at de kan sige at både højre og venstre side giver det samme, nemlig 2,5412103×10^39. Hvordan i alverden får de det resultat? Når jeg regner på min HP48GX lommeregner, bliver venstre side 3,623x10^15 og højre side giver 1,922x10^15 og forskellen er 1,701x10^15.

  • 0
  • 0

Min billige maskine, købt i ALDI giver:

1782^12+1841^12 = 2.54121025910^39 = a 1922^12 = 2.54121025910^39 = b a - b = -7,01*10^29

IDLE i ikke eksakt mode: a - b = -7.0021195034097754e+29

  • 0
  • 0

Aaaah ok - det var mig der misforstod - det var ikke x10^12, men bare ^12. Ok - så får jeg resultatet af a - b = -7,1x10^29. Men stadigvæk, hvorfor skriver artiklen at det giver det samme?

  • 0
  • 0

Men stadigvæk, hvorfor skriver artiklen at det giver det samme?

2.54121025910^39 = a 2.54121025910^39 = b

Tilsyneladende er a = b, men a - b = -7.0021195034097754e+29 /= 0

  • 0
  • 0

Hvad er de 10 forskellige slags personer i verden? De som forstår binære tal, og de som ikke gør.

Åh. Du glemte alle os, der misforstod joken og troede den handlede om ternære tal.

  • 0
  • 0

Du glemte alle os, der misforstod joken og troede den handlede om ternære tal

De er ikke glemt. Nogle af dem forstaar binære tal andre ikke.

  • 0
  • 0

@Per Hansen. 9ms er sikkert fint i python, men Lisp er nu hurtigere ;)

Følgende funktion udregner korrekt at ligningen ikke holder:

(defun simpsonstest () (- (expt 1922 12)(expt 1782 12)(expt 1841 12))) ; udregn forskellen mellem højre og venstre side af 1782^12+1841^12=1922^12

compileret er denne funktion lynhurtig. 1 kald til denne funktion er under 1 ms... og ikke målbar uden en løkkestruktur, hvilket jeg ikke har gidet teste.

(time (simpsonstest)) Timing the evaluation of (SIMPSONSTEST)

User time = 0.000 System time = 0.000 Elapsed time = 0.000 [ms]

Har I nogen bud på alternative hurtigere (og korrekte!) koder ?

By the way - dit 1922^1922 udregner Lisp på bare 2 ms! (jeg vil ikke skrive resultatet her, det fylder for meget, men det ender på ..184)

  • 0
  • 0

9ms er sikkert fint i python, men Lisp er nu hurtigere ;)

Følgende funktion udregner korrekt at ligningen ikke holder:

(defun simpsonstest () (- (expt 1922 12)(expt 1782 12)(expt 1841 12)))

Lisp og lisp. tjah bum bum? Det er Expt funktionen i maskinkode der er hurtig. Og det vil den være uanset om den kaldes fra lips eller et andet sprog. Men prøv at skrive Expt funktionen fra bunden i lisp og se så hvor hurtig den er, sammenlignet med en kodning fra bunden i f.eks. C. Ellers kunne jeg også påstå at APL er lynhurtigt. Det beregner i hvert tilfælde sådan en opløftning hurtigt!

  • 0
  • 0

@Jens Olsen. Javist er det en kompileret funktion, men det rører jo ikke ved at det er >> hurtigere end python.

Kan APL også regne med vilkårligt antal cifre? Lige dér må jeg erkende at have et hul i min programmeringsmæssige dannelse.

Og C? Tja, det kan vel lade sig gøre at lave kode der kan udregne x^y med et vilkårligt antal cifre. Men anvendelse af standard funktioner/typer såsom Long Int er vel out-of-the-question? og så er vi tilbage til, hvad er hurtigst når man samtidig skal tænke på at man også selv skal lave koden? I Lisp tager det max 1 minut at kode og teste ovenstående.

  • 0
  • 0

Kan APL også regne med vilkårligt antal cifre?

Ja det ved jeg sgu ikke lige. Kommer vel an på hvilken implementation vi taler om.

Ellers kan vi nok finde noget som MathLab eller andet der klarer det i lyntempo. Pointen er at det som sådan ikke har noget med sproget at gøre, men hvor god implementation af denne funktion er i assembler. Vel iøvrigt ikke lige den sværeste funktion at skrive i assembler.

  • 0
  • 0

Tværtimod, sproget har en hel del med det at gøre. funktionen x^y kan sikkert også være implementeret 'perfekt' i Excel /VBA , men det gør jo ikke Excel /VBA til en god måde at løse dette problem på, pga begrænsninger i variabeltype/størrelser. Samme gør sig gældende for assembler. Det kan være det er super hurtigt, men hvis det tager timer at skrive koden så ....

  • 0
  • 0

Tværtimod, sproget har en hel del med det at gøre. funktionen x^y kan sikkert også være implementeret 'perfekt' i Excel /VBA , men det gør jo ikke Excel /VBA til en god måde at løse dette problem på, pga begrænsninger i variabeltype/størrelser.

Er expt funktionen ikke en udvidelse af lips kun tilgængelig i visse implementationer? Hvis jeg kan finde et php-bibliotek, der implementer potensopløftning ved at akceptere to tekststrenge og returnere resultatet som en tekststreng, så er php det perfekte sprog "at løse problemet i"?

Om der tilfældigvis findes lige den funktion man søger i et funktionsbibliotek, har intet som helst med sproget som sådan at gøre. Altså om det er proceduralt eller declaretivt, blokstruktureret, objetorienteret etc. Findes funktionen i et bibliotek, så tager det sgu den samme tid at skrive ét enkelt funktionskald uanset om sproget er baseret på en operationel formulering af lambda-kalkulen eller det er good old Fortran.

  • 0
  • 0

av, ramte jeg en nerve her? Sagen er vi stadig kun har to eksempler på kode der korrekt udregner 1922^12 - 1782^12 1841^12 ;

min Lisp: (- (expt 1922 12)(expt 1782 12)(expt 1841 12)))

og Per Hansens Python : python -c "print abs(1782 ** 12 + 1841 ** 12 - 1922 ** 12)"

Show me your code...

  • 0
  • 0
Bidrag med din viden – log ind og deltag i debatten