---

Fra siden: http://www.saack.dk/maalogvaegt.shtml ser jeg at:
Googol 1 + 100 nuller
Googolplex 1 + 1 Googol nuller


Hvad er forskellen så på en Googol og en Googolplex?
Er det:
Googol = 1.000.000.000.000.0........
Googolplex = 10.000.000.000.0........ eller 11.000.000.000.0........ eller
1.000.000......001.
Ja hvad er forskellen?

Tillægsspørgsmål: Hvor søren bruger man så store tal?
Læs evt. forklaingen til størrelsen på en Googol... det er ekstremt!

ps: nævnes ordet Googolplex ikke i en af "Back to the Future", den med
Michael J. Fox og Christopher Lloyd?

---

Jens A. skrev:

> Googol 1 + 100 nuller
> Googolplex 1 + 1 Googol nuller

>Hvad er forskellen så på en Googol og en Googolplex?

Eksempel:
Gøg   = 1 + 10 nuller
Gokke   = 1 + Gøg nuller.

Gøg = 10 000 000 000
Gokke = 10 000 000 000 000 000 000 ... 000   i alt Gøg nuller
(altså 10 mia. nuller)

>Tillægsspørgsmål: Hvor søren bruger man så store tal?

I debatgrupper - og til at postulere at antallet af atomer i
universet er mindre end 1 Googol.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

"Bertel Lund Hansen" <nospam@lundhansen.dk> skrev i en meddelelse
news:gcckgug2h4m3r565eruvc1b871kvnrrac7@sunsite.auc.dk...
> Gøg = 10 000 000 000
> Gokke = 10 000 000 000 000 000 000 ... 000 i alt Gøg nuller
> (altså 10 mia. nuller)

Okay... den skulle bare lige "ind og vende" på lystavlen

> >Tillægsspørgsmål: Hvor søren bruger man så store tal?
>
> I debatgrupper - og til at postulere at antallet af atomer i
> universet er mindre end 1 Googol.

Ér der da ikke over én Googol atomer i universet?

---

"Jens A." <0011754m001@mail1.stofanet.dk> writes:

> Ér der da ikke over én Googol atomer i universet?

Jeg mindes at have set 10^79 (1 med 79 nuller efter) opgivet som
antallet af partikler i universet. Lidt søgning finder andre
der siger mindre end 10^77.
<URL:http://www.innerx.net/personal/tsmith/LARGEsmall.html>

Jeg kan dog ikke sige hvad der regnes som en partikel i den her
sammenhæng.

Vi brute tallet i kompleksitetsteori i datalogi. En bestemt operation
havde tidskompleksitet O(n log*(n)) hvor log*(n) var antallet af gange
man kunne iterere (2-tals) logaritmen på n før man nåede under 1.
Altså var log*(antal partikler i universet)=5, så man kunne i praksis
udskifte log*(n) i udtrykket med en konstant.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
'Faith without judgment merely degrades the spirit divine.'

---

"Lasse Reichstein Nielsen" <lrn@hotpop.com> skrev i en meddelelse
news:4rg5enzl.fsf@hotpop.com...
> Vi brute tallet i kompleksitetsteori i datalogi. En bestemt operation
> havde tidskompleksitet O(n log*(n)) hvor log*(n) var antallet af gange
> man kunne iterere (2-tals) logaritmen på n før man nåede under 1.
> Altså var log*(antal partikler i universet)=5, så man kunne i praksis
> udskifte log*(n) i udtrykket med en konstant.

I´m out Det fattede jeg så lige knap så meget af.... men du har da
sikkert ret (hvis du forstår min uvidenhed på området...)

---

On Fri, 14 Jun 2002 20:03:58 +0200, Lasse Reichstein Nielsen wrote:

> "Jens A." <0011754m001@mail1.stofanet.dk> writes:
>
>> Ér der da ikke over én Googol atomer i universet?
>
> Vi brute tallet i kompleksitetsteori i datalogi. En bestemt operation
> havde tidskompleksitet O(n log*(n)) hvor log*(n) var antallet af gange
> man kunne iterere (2-tals) logaritmen på n før man nåede under 1. Altså
> var log*(antal partikler i universet)=5, så man kunne i praksis udskifte
> log*(n) i udtrykket med en konstant.

Jeg har følgende definition fra min algoritme-bog:
Definer funktionen H således at:
H(0) = 1
H(i) = 2^H(i-1)
Dvs. H(4) = 2^(2^(2^2))
Nu defineres så lg*(j) (j >= 1) som det mindste i således at H(i) >= j.

Med denne definition fås følgende tabel:
i 0 1 2 3 4 5 6 ... 65536
H(i) 1 2 4 16 65536 2^65536 ...
lg*(i) 0 1 2 2 3 4

Sådan cirka...
Dvs. lg*(i) vokser ikke specielt hurtigt

Mvh
Martin
--
I sort through my snail mail and crack open the BOFH Monthly Newsletter,
"kill -9" and check out the articles therein. There's a nice peice of
making OS2 slow, boring and painful, but it looks exactly like the OS2
installation instructions to me... Ah, who knows.
   BOFH

---

Martin Ehmsen <thames@get2net.dk> writes:

> Jeg har følgende definition fra min algoritme-bog:
> Definer funktionen H således at:
> H(0) = 1
> H(i) = 2^H(i-1)
> Dvs. H(4) = 2^(2^(2^2))
> Nu defineres så lg*(j) (j >= 1) som det mindste i således at H(i) >= j.

Jep, det giver det samme. Vi havde ikke indført H (towerfunktionen med
base 2) på det tidspunkt, så vi fik bare en løs definition.

Hvis man VIRKELIG skal vokse hurtigt, så kan man bruge
Ackermann-diagonal-funktionen (som jeg viser her bare fordi jeg synes
den er sjov :)

Ackermann (en funktion af to argumenter)
A(0,m)=m+1
A(n,0)=A(n-1,1)
A(n+1,m+1)=A(n,A(n+1,m))
Ackermans-diagonal
A_d(n)=A(n,n)

Ackermann
n 0 1 2 3 4 5
m
0 1 2 3 4 5 6
1 2 3 4 5 6 7 (2+(m+3))-3
2 3 5 7 9 11 13 2*(m+3) -3
3 5 13 29 61 125 253 2^(m+3) -3
4 13 65533 2^65536-3 2^2^65536-3 ... 2!(m+3) -3
5 65533 2!65536-3 ... ingen symbol.

(2!n er towerfunktionen med base 2, i.e. H(n))

Diagonalfunktionen vokser altså som

1 3 7 61 2^2^2^(65536)-3 2!2!2!2!2!65536-3
(ell. H(H(H(H(H(65536)))))-3)

2^65536 fylder ca. fire siders udskrift (lille skrift, det har ca
20000 cifre decimalt). Dette tal svarer til antallet af cifre i
2^2^65536.... som igen er antallet af cifre i A_d(4).

Derefter bliver det *rigtigt* stort!

/L 'nørd der godt kan lide Ackermann'
--
Lasse Reichstein Nielsen - lrn@hotpop.com
'Faith without judgment merely degrades the spirit divine.'

---

On Sat, 15 Jun 2002 11:15:19 +0200, Lasse Reichstein Nielsen wrote:

> Hvis man VIRKELIG skal vokse hurtigt, så kan man bruge
> Ackermann-diagonal-funktionen (som jeg viser her bare fordi jeg synes
> den er sjov :)

Jeg overvejede faktisk også om jeg skulle tage Ackermann's funktion med i
mit indlæg. Men nu gjorde du det så...

Det fede ved Ackermann's funktion (blandt andre ting) er at det er
beviseligt at der ikke findes eksplicitte funktionsudtryk (ved de
almindelige regningsarter, potensopløftning osv.. Dette hedder noget
smart, som jeg ikke lige kan huske) som vokser hurtigere end Ackermann's
funktion.
Dvs. fx x^(x^(x^(x!))) osv... altid vil blive "slået" af Ackermann's
funktion. Det er ret sejt!

> 2^65536 fylder ca. fire siders udskrift (lille skrift, det har ca 20000
> cifre decimalt). Dette tal svarer til antallet af cifre i 2^2^65536....
> som igen er antallet af cifre i A_d(4).

Vores forlæser skrev A_d(1), A_d(2), A_d(3) op til en forlæsning, men bad
os om ikke at sende ham A_d(4)!

Er der ikke også noget om et type træ, hvis højde vokser som Ackermann's
funktion "invers"??
Det er hvad jeg ville regne for en konstant.

> /L 'nørd der godt kan lide Ackermann'

Det samme her

Martin
--
I sort through my snail mail and crack open the BOFH Monthly Newsletter,
"kill -9" and check out the articles therein. There's a nice peice of
making OS2 slow, boring and painful, but it looks exactly like the OS2
installation instructions to me... Ah, who knows.
   BOFH

---

On Sat, 15 Jun 2002 15:49:16 +0200, Martin Ehmsen wrote:

> Det fede ved Ackermann's funktion (blandt andre ting) er at det er
> beviseligt at der ikke findes eksplicitte funktionsudtryk (ved de
> almindelige regningsarter, potensopløftning osv.. Dette hedder noget
> smart, som jeg ikke lige kan huske) som vokser hurtigere end Ackermann's
> funktion.

Jeg fandt lige det korrekt udtryk: Ackermann's funktion er ikke "primitiv
rekursiv"

Martin
--
I sort through my snail mail and crack open the BOFH Monthly Newsletter,
"kill -9" and check out the articles therein. There's a nice peice of
making OS2 slow, boring and painful, but it looks exactly like the OS2
installation instructions to me... Ah, who knows.
   BOFH

---

Martin Ehmsen <thames@get2net.dk> writes:

> Jeg fandt lige det korrekt udtryk: Ackermann's funktion er ikke "primitiv
> rekursiv"

Og iøvrigt den *første* funktion der blev fundet der ikke var primitiv
rekursiv.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
'Faith without judgment merely degrades the spirit divine.'

---

Scripsit Lasse Reichstein Nielsen <lrn@hotpop.com>
> Martin Ehmsen <thames@get2net.dk> writes:

> > Jeg fandt lige det korrekt udtryk: Ackermann's funktion er ikke "primitiv
> > rekursiv"

> Og iøvrigt den *første* funktion der blev fundet der ikke var primitiv
> rekursiv.

Og i øvrigt konstrueret til at have den egenskab: for ethvert N er

fn x => ack(N,x)

den hurtigst voksende funktion som i højst N trin kan vises at være
p.r. (for en passende aksiomatisering af "p.r."). Diagonalen vokser
derfor hurtigere end en hvilkensomhelst p.r. funktion (som jo alle
skal have en endelig begrundelse for at være p.r.)

Det kan endda være - men jeg har ikke tænkt det helt igennem her midt
på natten - at med en endnu mere passende aksiomatisering vil ack(N,x)
være mindst lige så stor som f(x) for *ethvert* x og *enhver* funktion
f der i N trin kan vises at være p.r.

--
Henning Makholm "They are trying to prove a hypothesis,
they are down here gathering data every season,
they're publishing results in peer-reviewed journals.
They're wrong, I think, but they are still scientists."

---

Martin Ehmsen <thames@get2net.dk> writes:

> Er der ikke også noget om et type træ, hvis højde vokser som Ackermann's
> funktion "invers"??

Hvis du bruger en skov af træer til at repræsentere diskunkte mængder,
og bruger både "union by rank" og path compression", bliver køretiden
for n Make-Set- og m-n Union- eller Find-operationer O(m alpha(n)). hvor
alpha(n) er en form for invers til Ackermans funktion.

> Det er hvad jeg ville regne for en konstant.

Den er i praksis mindre end 4.

--
"Det er fundamentalt noget humanistisk vås, at der er noget,
der hedder blød matematik."
--- citat Henrik Jeppesen, dekan for det naturvidenskabelige fakultet

---

On Mon, 17 Jun 2002 14:44:45 +0200, Henrik Christian Grove wrote:

>> Er der ikke også noget om et type træ, hvis højde vokser som
>> Ackermann's funktion "invers"??
>
> Hvis du bruger en skov af træer til at repræsentere diskunkte mængder,
> og bruger både "union by rank" og path compression", bliver køretiden
> for n Make-Set- og m-n Union- eller Find-operationer O(m alpha(n)). hvor
> alpha(n) er en form for invers til Ackermans funktion.

Yeps, det var nøjagtigt det eksempel jeg ikke kunne huske.

>> Det er hvad jeg ville regne for en konstant.
>
> Den er i praksis mindre end 4.

Nå det mener du

Martin
--
There are 10 kinds of people. Those who count in binary and those who
don't
   Anonym

---

Henrik Christian Grove <grove@sslug.dk> writes:

> Hvis du bruger en skov af træer til at repræsentere diskunkte mængder,
> og bruger både "union by rank" og path compression", bliver køretiden
> for n Make-Set- og m-n Union- eller Find-operationer O(m alpha(n)). hvor
> alpha(n) er en form for invers til Ackermans funktion.

Det var netop denne funktion vi fik opgivet som log* til det selvsamme
problem. Opgaven var at lave en struktur hvor man kunne implementere
en ækvivalensrelation med operationerne "foren klasser" og "er
ækvivalente?". Med path compression blev den amortiserede køretid for
n operationer (startende fra singleton-klasser) netop O(n log*(n)).

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
'Faith without judgment merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen <lrn@hotpop.com> writes:

> > for n Make-Set- og m-n Union- eller Find-operationer O(m alpha(n)). hvor
> > alpha(n) er en form for invers til Ackermans funktion.
>
> Det var netop denne funktion vi fik opgivet som log* til det selvsamme
> problem. Opgaven var at lave en struktur hvor man kunne implementere
> en ækvivalensrelation med operationerne "foren klasser" og "er
> ækvivalente?". Med path compression blev den amortiserede køretid for
> n operationer (startende fra singleton-klasser) netop O(n log*(n)).

alpha og log* er ikke samme funktion, alpha vokser meget
lamngsommere. Beviset for at køretiden for de omtalte operationer er O(m
alpha(n)) er svært, men det er forholdsvist let at vise at den er (O(m
log*(n)), derfor er det ikke overraskende at I (hvem?) har set det.
Eftersom log*(n) for alle i praksis forekommende n er mindre end 5, er
de to udsagn lige gode til at indse at køretiden essentielt er uafhængig
af n.

..Henrik

--
"Det er fundamentalt noget humanistisk vås, at der er noget,
der hedder blød matematik."
--- citat Henrik Jeppesen, dekan for det naturvidenskabelige fakultet

---

Henrik Christian Grove <grove@sslug.dk> writes:

> alpha og log* er ikke samme funktion, alpha vokser meget
> lamngsommere.

Klart.

> Beviset for at køretiden for de omtalte operationer er O(m
> alpha(n)) er svært, men det er forholdsvist let at vise at den er (O(m
> log*(n)), derfor er det ikke overraskende at I (hvem?) har set det.

Datalogistuderende på første semester :)
/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
'Faith without judgment merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen wrote:
>
> "Jens A." <0011754m001@mail1.stofanet.dk> writes:
>
> > Ér der da ikke over én Googol atomer i universet?
>
> Jeg mindes at have set 10^79 (1 med 79 nuller efter) opgivet som
> antallet af partikler i universet. Lidt søgning finder andre
> der siger mindre end 10^77.

I så fald skal der jo

100 000 000 000 000 000 000 000 universer

til for at have 1 googol partikler.

--
Jeppe Stig Nielsen <URL:http://jeppesn.dk/>. «

"Je n'ai pas eu besoin de cette hypothèse (I had no need of that
hypothesis)" --- Laplace (1749-1827)

---

"Jens A." <0011754m001@mail1.stofanet.dk> skrev i en meddelelse
news:3d0a3135$0$264$ba624c82@nntp03.dk.telia.net...
> ps: nævnes ordet Googolplex ikke i en af "Back to the Future", den med
> Michael J. Fox og Christopher Lloyd?

Jo, hende kvinden i 3'eren bliver omtalt som "one in a million, one in a
googolplex"

--
Martin Højriis Kristensen - http://www.makr.dk/?usenet
Jeg repræsenterer med dette indlæg mig selv og ikke TDC Internet