Bézierkurver

For nyligt kom snakken i festligt lag forbi Bézier-kurver - det kan der siges meget klogt om (som f.eks. hos wikipedia). Der kan også siges meget vrøvl, og vi var vist langt nok ude på aftenen til, at jeg gjorde det sidste. Men det var for mig anledning til at genbesøge de fascinerede kurver, og selvom det hurtigt kan udarte sig i megen matematik, så er de faktisk overraskende nemme at konstruere på papir.

Hvis man er vant til at arbejde med Bézier kurver i grafiske værktøjer, så arbejder man med 3. grads eller kubiske kurver (som har to kontrolpunkter, en til hver ende af kurven). Men lad os starte med 2. grad eller kvadratiske kurver (som kun har et kontrolpunkt):

Ideen er simpel: I den ene ende starter man med fuldt ud at være på den ene linje (fra endepunkt til kontrolpunkt), og blander man trinvist med den anden linje (fra kontrolpunkt og til det andet endepunkt) indtil man fuldtud er på den anden linje i det andet endepunkt.

Tegner man det i frihånd, så kan fint nøjes med at lade kurven tangere hjælpelinjerne, som ovenfor. Men der er tale om en parametriceret kurve, hvilket illustreres af dette andet eksempel:

Her har jeg fremhævet tangentpunktet 3/8-del inde på kurven.

En af de fine ting ved en Bézier-kurve er, at den tangerer linjen til kontrolpunktet når man kommer til endepunktet. Det er mao. nemt at få en kurve, som kan forsættes i en lodret linje, som ovenfor. Men hvad hvis man gerne vil kontrollere begge endepunkters hældning? En mulighed er selvfølgelig at sammenstykke to 2. grads kurver, så de deler et endepunkt på linjen imellem de to kontrolpunkter, som hver især giver den rette hældning for den anden ende af kurverne:

Her sidder den midt imellem de to punkter, men man kan selvfølgelig også flytte den tættere på de to reelle kontrolpunkter.

Men vi kunne også sammenblande to 2. gradskurver - hvis vi kalder endepunkterne for E1 hhv. E2 og kontrolpunkterne for K1 hhv. K2, så vil den ene kurve gå fra E1 til K2 med K1 som kontrolpunkt, og den anden gå fra K1 til E2 med K2 som kontrolpunkt.

Her er det sammenblandingen en 1/4-del inde på begge kurver, som er markeret. Den sammenblandede kurve tangerer linjen imellem de to kurvers 1/4-dels tangentpunkter, en 1/4 inde.

Dette giver en 3.grads, eller kubisk, Bézier-kurve:

Det kræver en del mere arbejde at tegne sådan en kurve (og hvis man kigger efter, kan man også se, at jeg har tegnet skævt nogle gange). Men det er bestemt muligt med en lineal og noget forholdstalsregning (eller en passer, hvis man er mere ihærdig), og den virker mindre "bulet" end ovenfor, hvor det var to 2. grads kurver, som blev stykket sammen.

Hvis man er meget ambitiøs, så kan man sammenstykke to 3. grads kurver på samme måde, som de to 2. grads kurver blev, og det får man så en 4. grads kurve ud af. Jeg overlader det som øvelse til læseren (der er eksempel på en 4. og på en 5. grads kurve på wikipedia - jeg ville bare vise, at det faktisk kan "tegnes i hånden").

NCAP for software

Det her er interessant:
A famed hacker is grading thousands of programs — and may revolutionize software in the process (theintercept.com)

Som jeg læser ideen, så svarer det lidt til Euro NCAP og deres stjerner for bilers sikkerhed, bare for software.

Euro NCAP initiativet har formået at gøre sikkerhedsmæssigt dårligt konstruerede biler usælgelige, og har fået gjort sikkerhed til et konkurrence parameter. Dets - efter min mening - største fortjeneste har været, at det har formået at hæve bundniveauet markant. Og det håber jeg også vil kunne ske for software, for det har vi brug for - og ovenstående ligner efter min mening et godt bud på, hvordan det kunne gøres.

"Stjernerne" uddeles efter statisk analyse af programmer, og kan derfor ikke sige noget om, hvorvidt det er sikkert eller gør det, som det påstår at gøre; det kan derimod påpege, om programmet er bygget på en måde, som enten ikke lever op til gængs og tidssvarende praksis, eller som øger dets sårbarhed.

Den første ting, som man kigger på, er et absolut mål, nemlig om der er brugt en nyere compiler og om dens muligheder for at øge sikkerheden er udnyttet. F.eks. om der bruges address space layout randomization (ASLR) og heap- og stack-beskyttelse. Det svarer lidt til, at man tæller airbags i biler; det er ikke noget, som man som almindelig bruger kommer til at mærke noget til (forhåbentlig!), og antallet i sig selv siger ikke noget om sikkerhedsniveauet; på den anden side, så er der vist ingen tvivl om, at airbags er nyttige og at de næppe ville have været i ret mange modeller, hvis ikke man havde talt dem.

Den anden ting, er hvor mange andre software biblioteker man bygger på. Her tænker jeg, at (i hvertfald) tre dimensioner er interessante:

1. Antal: siger noget om kompleksiteten - man bør ikke genopfinde hjulet, men hvis der er taget mange eksterne biblioteker ind, så øger det naturligt sårbarheden; det kan være en indikation for en ringe styret udviklingsprocess, hvis der er brugt unødigt mange biblioteker.
2. Alder: bruges der tidsvarende og opdaterede biblioteker, eller er det noget, som man enten er ligeglad med, eller lader forfalde?
3. Hvilke: Visse biblioteker er erkendt mere sårbare end andre, og det kan i sig selv være interessant, hvis der bygges med dårlige materialer.

Den tredje ting er nødvendigvis relativ, nemlig et mål for programmets kompleksitet: det kan f.eks. være metrikker for, om der bruges mange betingelser. Det er oplagt, at der er en vis iboende kompleksitet i alle problemstillinger og at den varierer fra problemstilling til problemstilling, men det er også lige så oplagt, at unødigt komplekse løsninger indeholder et langt større potentiale for uhensigtsmæssigt og uønsket opførsel; der er simpelthen mere, som kan gå i stykker.

Hvis det skal lykkedes at få givet 'stjerner' til software, så kræver det to ting: For det første skal det sandsynliggøres, at en dårlig score tyder på et usikker software (men ikke nødvendigvis omvendt), og det er man tilsyneladende igang med. Her håber jeg bare, at man starter forsigtigt ud, for der vil helt sikkert komme kritik - og det er nemmere at affærdige eller miskreditere noget, som er kompliceret end noget, som åbenlyst er rimeligt.

For det andet, så skal der være alternativer. Hvis ikke vi brugere kan og vil 'stemme med fødderne', så vil det bare løbe ud i ende- og nyttesløse debatter på oversete fagmedier som f.eks. Version2. Det hjælper ikke noget at teste og diskutere kollisionssikkerhed, hvis det eneste man kan købe er en Trabant, og det hjælper heller ikke, at man kan vælge hvilken-som-helst farve, hvis det i praksis skal være sort (NemID, Rejsekort m.fl., jeg kigger på jer!). Artiklen peger selv på forskelle imellem browsere, og der har vi - for det meste - stadig et reelt valg; de dage, hvor stort set alt interessant var 'optimeret til IE' er heldigvis ved at være overstået.

Til sidst et forbehold: jeg kender kun initiativet fra ovenstående kilde, og kan derfor kun udtale mig om selve ideen, som jeg forstår den - ikke om hvorvidt denne eller hin person eller firma er troværdige.