---

Hej

Jeg er lige i øjeblikket ved at lave en matematisk evaluator, og sidder
med et problem med hensyn til den matematiske syntax. Jeg har lavet den
så den følger standard-prioriteterne, men nu er mit problem dog lidt mere
grovkornet, for de matematik-programmer jeg har testet med er ikke helt
enige med mig i hvad udtrykket "2^3^4" skal give.. Wolframs Mathematica
evaluerer det nemlig som "2^(3^4)", og får så "2417851639229258349412352",
hvorimod mit program evaluerer det som "(2^3)^4", og derfor får "4096"...

Men hvad er rigtigt?

Lige nu arbejder jeg ud fra en model der hedder at operatorer har
følgende prioriteter, plus og minus 3, gange og division 2 og
potensopløftning 1. Det jeg så gør er at jeg deler et udtryk op i en
liste af udtryk, separeret af den vigtigste operator der står udenfor
paranteser i udtrykket... så jeg deler "23+34*2+34" ned til "23",
"34*2" og "34"... derefter gør jeg så det samme på "34*2" osv...

Er der nogen generelle fejl i den model? Den gør jo at 2^3^4 f.eks. ikke
bliver evalueret "rigtigt" (ifølge Mathematica selvfølgelig)... Men er
det et særtilfælde, eller bør jeg lave det helt om?

På forhånd tak.

--
Ulrik Jensen
ulrik@qcom.dk - http://www.minefilm.tk
"It's only a movie, and, after all, we're all grossly overpaid."

---

Ulrik Jensen <ulrik@qcom.dk> writes:

....

> er ikke helt enige med mig i hvad udtrykket "2^3^4" skal give..
> Wolframs Mathematica evaluerer det nemlig som "2^(3^4)", og får så
> "2417851639229258349412352", hvorimod mit program evaluerer det som
> "(2^3)^4", og derfor får "4096"...

> Men hvad er rigtigt?

Jeg ville stole på Wolframs version. Jeg ved ikke om det er en fast
regel, men i matematik ser jeg det kun blive udregnet som Wolfram
gør det.

> Lige nu arbejder jeg ud fra en model der hedder at operatorer har
> følgende prioriteter, plus og minus 3, gange og division 2 og
> potensopløftning 1. Det jeg så gør er at jeg deler et udtryk op i en
> liste af udtryk, separeret af den vigtigste operator der står udenfor
> paranteser i udtrykket... så jeg deler "23+34*2+34" ned til "23",
> "34*2" og "34"... derefter gør jeg så det samme på "34*2" osv...
>
> Er der nogen generelle fejl i den model?

Nej, den er fin. Ikke den mest økonomiske måde at gøre det på, men
hvis man ikke vil til at fedte med parsergeneratorer, så lyder den
til at virke.

> Den gør jo at 2^3^4 f.eks. ikke
> bliver evalueret "rigtigt" (ifølge Mathematica selvfølgelig)... Men er
> det et særtilfælde, eller bør jeg lave det helt om?

Det har faktisk ikke noget at gøre med din måde at dele op på. Problemet
er hvordan du sætter det sammen igen bagefter.

Tag 2+3+4. Det deler du op som 2, 3 og 4, og du husker at der står
plus imellem (og ikke fx minus, som har samme prioritet). Så lægger
du dem sammen fra venstre mod højre: først 2+3=5 og så 5+4=9.

Det virker for plus, minus, gange og division, men det fejler for
potensopløftning. Forskellen mellem fx minus og potensopløftning er at
2-3-4 læses som (2-3)-4, og minus siges at være "venstre-associativ",
mens 2^3^4 læses af fx Mathematica (og de fleste andre) som 2^(3^4).
Der skal du altså starte fra højre, og potensoperatoren kaldes derfor
"højre-associativ". I begge tilfælde giver det det forkerte svar at
regne i den forkerte rækkefølge.

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

---

Jeg tror, at 2^3^4 = 4096 er det mest udbredte (left-to-right order). Jeg
gætter på, at Mathematica gør det anderledes for at minde mere om den
håndskrevne potensopløftning med superscript.

Heldigvis er matematik i datalogi (i hvert fald den mere praktiske del med
compilere, mv.) et stort rod uden standarder, så du kan næsten bare gøre som
du vil

Din strategi med opdeling af regneudtrykket er rigtig nok. Det svarer til at
opbygge et træ, hvor hvert blad er et tal og hvert forgreningspunkt er en
regneoperation.

Mvh,

Lasse



"Ulrik Jensen" <ulrik@qcom.dk> wrote in message
news:uk7jdirxt.fsf@qcom.dk...
> Hej
>
> Jeg er lige i øjeblikket ved at lave en matematisk evaluator, og sidder
> med et problem med hensyn til den matematiske syntax. Jeg har lavet den
> så den følger standard-prioriteterne, men nu er mit problem dog lidt mere
> grovkornet, for de matematik-programmer jeg har testet med er ikke helt
> enige med mig i hvad udtrykket "2^3^4" skal give.. Wolframs Mathematica
> evaluerer det nemlig som "2^(3^4)", og får så "2417851639229258349412352",
> hvorimod mit program evaluerer det som "(2^3)^4", og derfor får "4096"...
>
> Men hvad er rigtigt?
>
> Lige nu arbejder jeg ud fra en model der hedder at operatorer har
> følgende prioriteter, plus og minus 3, gange og division 2 og
> potensopløftning 1. Det jeg så gør er at jeg deler et udtryk op i en
> liste af udtryk, separeret af den vigtigste operator der står udenfor
> paranteser i udtrykket... så jeg deler "23+34*2+34" ned til "23",
> "34*2" og "34"... derefter gør jeg så det samme på "34*2" osv...
>
> Er der nogen generelle fejl i den model? Den gør jo at 2^3^4 f.eks. ikke
> bliver evalueret "rigtigt" (ifølge Mathematica selvfølgelig)... Men er
> det et særtilfælde, eller bør jeg lave det helt om?
>
> På forhånd tak.
>
> --
> Ulrik Jensen
> ulrik@qcom.dk - http://www.minefilm.tk
> "It's only a movie, and, after all, we're all grossly overpaid."

---

LR skrev:

> Jeg tror, at 2^3^4 = 4096 er det mest udbredte

Python er enig med Mathematica:

#v+

>>> 2**3**4
2417851639229258349412352L
>>>

#v-


// Klaus

--
><>    vandag, môre, altyd saam

---

Klaus Alexander Seistrup wrote:

> LR skrev:
>
>> Jeg tror, at 2^3^4 = 4096 er det mest udbredte
>
> Python er enig med Mathematica:

bc er enig med både Python og Mathematica:

2^3^4
2417851639229258349412352

-Claus

---

TI-grafregnerne (i hvert fald 83+) er enige med Visual Basic om at 2^3^4 =
4096.

Lasse




"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ar6c11$k0m$3@sunsite.dk...
> Klaus Alexander Seistrup wrote:
>
> > LR skrev:
> >
> >> Jeg tror, at 2^3^4 = 4096 er det mest udbredte
> >
> > Python er enig med Mathematica:
>
> bc er enig med både Python og Mathematica:
>
> 2^3^4
> 2417851639229258349412352
>
> -Claus
>

---

"LR" wrote
> TI-grafregnerne (i hvert fald 83+) er enige med Visual Basic om at 2^3^4 =
> 4096.
>
Min TI-89 er ikke enig...
2^3^4 = 2417851639229258349412352

---

Jonas Jalling skrev:

>Min TI-89 er ikke enig...
>2^3^4 = 2417851639229258349412352

Min er heller ikke. Den skriver endda selv 2^(3^4) på skærmen.

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

---

"LR" <lar@tdcadsl.dk> wrote in message news:ar6jv5$6rd$1@sunsite.dk...
> TI-grafregnerne (i hvert fald 83+) er enige med Visual Basic om at 2^3^4 =
> 4096.

Det samme med HP48SX. HP32S kan ikke indtastes på den måde...


--
Med venlig hilsen/best regards
Jesper G. Poulsen

---

On Sat, 16 Nov 2002 22:06:52 +0100, Claus Rasmussen
<clr@cc-consult.dk> wrote:

>Klaus Alexander Seistrup wrote:
>
>> LR skrev:
>>
>>> Jeg tror, at 2^3^4 = 4096 er det mest udbredte
>>
>> Python er enig med Mathematica:
>
>bc er enig med både Python og Mathematica:
>
>2^3^4
>2417851639229258349412352

Matlab siger:

$ >> 2^3^4
$
$ ans =
$
$ 4096

Det samme gør Excel og MS Visual Basic (ikke at jeg tillægger hvad M$
mener i denne sammenhæng den store betydning).

Tom

--
Faber quisque fortunae suae.
- Appius Claudius

---

Claus Rasmussen skrev:

>>> Jeg tror, at 2^3^4 = 4096 er det mest udbredte
>>
>> Python er enig med Mathematica:
>
> bc er enig med både Python og Mathematica:
>
> 2^3^4
> 2417851639229258349412352

Calc er enig med både Python og Mathematica:

#v+

> 2^3^4
2417851639229258349412352
>

#v-


// Klaus

¹) <http://www.isthe.com/chongo/tech/comp/calc/>
& <http://packages.debian.org/apcalc>
--
><>    vandag, môre, altyd saam

---

Scripsit "LR" <lar@tdcadsl.dk>

> Jeg tror, at 2^3^4 = 4096 er det mest udbredte (left-to-right order).

Det tror jeg ikke. ^ skulle gerne virke i analogi med løftede
eksponenter i trykt og håndskrevet matematik, og der er

c
b
a

altid notation for a^(b^c). Den alternative betydning (a^b)^c kan
nemlig enklere noteres som a^(bc), så medmindre man ligefrem er ved at
forklare potensregneregler har man sjældent brug for at skrive
(a^b)^c. Derfor er det fornuftigt at a^(b^c) - som der af og til *er*
god grund til at skrive - er det der kan noteres uden parenteser.

--
Henning Makholm "... popping pussies into pies
Wouldn't do in my shop
just the thought of it's enough to make you sick
and I'm telling you them pussy cats is quick ..."

---

"Ulrik Jensen" <ulrik@qcom.dk> skrev i en meddelelse
news:uk7jdirxt.fsf@qcom.dk...
> Hej
>
> Jeg er lige i øjeblikket ved at lave en matematisk evaluator, og sidder
> med et problem med hensyn til den matematiske syntax. Jeg har lavet den
> så den følger standard-prioriteterne, men nu er mit problem dog lidt mere
> grovkornet, for de matematik-programmer jeg har testet med er ikke helt
> enige med mig i hvad udtrykket "2^3^4" skal give.. Wolframs Mathematica
> evaluerer det nemlig som "2^(3^4)", og får så "2417851639229258349412352",
> hvorimod mit program evaluerer det som "(2^3)^4", og derfor får "4096"...
>
> Men hvad er rigtigt?

[XFUT dk.edb.programmering]

Jeg foreslår en fejlmeddelelse. Sådan noget i stil med "Så brug da
parenteser for helvede, det andet der kan de lærde skændes om i
timevis."

I øvrigt har Mathematica "ret": Potensopløftning er normalt
højreassociativ.

Men det hjælper jo ikke brugeren, der skrev "2^10^20" og forventede at
det terminerede i hans levetid.

>
> Lige nu arbejder jeg ud fra en model der hedder at operatorer har
> følgende prioriteter, plus og minus 3, gange og division 2 og
> potensopløftning 1. Det jeg så gør er at jeg deler et udtryk op i en
> liste af udtryk, separeret af den vigtigste operator der står udenfor
> paranteser i udtrykket... så jeg deler "23+34*2+34" ned til "23",
> "34*2" og "34"... derefter gør jeg så det samme på "34*2" osv...
>
> Er der nogen generelle fejl i den model?

Det skal sikkert nok virke, omend en recursive-descent parser nok
havde været nemmere.

- Anders

---

"Anders J. Munch" <andersjm@inbound.dk> writes:

> [XFUT dk.edb.programmering]

Well, lige nu snakker vi jo primært de matematiske regler, så jeg vil
mene det hører til i dk.videnskab....

> Jeg foreslår en fejlmeddelelse. Sådan noget i stil med "Så brug da
> parenteser for helvede, det andet der kan de lærde skændes om i
> timevis."

Det er nu ligemeget, det er mest for at vide hvad der er den /rigtige/
måde at gøre det på.

> Det skal sikkert nok virke, omend en recursive-descent parser nok
> havde været nemmere.

Den er skam rekursiv, men hvis et udtryk har flere led deler den leddene
op og kører rekursivt på hvert af dem....

--
Ulrik Jensen
ulrik@qcom.dk - http://www.minefilm.tk
"It's only a movie, and, after all, we're all grossly overpaid."

---

"Anders J. Munch" wrote:
>
> Jeg foreslår en fejlmeddelelse. Sådan noget i stil med "Så brug da
> parenteser for helvede, det andet der kan de lærde skændes om i
> timevis."

Enig.

>
> I øvrigt har Mathematica "ret": Potensopløftning er normalt
> højreassociativ.

Enig.

>
> Men det hjælper jo ikke brugeren, der skrev "2^10^20" og forventede at
> det terminerede i hans levetid.

Jeg prøver lige med bc:

2^10^20
Runtime error (func=(main), adr=13): exponent too large in raise
(2^10)^20
1606938044258990275541962092341162602522202993782792835301376

De terminerede begge i min levetid (regnetiden var forsvindende).

--
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)

---

Jeppe Stig Nielsen <mail@jeppesn.dk> writes:

> Jeg prøver lige med bc:
>
> 2^10^20
> Runtime error (func=(main), adr=13): exponent too large in raise
> (2^10)^20
> 1606938044258990275541962092341162602522202993782792835301376
>
> De terminerede begge i min levetid (regnetiden var forsvindende).

Da min evaluator bruger ANSI C math-lib'et, og jeg endnu ikke har sørget
for at den ikke bliver kaldt med værdier den ikke kan klare, er det den
der i dette tilfælde står for fejlmeddelelsen.

Udtrykket: "2^(10^20)" giver:
pow: OVERFLOW error
Resultat: +INF

Se der var da noget jeg ikke vidste :]

--
Ulrik Jensen
ulrik@qcom.dk - http://www.minefilm.tk
"It's only a movie, and, after all, we're all grossly overpaid."