«Eksamenskalkulatoren» HP30S

Merk: Denne siden representerer ikke NTNUs (eller Institutt for matematiske fags) offisielle sysnpunkter. Innholdet står undertegnede personlig for. Jeg laget siden i håp om at noen kunne finne den nyttig.

Fra og med høsten 2001 er HP30S (bildet) eneste tillatte kalkulator ved de fleste eksamener ved NTNU. Dette er kontroversielt - både prinsippet og valget av denne spesielle kalkulatoren - men hensikten med denne websiden er ikke å komme med noe innlegg i denne debatten. I stedet vil jeg holde meg til noenlunde objektive fakta: Hva oppfattes som styrker og svakheter ved kalkulatoren, hvilke feil har den, og hvordan kan den utnyttes mest mulig effektivt?

HP har en egen hjemmeside for kalkulatoren.

Noen kan kanskje ha litt moro av en aprilspøk jeg laget kort tid etter at det nye kalkulatorreglementet kom.

Hvis du har synspunkter på innholdet i denne siden, mer informasjon eller nyttige tips, hører jeg gjerne fra deg. Send meg en mail (se kontaktinformasjon helt nederst på siden). Jeg forbeholder meg retten til å være litt kresen med hensyn til hva jeg tar med, både for å holde siden noenlunde kort og informativ, og for å begrense arbeidsmengden med vedlikeholdet.

Ergonomi og (fysisk) kvalitet

Generelt er jo dette en billig kalkulator, og det synes på mange måter.

Noen finner displayet vanskelig å lese. Som LCD-display flest er det avhengig av god belysning, og det skal helst ses fra riktig vinkel. Mange savner selvsagt enhver mulighet for grafikk. Displayet har bare to linjer, en for inndata og en for utdata. Dette gjør det vanskelig å holde oversikten når man taster inn en formel av mer enn triviell størrelse.

Noen synes teksten på tastene er vanskelig å lese. Jeg synes ikke det selv, men det er klart at det at den er skråstilt gjør den mindre lettlest. Teksten over tastene er noe mindre, og adskillig mindre lesbare, enn på tastene.

Noen klager over at kalkulatoren ikke ligger støtt på underlaget, og vipper på en irriterende måte når man taster på den. På den kalkulatoren jeg har, stemmer dette når lokket er satt på bakpå kalkulatoren, men om man legger lokket til side og har kalkulatoren rett på bordet ligger den forholdsvis støtt. Men den sklir lett omkring på bordet under bruk. Noen gummiføtter ville nok ha hjulpet.

Men det aller største problemet er piltastene. Det er jo ikke fire separate taster, men en stor tast som gir opp, ned, høyre og venstre avhengig av hvor man trykker. Det er veldig fort gjort å få opp eller ned når man prøver å trykke høyre eller venstre. Hvis dette skjer mens man redigerer en formel, mister man hele formelen og må starte på nytt. Etter mitt syn er dette en alvorlig designfeil.

Feil og problemer

Feil i brøkregning

Merk: Jeg har fått vite at ikke alle kalkulatorer har denne feilen. Så langt ser det ut til at kalkulatorer med versjonsnummer CN0029 eller CN0039 har feilen, mens de med nummer CN0043 har den ikke. (Nummeret bakpå kalkulatoren ser ut til å være et slags versjonsnummer.)

Jeg er blitt fortalt at det går an å få byttet in kalkulatorer med denne feilen hos Tapir.

Først litt bakgrunn: Tasten merket a^b/_c brukes til å lage rasjonale tall (heltallsbrøker): For eksempel om man trykker 3, denne tasten, og 4, får man brøken 3/4, uttrykt som eksakt brøk og ikke som desimaltall 0.75. (Man kan konvertere til desimaltall med tasten rett under: 2nd etterfulgt av F<>D. Denne tasten konverterer faktisk begge veier.)

Feilen er lett å demonstrere: Prøver man å taste inn brøken 1/110 får man 0/1, som er nokså presis 100% feil. Det ser faktisk ikke ut til at kalkulatoren kan uttrykke brøken 1/110 på noen måte. For eksempel vil 1/22-2/55 (regnet som brøker) også gi 0. Etter litt eksperimentering har jeg kommet til at kalkulatoren tilsynelatende gjør om enhver brøk m/n, der n er et multiplum av 110, og der m/n ikke er større enn 1/110, til 0/1. Dette skjer for eksempel med 1/550, 2/550, 3/550, 4/550 og 5/550, men ikke med 6/550. Det vil si, dette er ikke helt sant det heller, for 11/1100 blir 1/100, men 10/1100 blir null.

Mangel på presisjon

Den gamle hjemmesiden for kalkulatoren påsto for kalkulatoren sier den regner med 24 siffer internt. Men hvorfor gir da regnestykket ln(10*10^(-1)) svaret -1.387778781×10^-17? Men dette har de rettet siden: spesifikasjonen sier nå 15 siffer, og dét virker mer i overensstemmelse med sannheten.

Teksten i de neste tre avsnittene var skrevet i 2001, lenge før jeg så denne endringen i HP's sider (i november 2005). Jeg lar den stå uendret inntil videre.

Du ville kanskje forvente at svaret skulle være null, men nå skal du huske på at 10^(-1) ganske sikkert regnes ut ved hjelp av formelen x^y=exp(ylnx) eller noe tilsvarende, og dette gir alltid en liten avrundingsfeil. Men om kalkulatoren regnet med 24 siffer skulle du forvente et svar som ikke er så mye større enn 10^-24. Det svaret vi får, er altså en faktor 10⁷ ganger for stort.

Vi kan få litt mer informasjon ut av dette resultatet. Jeg gjetter på at kalkulatoren bruker totallsystemet til interne beregninger. 24 desimale siffer svarer til 80 bits (binære siffer), siden 24×ln(10)/ln(2)=79.726... Men 1.387778781×10^-17=2^-56 som for meg i hvert fall er en indikasjon på at min gjetning om bruk av totallsystemet er riktig, og kalkulatoren bare oppnår 56 bits nøyaktighet internt, i hvert fall i denne spesielle beregningen.

Nå skal jeg skynde meg å legge til at 56 bit, eller 17 desimale siffer, ganske sikkert er mer enn tilstrekkelig nøyaktighet for de fleste tekniske og vitenskapelige beregninger, så dette problemet er nok ikke så stort.

Tips

Jeg forutsetter at leseren selv har behersket den mest grunnleggende funksjonaliteten på kalkulatoren, inklusive bruken av de få navngitte variablene som finnes. Men husk at et uttrykk som involverer andre variabler bare kan lagres i EQN! Lagrer du et slikt uttrykk i en annen variabel, blir bare uttrykkets numeriske verdi lagret.

Iterasjon

La oss for eksempel si at du vil finne kvadratroten av 2 ved Newtons metode:

Her er en enkel metode:

• Tast inn initialverdien x₀, for eksempel 1, og trykk ENTER.
• Tast inn formelen (ANS+2/ANS)/2 og trykk ENTER.
  Resultatet av første iterasjon står i displayet.
• Trykk ENTER igjen, og igjen. For hver gang kommer resultatet av neste iterasjon i displayet.

Merknad: Det går fint an å putte inn variabler i uttrykket som itereres, for eksempel (ANS+A/ANS)/2 om man vil regne ut kvadratroten av tallet i variabelen A. Men da må man lagre en verdi i A-registeret før man begynner på prosedyren ovenfor.

Delsummer av rekker, rekursjon

Den opplagte, men ineffektive måten å gjøre det på er å bruke minneknappen: Man regner ut hvert ledd i rekken og trykker M+ for hvert ledd. Til slutt trykker man MRC for å få vite summen. Hvis det krever mange knappetrykk å regne ut hvert ledd, blir dette fort tungvint, og man fristes til å lagre et uttrykk i EQN for å forenkle jobben. Men nå kommer to nye problemer inn i bildet:

• Man må jo i det minste trykke M+ for å legge et nytt ledd til summen. Men når man gjør det (eller en vilkårlig annen operasjon) mister man muligheten til simpelthen å bruke opp-pil for å gå tilbake og regne ut neste ledd ved å redigere variabelverdien(e) som inngår. Så man må hente tilbake innholdet i EQN hver gang (4 ekstra knappetrykk).
• Etter at man har brukt innholdet av EQN for å regne ut noe, virker ikke M+ på resultatet! Dette kan omgås ved å trykke ANS først (2 ekstra knappetrykk).

Etter en del fikling har jeg funnet en rimelig effektiv måte å gjøre det på. Metoden har den ulempen at du ikke får se verdien av de individuelle termene i summen, men så snart du har stilt opp alt riktig, kan du veldig raskt regne ut delsummer omtrent så langt som du vil.

For eksemplet mitt antar jeg du vil regne ut delsummer for rekken for e^x: Altså summen av xⁿ/n! for n fra 0 og oppover.

• Tast inn uttrykket ANS+A^B/B! og lagre det i EQN.
  Legg merke til at jeg brukte variabelen B for n, som jeg skal endre hver gang - mens jeg brukte A for x, som bare skal settes én gang. Det er lurt å ha den variabelen som skal endres oftest, sist i alfabetet.
  Du finner ! for fakultet i menyen som dukker opp når du trykker PRB (for probability, eller sannsynlighetsregning).
  Jeg fikk forresten feilmeldingen DOM Error da jeg gjorde dette, fordi kalkulatoren ikke bare lagrer uttrykket i EQN, men også regner det ut numerisk. Men jeg hadde 2.6 i B, og 2.6! er ikke definert. (De kunne jo brukt gammafunksjonen til å definere x! for alle x>-1, men det har de altså valgt å ikke gjøre.) Uansett er dette ikke noe problem: Tross feilmeldingen ble uttrykket lagret i EQN.
• Tast inn 0 og ENTER (0 er initialverdien for summen).
• Hent fram EQN og trykk ENTER, fyll inn x-verdien for A, og B=0. Trykk ENTER. Du har nå første delsum (ganske sikkert 1) i displayet.
• Trykk opp-pil én gang: Der står spørsmålet om verdien på B. Putt inn neste n-verdi 1, og trykk ENTER. Du har nå neste delsum i displayet.
  Gjenta dette punktet for n=2, 3, 4, ...
  Hadde du trykket opp-pilen to ganger, hadde du kommet til spørsmålet om A. Det var derfor jeg valgte å navngi variablene i denne rekkefølgen.

Fremgangsmåten kan lett tilpasses alle slags rekursjonsformler: Eksemplet er jo ikke noe annet enn rekursjonsformelen

der S_n er n-te delsum. Uttrykket i EQN er høyresiden i rekursjonsformelen med ANS for forrige verdi.