Dansk professor vil forbedre regneark

It-Universitetes nye professor i softwareudvikling vil gøre regneark hurtigere, gemme mellemregningerne væk i funktionsark og gøre det nemt for brugerne at definere nye funktioner.

Regneark kan gøres endnu bedre, end de er. Det mener den nyudnævnte professor i softwareudvikling ved It-Universitetet, Peter Sestoft, der også vil gøre noget ved det.

For det første har han en plan om at udvikle funktionsark til det almindeligt kendte regneark, som kan gøre det nemmere og mere overskueligt at lave mellemregninger.

Han hiver et basalt eksempel frem - beregning af arealet af trekanter. Formlen er s(s-a)(s-b)(s-c), hvor a, b og c er sidelængderne i trekanten og s er (a+b+c)/2.

Vil man lave udregningen i et normalt regneark er det nemmeste at lave en ekstra kolonne, hvor s er udregnet, men det burde kunne undgås, mener Peter Sestoft.

»Det er et typisk problem i dag, at man får forurenet sit regneark med ekstra kolonner med mellemresultater, som man egentlig ikke er interesseret i at se på,« siger han.

Den anden mulighed er at udskifte s med (a+b+c)/2 i formlen, men så får man eksempelvis denne lange formel: SQRT((A5+B5+C5)/2((A5+B5+ C5)/2-A5)((A5+B5+C5)/2-B5)*((A5+ B5+C5)/2-C5)).

»Og så har man med meget stor sandsynlighed skrevet noget forkert undervejs. Et simpelt eksempel på, at regneark savner den helt basale abstraktionsmekanisme, hvor du har et udtryk og gerne vil definere en funktion i stedet for.«

Løsningen er et funktionsark, som andre forskere også har foreslået. Det ligner et almindeligt regneark, men som har inputceller og outputceller. Her kan mellemregningerne finde sted og det endelige resultat kan så hentes over i selve regnearket.

Planen er at få studerende med på projektet og have første prototype programmeret i C# klar om et års tid. Den vil formentlig komme ud som et opensourcekomponent, som alle kan hente ned og bruge.

I første omgang vil funktionsark højst sandsynligt ikke kunne bruges med Microsoft Excel, men det kan ændre sig, hvis Office bliver bedre integreret med .Net-platformen.

Men inden det kommer så langt, skal der blandt andet arbejdes med at gøre komponenten lige så hurtig, som Excel.

»Den største udfordring er at få funktionsarket ud i en form, hvor det rent faktisk er brugbart. Men teknisk set er det spændende at få den bedst mulige performance,« siger han.

Han ser god logik i at forbedre regnearket, da det er så brugervenligt, at det gør det muligt at lave ret avanceret modellering med simpel programmering.

»Der er en hel del relativt komplekse beregningsopgaver, som slutbrugere - biologier, fysikere, aktuarer, ingeniører, revisorer - selv kan finde ud af at lave i regneark.«

Men regnearket har også sine grænser, der sætter brugerne på større opgaver end det er nødvendigt.

»Mange laver meget komplicerede løsninger, hvor de strækker regnearket til det yderste, fordi alternativet er at programmere med VisualBasic, som mange ikke forstår.«

Et klart mål med funktionsark er at det nemt for brugere at definere funktioner som mangler i gængse regneark. For eksempel kan Excel ikke beregne ISO-ugenumre, selvom halvdelen af verden bruger dem. Men også mange statistiske og finansielle funktioner kunne nemt defineres som funktionsark, og behøver så ikke være indbygget.

Næste skridt er at optimere regnearkene til det hardware, der bruges i fremtiden. De pc'er man køber har to eller fire CPU'er og snart vil de have 16 eller 32, og der er ikke særlig mange programmer, som kan udnytte det optimalt. Men i regneark sker beregningerne på en forholdsvis forudsigelig måde, så det er nemmere at udnytte alle kernerne parallelt.

»Det er et perspektiv som er meget interessant. Man kan formentlig få komplekse beregninger såsom simuleringer til at køre 20 gange hurtigere på en computer med 32 CPU'er.«

Men hvorfor lige kaste sig over regneark?

»Regneark er interessant at arbejde med, for man flytter virkelig noget for utrolig mange mennesker.«

Ud over regneark arbejder den nye professor med statisk verifikation af software. Han vil sammen med kollegaen Lars Birkedal bevise, at en ny model, der beskriver hvad et stykke software skal gøre og at det rent faktisk gør det vha. matematiske formuleringer, virker.

De to forskellige forskningsområder har vidt forskellig motivation.

»Hvis det med statisk verifikation lykkedes, har vi virkelig flyttet akademisk forskning til noget, der kan bruges industrielt, mens det med regneark mere er lavpraksis, hvilket har meget stor potentiel betydning i praksis for rigtig mange mennesker,« slutter Peter Sestoft.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Torben Mogensen Blogger

Der mangler lige et kvadratrodstegn omkring formlen s(s-a)(s-b)(s-c). Peter havde det med i sit foredrag, men det lader sig nok ikke nemt gengive i BBCode. :-)

Regneark har en del egenskaber, der gør dem interessante at forske i:

  • De er deklarative.

  • De har mulighed for parallelisering, da regnerækkefølgen ikke er specificeret.

  • De programmeres af slutbrugeren, hvilket sætter særlige krav til gennemskuelighed osv.

  • 0
  • 0
#2 Jacob Christian Munch-Andersen

Jeg ville egentlig bare gerne have mulighed for at bruge løkker, midlertidige variable og at referere til celler vha. talsæt. Dertil skal man selvfølgelig have mulighed for at gemme hele herligheden som en brugerdefineret funktion. På den måde kan man totalt erstatte behovet for makroer til avancerede funktioner.

Desværre er OpenOffice Calc udviklingsmæssigt låst til MS XL for at maksimere interoperabiliteten, så der skal nok et helt nyt produkt på banen for at få den funktionalitet.

  • 0
  • 0
#3 Jesper Kleis

Regneark er lette at gå til - men de er meget uhensigtsmæssige i videnskabelige sammenhænge, eller blot til standard dataopsamling og analyse i f.eks. gymnasiet.

Man kan selvfølgelig gå den hårde vej, og bruge statistiske pakker i stedet, men ofte er behovet blot mere overskuelighed, muligheden for at arbejde med datasæt uden at skulle lave navngivning etc.

Samtidig er f.eks. Word meget lidt egnet til videnskabelige rapporter med formler, formelreferenser etc.

Alternativet er her at skrive i latex, købe mathtype plugin'et (som har meget begrænset funktionalitet på mac) eller lignende.

Jeg så gerne et offspring af openoffice, der fokuserede på videnskabelige artikler inden for naturvidenskaben. Så i stedet for at have en masse transperante figurer etc - gav mulighed for enkel og let databehandling, let formelskrivning med referenceværktøjer og en mulighed for at implementere f.eks. formelark.

Det er alletiders hvis ovenstående også blev implementeret i MS office - men open office gruppen burde måske fokusere der var noget mere nyskabende end blot at lave et kopiprodukt.

ps: Jeg ved at der er muligheder for latex plugins etc, til open office - jeg så bare gerne at de fleste brugere havde en mulighed for en mellemvej, hvilket hurtigt ville gøre open office populær i uddannelsesøjemed.

  • 0
  • 0
#5 Jesper Kleis

Selv er jeg også Python fanatiker - og Resolver ser spændende ud. Dog har den frie version en .msi extension - og det er vist ikke rigtig noget jeg kan lege med på min mac, eller tager jeg fejl?

  • 0
  • 0
#6 Deleted User

Jeg har svært ved at se, at det at fjerne rækker og kolonner, kan gøre et regneark hurtigere - måske bliver det endog langsommere. Et felt, eller en række/kolonne, behøver ikke, at tage tid.

Normalt, vil jeg forvente, at et regneark fungerer som en compiler. Det betyder, at værdien i et felt, skrives der i binært - på samme måde, som i en variabel. Ved udskriften, omsættes så til udskriftsformen, det vil sige streng, tal nummer osv. Og tilmed, hvis der ikke er nogen ændring, så er ikke nødvendigt, at skifte teksten ud. Udskiftning af tekst, sker ikke nødvendigvis før cellerne "printes" på skærmen - sådan er det også i compilere. Det er udskriften, der omsætter til 10-tals system osv. Internt, gemmes det binært.

Hvad er så fordelen ved flere celler i regneark? Ja, en af dem er, at i modsætning til ved normale programmeringssprog, så behøver de ikke at blive genregnet ved tryk på "beregningstasten". Kun, hvis noget medfører ændring af felterne, medfører det genberegning. Dette svarer lidt til en simulator, der også kun genregner funktionen af komponenter, der påvirkes. Ændres, således et felt, i et regneark, vil ikke alle felter genudregnes - kun de felter, der påvirkes af ændringen.

Det svarer fuldstændigt, til hvordan en digital simulator virker, bortset fra, at compileringen af felter, kan ske styk for styk, og en ændring i et felt, således ikke behøver genkompilering af et regneark. Ændring, af et felts værdi, behøver hellerikke compilering, men en ny beregning, vil medføre at regnearkets felter, som påvirkes af denne ændring, udregnes.

Med andre ord, er det om at gemme så mange værdier som muligt, i kolonner, fordi at det er stor sandsynlighed for at en ændring af værdier, ikke påvirker feltet. Og derfor, vil den medføre besparelse i udregningstid. Selvom, den skulle medføre ændring i værdien, så bliver det ikke nødvendigvis langsommere af den grund. Felter, der "hænger sammen" sættes sammen, så det svarer til et program automatisk. Dette svarer til, at man analyserer flow grafen, for regnearket, og udregner hvilke "processer" det skal deles op i, og så aktiverer disse processer. Er det felter, som hver gang opdateres, vil de stå under samme process, og der bruges ikke nødvendigvis tid på eventhåndteringen. Andet, end et jump, kan være nødvendigt, for at gøre regnearket fleksibelt (når felt udskiftes).

Umiddelbart, kan jeg ikke se at hastigheden for regneark kan øges betydeligt umiddelbart - det eneste, som kan gøres, er at give ekstra funktionalitet.

  • 0
  • 0
#7 Martin Otzen

Et problem med regneark er at de er blevet til en sweitzerkniv (er det stavet sådan?), utroligt mange bruger dem til simple teksttabeller.

Men der hvor jeg bliver træt er når de bruges til at vise grafer over funktioner, egentlig burde det ikke være så svært at tilpasse dem til dette, at en datasamling absolut skal placeres i en række celler, og demed fylde visuelt alt for meget i regnearket er trælst, det ville være rart om man kunne lave en simpel databeholder der så kunne refereres til, så behøver man heller ikke kopoiere sin formel ud i det antal datapunkter man ønsker til sin graf.

Men en rigtig rigtig stor forbedring ville være om regnearket lærte bare lidt af matematik programmer som fks mathcad, at man i et moderne regne program i nutidens computere skal slås med streng baserede formeludtryk er utroligt, hvor meget vil det kræve at inføre en formel editor i regnearket? At forfatteren i følge TM har en fejl i artiklens formel viser jo at den måde at skriver formler på er uoverskuelig for menesker.

  • 0
  • 0
#8 Claus Agerskov

I OpenOffice.org

Man vælger hver enkelt af de celler på Ark1 som skal være siderne og trykker CTRL+F3, skriver bogstavet (a, b eller c) og vælger OK.

På Ark2 vælges en celle til s, som navngives på samme måde. I feltet skrives =(a+b+c)/2

Nedenunden navngives en celle og i denne skrives =KVROD((s(s-a)(s-b)*(s-c)).

Tilbage i Ark1 vælges en celle til resultat og heri skrives blot =areal.

Hvis det er en engelsk udgave erstattes Ark med Sheet og KVROD med SQRT.

Jeg tror, noget tilsvarende kan gøres i andre regnearksapplikationer.

De herligste hilsner Claus Agerskov

  • 0
  • 0
#11 Peter Sestoft

Jens Madsen skrev "Umiddelbart, kan jeg ikke se at hastigheden for regneark kan øges betydeligt umiddelbart - det eneste, som kan gøres, er at give ekstra funktionalitet."

Det med hastigheden har kun en indirekte sammenhæng med funktionsark; at mindske eller øge antallet af kolonner har ingen effekt, som du siger. Og det er klart at man kan behøver genberegne nogle af formelcellerne når en datacelle ændres. Men det er ikke klart hvordan man administrerer sådan sparsommelig genberegning på den mest effektive måde. Lidt mere af historien kan læses i http://www.itu.dk/people/sestoft/corecalc/ITU-TR-2006-91.pdf, især kapitel 4. Men denne tekniske rapport er to år gammel og der er sket en del siden.

  • 0
  • 0
#12 Deleted User

Det med hastigheden har kun en indirekte sammenhæng med funktionsark; at mindske eller øge antallet af kolonner har ingen effekt, som du siger. Og det er klart at man kan behøver genberegne nogle af formelcellerne når en datacelle ændres. Men det er ikke klart hvordan man administrerer sådan sparsommelig genberegning på den mest effektive måde. Lidt mere af historien kan læses i http://www.itu.dk/people/sestoft/corecalc/ITU-TR-2006-91.pdf især kapitel 4. Men denne tekniske rapport er to år gammel og der er sket en del siden.

Jeg har ikke noget at tilføje.

Det er faktisk en god rapport.

Du har skrevet programmet i C# - dette er også ok. Sandsynligvis, kan opnås lidt ekstra, ved at oversætte til maskinkode, og du har også nævnt muligheden for at bruge flere CPU'er.

  • 0
  • 0
#13 Nikolaj Brinch Jørgensen

Hej Peter,

Godt initiativ, jeg vil gerne foreslå lidt forbedringer (måske har du allerede tænkt på dem?).

Flere dimensioner. 2 er ikke nok, det er alt for legacy RDBMS agtigt. Implicit valutaomregning, det kunne jeg godt bruge. Nemmere referencer mellem sheets. Muligheden for at arbejde i 2 eller flere sheets på skærmen samtidigt, især nu hvor de fleste har wide screen displays. Større fleksibilitet for at genbruge data (tal/tekster) uden brug af copyright paste, men ved hjælp af definition.

  • 0
  • 0
#14 Erik Jacobsen

For mange år siden læste jeg om en undersøgelse, der påviste at regneark med udregninger meget ofte indeholdt fejl, og at fejlene i disse regneark var svære at finde.

Jeg tror ikke det har ændret sig, og det er bekymrende at tænke på at verden styres af økonomers udregninger i netop regneark.

Den forbedring jeg savner i regneark, er muligheden for at gøre beregningerne testbare - unit-test, og dokumenterbare - kommentarer.

  • 0
  • 0
Log ind eller Opret konto for at kommentere