Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

RPN-kalkulatorer (RPN står for Reverse Polish Notation, se http://en.wikipedia.org/wiki/Reverse_Polish_notation) er kalkulatorer der operander (verdier) angis først og så operatorene (operasjoner), istedenfor den vanlige infix-notasjonen. For å regne ut 1 + 2 så angis altså 1 og to og så angis +, som gir resultatet 3. For å bygge videre på resultatet, angir en nye operander og operatorer, f.eks. regnes (1 + 2) * 3 ut ved å angi sekvensen 1 2 + 3 *. Implementasjonen er svært enkelt, en legger bare operandene på en stack ettersom de angis, og operatorene fjerner og bruker disse og legger resutlatet tilbake.

rpncalc1.py

Nedenfor vises en enkel Python-implementasjon, med forklaringer til høyre.

...

Kjør koden og se at det virker ved å skrive inn ulike operander og operatorer.

Vi har plantet (minst) to feil i koden: Den ene har med manglende operander å gjøre, den andre med håndteringen av minus. Prøv å se om du finner en måte å rette dem på, før du leser videre!! Du finner (et forslag til) svar i rpncalc2-eksemplet som bygger videre på dette.

Håndtering av variabler og verdier

Koden over bruker flere variabler for å holde rede på tilstanden til programmet. Den viktigste variablen er operands, som refererer til lista med operander, som utvides og minskes ved gjennomgang av løkka. I tillegg har vi de to variablene token og operand, som holder det brukeren skrev inn som henholdvis (rå)tekst (string) og og konvertert til desimaltall (float). Mens det er viktig at operands-variablen beholder sin verdi for hver runde i løkka, så er det ikke viktig at token og operand gjør det. Tvert imot, så tenker en gjerne at disse er lokale for løkka, selv om Python ikke behandler dem annerledes enn operands i så måte. I andre språk, f.eks. Java, så er det mulig å opprette (deklarere) såkalt blokk-lokale variabler.

...

PlantUML Macro
object "rpncalc1" as rpncalc1
Ved oppstart av programmet tanker vi oss at det opprettes et slags notatark, med samme navn som programmet. Fra starten er arket tomt, som vist til venstre.
PlantUML Macro
object "rpncalc1" as rpncalc1 {
	operands = []
}
Når tilordningen til operands utføres, så noteres navnet og verdien på notatarket.
PlantUML Macro
object "rpncalc1" as rpncalc1 {
	operands = []
	token = "1.0"
}

Når raw_input utføres, så blir programmet liggende og vente til brukeren har skrevet inn tekst, og denne teksten tilordnes så til token. Siden token ikke finnes, så utvides notatarket med denne variablen og tilhørende verdi.

Her antar vi at brukeren skriver inn 1.0.

PlantUML Macro
object "rpncalc1" as rpncalc1 {
	operands = []
	token = "1.0"
	operand = 1.0
}
token har nå verdien 1.0 (som tekst, altså en string) og denne lar seg konvertere til desimaltall (altså en float-verdi). Dermed blir operand-tilordningen utført for første gang, så operand får verdien 1.0.
PlantUML Macro
object "rpncalc1" as rpncalc1 {
	operands = [1.0]
	token = "1.0"
	operand = 1.0
}
På linjen deretter så legges operand til operands-lista. Her leses operands-variablen, men den endres ikke, det er det jo lista som gjør.
PlantUML Macro
object "rpncalc1" as rpncalc1 {
	token = "1.0"
	operand = 1.0
}
object "1: list" as list1 {
	1.0
}
rpncalc1 -> list1: operands

For å gjøre poenget med at det er lista som operands refererer til som endres og ikke operands selv, så kan vi tegne tilstanden litt annerledes. Lista tegnes som en egen boks med nr. (1) og type (list) med verdiene inni seg. operands-variablen tegnes som en pil med navn på, som peker til liste-boksen. En slik pil kalles gjerne en referanse.

Når operands-variablen leses, så følges pila, så det er på en måte referansen til list-boksen som er verdien til operands. Derfor er det list-boksen som endres ved kall til operands.pop() og operands.append(...) og ikke operands selv.

PlantUML Macro
object "rpncalc1" as rpncalc1 {
	token = "2.0"
	operand = 2.0
}
object "1: list" as list1 {
	1.0, 2.0
}
rpncalc1 -> list1: operands

Vi antar i andre runde av løkka at brukeren skriver inn 2.0. Siden token og operand allerede finnes, så vil disse få nye verdier. operands refererer fortsatt til samme liste, som igjen er utvidet med en ny operand.

PlantUML Macro
object "rpncalc1" as rpncalc1 {
	token = "+"
	operand = 2.0
}
object "'#'1: list" as list1 {
	3.0
}
rpncalc1 -> list1: operands

Når brukeren i tredje runde i løkka skriver inn +, så utløses ValueError-unntaket før tilordningen av operand rekker å bli utført. Og derfor endres ikke operand, kun token. operands endrer fortsatt ikke verdi, men lista den refererer til endrer seg.

Hvis en hadde utført linja operands.append(operands.pop() - operands.pop()) i små steg, så ville en sett at lista faktisk endrer seg tre ganger: Først fra [1.0, 2.0] til [1.0] når pop kalles første gang, så fra [1.0] til [] når pop kalles andre gang og så til [3.0] når svaret legges til med append.

 

  
  
  

 

rpncalc2.py

...