Y2k+10 bug

Knapt er vi kommet os over panikken omkring år 2000-problemet, også kendt som Y2k, der nærmest truede med verdens undergang i en sådan skala at det gør selv 2012 filmen til skamme, inden at vi rammes af en ny katastrofe; 2010 årsskiftet!

Som man kan læse i denne artikel, er Dankort systemet i ca. 1.600 P-automater i København, umiddelbart lige efter kl. 23.59 d. 31/12-2009, ophørt med at fungere til stor undren for folkene bag, og stor irritation for alle øvrige.

Det er en påstand herfra, at P-automat betalingssystemet der anvendes utvivlsomt er udviklet efter år 2000-problemet blev konstateret og løst.

Dels har det jo kørt upåklageligt da årstallet viste “00”, “01”, “02”, “03”, …, og “09”, og der ville nok først igen opstå problemer når der trilles over de “99” til “00” (lige som sidst). Desværre vippede det nye årstal ikke rundt til et “10” som man vist havde regnet med, men istedet til “0A”, der er det hexadecimale talsystems repræsentation af decimaltallet 10. Det hexadecimale talsystem er et som computere har det ret godt med – en byte omfatter 8 bits, der dækker decimaltallene 0 til 255, eller hexadecimalt 00-FF. Og så gik maskineriet i selvsving, “0A” og “10” kunne ikke sammenholdes mellem den grænseflade der er mellem betalingssystemet og yderligere systemer.

Den anden vinkel på hvorfor P-automat betalingssystem må og skal være etableret efter Y2k er at det simpelthen ville være opdaget i 1999 også; decimaltallet 99 repræsenteres som 63 hexadecimalt. Mon ikke der havde været rod i et regnskab eller to, med bogføring af indkomster fra 1963 i år 1999 uden nogen form for renteindtægt eller forudgående poster med langsigtede krediteringer?

Hvis vi tænker lidt over hvorfor man efter en så voldsom omgang skruen på kode der vedrører datoer, alligevel er kommet frem til at holde årstallet i en byte og repræsentere denne talværdi i systemet hexadecimalt både internt og eksternt, ja så er min personlige konklusion helt klar. Tanken må have været at alle da bare skal se i en fart at få lært det hexadecimale talsystem. Det er jo over 2,5 gange mere fremtidssikret med hensyn til hvornår en ny Y2K fejl opstår, vi har jo med talrummet fra 0 til 255 at gøre og ikke kun 0 til 99. Desuden vil det fjerne enhver form for enkodnings- og/eller formatteringsproblematik der måtte være en gang for alle, ved ganske enkelt blot at anvende et fælles og maskinelt nemt behandlingsbart talsystem.

Snedigt! 😉

Der er flere der er ramt af andre nye årstals problemer, blandt andet kan nævnes Windows Mobile. Her er problemet at SMS beskeder ankommer i 2010 som om de er sendt i 2016. Det skyldes samme problemstilling bare vendt på hovedet: “10” kommer ind, og behandles hexadecimalt, hvilket giver decimalværdien 16.

Alle SAP systemer er tilsyneladende også ramt af 2010 problemet, det kan man læse mere om her.

Så husk det nu: Enkodning, formattering og valg af datatyper er vigtigt.

Strukturel processering af billeder

Når billeder skal processeres programmatisk anvendes en matematisk metode der kaldes morfologiske transformationer (morphological transformations), mønster genkendelse (pattern recognition) og/eller egenskabs ekstraktion (feature extraction).

Her i juletiden har mange været påvirket af huller i asfalten langs eksempeltvist Vejle fjordbroen. Hvis vi begiver os ud i et tankeeksperiment er det med relativt simple billedbehandlingsalgoritmer “nemt” at detektere en betydelig andel af opbyggende huller og dermed kunne man forebyggende iværksætte udbedrende vejarbejde før et problem opstår.

Et eksempel kunne være anvendelse af thresholding, erosion og dilation på en stribe billeder taget af asfaltoverfladen på udvalgte vejstrækninger. For resten af denne artikel antages det, at sådanne billeder er tilgængelige.

Herunder vises en række billeder af asfaltoverflader hvor der er opstået minimale huller og sprækker, samt hvor alvorlige slaghuller forekommer og er delvist udbedrede. Ligeledes vises en normal asfalt overflade. Under hvert billede vises en morfologisk behandlet udgave, der har været underlagt den samme algoritme for samtlige billeder. Givet disse resultatbilleder er det relativt simpelt at afgøre hvorvidt et behandlet resultatbillede udgør en kandidat til manuel inspektion eller ej.

Klik på billedet for at se en stor udgave.

“Proof-of-concept” algoritmen benyttet på resultatbillederne herover er skrevet i .NET C#, og ser overordnet således ud:

Bitmap input = new Bitmap(filename);
Bitmap output =
  Dilate(
    Dilate(
      Threshold(
        Dilate(
          Dilate(
            Dilate(
              Dilate(
                Grayscale(input)
              )
            )
          )
        ), 70
      )
    )
  );

output.Save(
  Path.GetFileNameWithoutExtension(filename) +
  ".processed" + Path.GetExtension(filename));

Tankeeksperimentet skal naturligvis føres videre ud før det bliver praktisk anvendeligt.

Det er klart at der vil være tale om mange tusinde billeder og adskillige terrabytes data, hvorfor system arkitekturen bag processeringssystemet bør være baseret på en skalerbar multiserver/multikerne teknologi. Et eksempel på en gratis open-source arkitektur kunne være AMD’s Framewave eller nVidia’s CUDA.

Ligeledes vil der være særlige elementer i billederne der skal tages særlig hånd om, f.eks. vejstriber og overgange mellem forskellige belægningstyper med videre.