En person tänker på ett tal mellan 1 och 100, och en annan ska gissa vilket. Om den som gissar skulle gissa fel, så får han reda på om han har gissat på ett för stort eller för litet tal. Den bästa strategin för att gissa rätt på så få försök som möjligt, är att försöka diskvalificera så många tal som möjligt.
Genom att gissa på 10 och få höra att talet är för stort, är genast 91 tal diskvalificerade, och rätt svar måste vara mellan 1 och 9, men man kan lika gärna (och troligen) få höra att talet är för litet, och då är bara 10 tal (1 till 10) diskvalificerade medan 90 tal fortfarande kan vara aktuella.
Smartast är att gissa på 50. Är det fel svar, diskvalificerar det ändå fler än hälften av alla tal mellan 1 och 100, oberoende av om 50 är för stort eller inte. Skulle det vara för stort gissar man på 25, skulle det vara för litet gissar man på 75, och så vidare. Den vinnande strategin för den som gissar på ett tal är alltså att dra av hälften av talrymdens storlek och addera det till eller dra bort det ifrån senaste gissning.
Eftersom det finns en bästa strategi för den som gissar, så kommer antalet försök att hitta ett tal alltid bli detsamma för ett specifikt tal. Personen tänker på talet 50, kommer den som gissar att hitta talet på första försöket. För att mäta hur lång tid det tar att hitta ett specifikt tal, och för att slippa sitta med en vän och gissa på tal hela veckan, har jag skapat två enkla robotar.
Roboten Conny kan tänka på ett tal och be någon att gissa. Roboten Steven kan gissa på tal, och är dessutom bekant med gissningsstrategin jag beskrev ovan. Detta är Conny:
public class NumberThinkingRobot
{
private readonly ICanGuess _guesser;
private readonly int _correct;
public NumberThinkingRobot(int correct, ICanGuess guesser)
{
_correct = correct;
_guesser = guesser;
}
public void Begin()
{
var tryCount = 0;
do
{
Console.WriteLine($"Try no. {++tryCount}");
var guess = _guesser.Guess();
if (guess < _correct)
_guesser.TooSmall();
else if (guess > _correct)
_guesser.TooLarge();
else
{
Console.WriteLine("Correct!");
break;
}
} while (true);
}
}
Programmet presenteras i sin helhet sist. Så låt oss instruera Conny att det korrekta talet är 22, och instruera Steven att det högsta tillåtna talet är 100, för att sedan fösa ihop dem.
using System;
const int max = 100;
const int correct = 22;
var steven = new NumberGuessingRobot(max);
var conny = new NumberThinkingRobot(correct, steven);
conny.Begin();
Vi kan konstatera att Steven behöver ha fem försök för att hitta 22. Detta är resultatet av körningen:
Try no. 1
Guess: 50
Too large!
Try no. 2
Guess: 25
Too large!
Try no. 3
Guess: 13
Too small!
Try no. 4
Guess: 19
Too small!
Try no. 5
Guess: 22
Correct!
Så hur svåra är de olika talen mellan 1 och 100 att hitta? 50 hittas direkt och 25 och 75 hittas på två gissningar. 13, 37, 63 och 87 kräver tre gissningar. 7 19, 31, 43, 57, 69, 81 och 93 kräver fyra. För 4, 10, 16, 22, 28, 34, 40, 46, 54, 60, 66, 72, 78, 84, 90 och 96 krävs fem gissningar. Resterande sextionio tal kräver sex gissningar eller fler, vilket innebär att det i snitt tar nästan sex gissningar att hitta rätt med den bästa strategin.
Om man istället ska gissa på ett tal mellan 1 och 1000 så har vi tio gånger så många alternativ till korrekt tal, men strategin kräver bara i snitt nio gissningar. Om vi har hundra gånger så många alternativ (ett tal mellan 1 och 10.000) krävs i snitt ungefär 12 gissningar, och för att gissa ett tal mellan 1 och 100.000 krävs knappt 16 gissningar.
Här är programmet i sin helhet (C#9):
using System;
const int max = 100;
const int correct = 22;
var steven = new NumberGuessingRobot(max);
var conny = new NumberThinkingRobot(correct, steven);
conny.Begin();
public class NumberThinkingRobot
{
private readonly ICanGuess _guesser;
private readonly int _correct;
public NumberThinkingRobot(int correct, ICanGuess guesser)
{
_correct = correct;
_guesser = guesser;
}
public void Begin()
{
var tryCount = 0;
do
{
Console.WriteLine($"Try no. {++tryCount}");
var guess = _guesser.Guess();
if (guess < _correct)
_guesser.TooSmall();
else if (guess > _correct)
_guesser.TooLarge();
else
{
Console.WriteLine("Correct!");
break;
}
} while (true);
}
}
public class NumberGuessingRobot : ICanGuess
{
private readonly int _max;
private int _correct;
private double _stepSize;
public NumberGuessingRobot(int max)
{
_max = max;
_correct = _max/2;
_stepSize = _correct;
}
public int Guess()
{
Console.WriteLine($"Guess: {_correct}");
return _correct;
}
public void TooSmall()
{
Console.WriteLine("Too small!");
_stepSize /= 2.0;
_stepSize = _stepSize < 1
? 1
: _stepSize;
_correct += (int)Math.Round(_stepSize);
_correct = _correct > _max
? _max
: _correct;
}
public void TooLarge()
{
Console.WriteLine("Too large!");
_stepSize /= 2.0;
_stepSize = _stepSize < 1
? 1
: _stepSize;
_correct -= (int)Math.Round(_stepSize);
_correct = _correct < 1
? 1
: _correct;
}
}
public interface ICanGuess
{
int Guess();
void TooSmall();
void TooLarge();
}
Det finns en del olika strategier för att bevara (eller preservera) gamla Commodore 64-program för framtiden. Här presenterar jag en snabbguide för den som äger en SD2IEC och ett tomt SD-kort.
Hårdvarukrav:
Du behöver ha en C64 (eller annan 8-bitarsmaskin från Commodore, men jag antar att du har en C64), en diskdrive, en floppydisk du vill bevara (preservera), ett SD-kort att preservera floppydisken på och en SD2IEC-enhet.
Förberedelser av SD-kort (görs på din Windows-dator):
Se till att formatera kortet till FAT32. Placera ut en diskavbildning (D64-fil) innehållande DraCopy och en diskavbildning som är tom (vilket enkelt skapas med t.ex. DirMaster). Du bör nu ha ett FAT32-formaterat SD-kort med två diskavbildningar på (D64-filer).
Mata därefter in SD-kortet i din SD2IEC-enhet som är kopplad till din C64. Notera att det finns en hel drös olika varianter av SD2IEC. Vissa har en serieport för att man ska kunna koppla in en fysisk diskdrive i den, men om det saknas så går det bra att dra en sladd mellan din C64 och din diskdrive, och en sladd mellan din diskdrive och din SD2IEC-enhet.
Val av enhetsbeteckning:
Om inget annat är sagt, kommer både din SD2IEC och din diskdrive att ha enhetsbeteckning 8, vilket innebär att de inte kan användas samtidigt. Har du en SD2IEC med dipomkopplare eller en diskdrive med dipomkopplare kan du enkelt ändra så att den ena enheten har en annan enhetsbeteckning än 8. Jag valde att lägga min diskdrive (Commodore 1571) på enhet 10 och låta min SD2IEC ligga kvar på enhet 8. Se till att dina enheter har olika beteckning, och att du håller koll på vilken enhet som har vilken beteckning – i denna text kommer min enhet 8 vara SD2IEC och enhet 10 vara min diskdrive, men du måste tänka på hur du har konfigurerat hårdvaran.
Om du inte kan ändra enhetsbeteckning med dipomkopplare på någon av enheterna, får du använda ett kommando för att ändra enhetsbeteckning på din SD2IEC. Detta kommando ändrar enhetsbeteckningen från 8 till 9 (vilket jag inte gjort).
OPEN1,8,15,"U0>+CHR$(9)":CLOSE1
Men tänk på att jag har SD2IEC som 8 och min diskdrive som 10.
Därefter är det bara att leta reda på en floppydisk som du vill bevara, och stoppa in den i din diskdrive (som för mig är enhet 10). Ditt SD-kort med DraCopy och den tomma virtuella disken (som jag har valt att kalla för empty.d64) ska matas in i din SD2IEC.
Utför kopieringen:
Välj den virtuella disketten innehållande DraCopy som din diskett på enhet 8 (i mitt fall – tänk på att anpassa efter behov) genom följande kommando:
Starta rätt version av DraCopy, beroende på vilken 8-bitarsmaskin du använder. Du kan se de tillgängliga versionerna genom att skriva LOAD"$",8 följt av LIST.
Jag hämtar rätt version för mig genom att skriva LOAD"DC64",8,1 och sedan RUN.
Innan du startar DraCopy, koppla loss diskavbildningen innehållande DraCopy. (Symbolen vänsterpil finns längst uppe till vänster på tangentbordet på din C64:a.)
OPEN1,8,15,"CD:[vänsterpil]":CLOSE1
Mounta sedan tomma virtuella disk.
OPEN1,8,15,"CD:EMPTY.D64":CLOSE1
DraCopy innehåller två fönster. Det ena har titeln S[enhet], t.ex. S08, och det andra har titeln D[enhet], t.ex. D09. Du väljer vilket fönster du ska arbeta i genom att trycka på vänsterpilen, längst uppe till vänster på tangentbordet.
I det ena fönstret, tryck på F2 tills du hittar källdisken (den fysiska) eller destinationsdisken (den virtuella). Tryck sedan F1 och för att visa diskens innehåll och bekräfta att du har valt rätt.
Därefter, tryck på vänsterpilen för att byta fönster och upprepa proceduren. F2 för att välja destinationsdisken eller källdisken och F1 för att visa innehåll.
När det ena fönstret innehåller källan och det andra fönstret innehåller destinationen, tryck på vänsterpilen till dess att källan har ett S framför sig och destinationen har ett D framför sig.
Därefter utför du kopieringen genom att trycka F8.
När kopieringen är klar och du har flyttat SD-kortet tillbaka till din PC, glöm inte att ge diskavbildningen ett vettigare filnamn än EMPTY.D64.
Begränsningar:
DraCopy kan endast kopiera disketter som inte innehåller några läsfel. Om du vill bevara ett program på en diskett som innehåller fel, bör du istället använda ett kopieringsprogram som kopierar individuella filer.
Resultat:
För min del valde hag en diskett innehållande bl.a. en låt som jag vet inte har digitaliserats för, nämligen Slow Down. Diskavbildningen finns att ladda hem här.
(Låten Slow Down är samplad från gruppen Loose Ends, 1986.)
Objektorienterad design (OOD) är ofta ett bra val för att det är relativt enkelt att använda med robusta mönster att följa. Men när man programmerar tidskritiskt, som t.ex. i när man gör spel, kan det vara värt att titta på dataorienterad design (DOD).
DOD handlar om att utnyttja processorns cache. Normalt när man läser och skriver data ber man processorn att läsa och skriva från RAM-minnet. Men när så sker, antar processorn att fler läs- och skrivoperationer kommer att ske med närliggande minneadresser, och cachar således närliggande data. Man kan alltså öka prestandan i sitt program, genom att se till att data som uppdateras ofta ligger nära varandra i minnet.
Jag har en väldigt enkel dator, en liten NUC från ASUS. Jag har skrivit ett litet testprogram i C#/.NET Core 3.1 som skapar 500 rymdskepp och flyttar dessa en halv miljon enheter i sidled, både enligt OOD och DOD.
Den objektorienterade lösningen
Denna kod definierar ett rymdskepp enligt traditionell OOD:
public class Spaceship
{
public int X { get; set; }
public int Y { get; set; }
}
Följande lilla kodsnutt skapar 500 rymdskepp i en array (givet att konstanten Ships är satt till 500):
var spaceshipsOop = new Spaceship[Ships];
for (var i = 0; i < Ships; i++)
spaceshipsOop[i] = new Spaceship
{
X = 0,
Y = i
};
Och denna kod förflyttar alla 500 skepp en halv miljon enheter åt vänster (eftersom konstanten travelDistance är satt till 500 000):
for (var x = 0; x < travelDistance; x++)
for (var i = 0; i < Ships; i++)
spaceshipsOop[i].X++;
Hela kalaset kostar 194 millisekunder (3,124 sekunder i debugläge) för min lilla processor att utföra.
Den dataorienterade lösningen
I den dataorienterade lösningen vill vi försäkra oss om att data som kommer uppdateras samtidigt också finns lagrat tillsammans. Därför skulle definitionen av ett rymdskepp kunna bytas ut mot en definition av samtliga rymdskepp:
public class Spaceships
{
public int[] X { get; set; }
public int[] Y { get; set; }
}
Det innebär att koden som skapar 500 rymdskepp istället ser ut så här:
var spaceshipsDoa = new Spaceships
{
X = new int[Ships], Y = new int[Ships]
};
for (var i = 0; i < Ships; i++)
{
spaceshipsDoa.X[i] = 0;
spaceshipsDoa.Y[i] = i;
}
Och slutligen, koden som förflyttar skeppen en halv miljon enheter åt vänster, ser nu ut så här:
for (var x = 0; x < travelDistance; x++)
for (var i = 0; i < Ships; i++)
spaceshipsDoa.X[i]++;
På min enhet har processorn fått jobba i 334 millisekunder (1,419 sekunder i debug-läge) för att åstadkomma detta, vilket är en rejäl försämring, men en förbättring på mer än 50 procent i debug-läge.
Vi kan alltså konstatera att man inte har någon automatisk vinst innan man kommer upp i lite tyngre arbeten, och det är därför fördelen med DOD var så tydligt i debug-läge. I release-läge ligger break-even för min del när 500 skepp gör en resa på två miljoner enheter (ungefär 1,2 sekunder oavsett strategi), och vid fem miljoner enheter kostar OOD-lösningen 3,2 sekunder och DOD-lösningen 2,5 sekunder.
Fördelen med DOD minskar ytterligare om antalet rymdskepp som ska förflyttas minskar, men ökar om antalet rymdskepp som ska förflyttas ökar. Med 2000 rymdskepp som ska som ska förflyttas fem miljoner enheter kostar OOD-lösningen 100 sekunder och DOD-lösningen 65 sekunder, vilket är en klart märkbar förbättring. Om en skälig mängd data ska användas väldigt intensivt och prestanda är kritiskt så är DOD att föredra, men i övrigt spelar det ingen större roll
Hela källkoden (C# version 8.0, .NET Core version 3.1):
using System;
using System.Diagnostics;
namespace ConsoleApp2
{
public class Program
{
public const int Ships = 2000;
private static void Main()
{
const int travelDistance = 5000000;
var spaceshipsOop = new Spaceship[Ships];
for (var i = 0; i < Ships; i++)
spaceshipsOop[i] = new Spaceship
{
X = 0,
Y = i
};
var stopwatch = new Stopwatch();
stopwatch.Start();
for (var x = 0; x < travelDistance; x++)
for (var i = 0; i < Ships; i++)
spaceshipsOop[i].X++;
stopwatch.Stop();
Console.WriteLine($"Object oriented approach: {stopwatch.ElapsedMilliseconds}");
stopwatch.Reset();
var spaceshipsDoa = new Spaceships
{
X = new int[Ships], Y = new int[Ships]
};
for (var i = 0; i < Ships; i++)
{
spaceshipsDoa.X[i] = 0;
spaceshipsDoa.Y[i] = i;
}
stopwatch.Start();
for (var x = 0; x < travelDistance; x++)
for (var i = 0; i < Ships; i++)
spaceshipsDoa.X[i]++;
stopwatch.Stop();
Console.WriteLine($"Data oriented approach: {stopwatch.ElapsedMilliseconds}");
}
}
public class Spaceship
{
public int X { get; set; }
public int Y { get; set; }
}
public class Spaceships
{
public int[] X { get; set; }
public int[] Y { get; set; }
}
}
I afton vill jag tipsa två fenomenala podcasts. I veckans avsnitt av Stulet gods pratar Henrik Andersson och jag om Poison, John Carpenter, Ankie Bagger och Joe Walsh. Avsnittet finns här eller där podcasts finns. Dessutom vill jag verkligen slå ett slag för Generation YX där vi diskuterar allt från den finska tullen till svensk skogsporr. Ingen mindre än Aron Flam närvarar.
Ibland hör man folk uttala sig vad datorer kan göra, antingen för att beskriva hur man ser på mjukvara eller för att göra en liknelse. Nu senast hörde jag Myra Åhbeck Öhrman berätta att datorer bara gör det man säger åt dem att göra. När hon berättar varför hon inte tror att människan kommer kunna skapa artificiellt intelligent liv säger hon:
En dator kan ju bara göra precis det vi säger åt den att göra.
Det får mig att fundera hur hon resonerar. Allra närmast plåten är detta på sätt och vis sant – en maskinkodsinstruktion som utförs av en mikroprocessor har ett förutsägbar effekt – men vilken kontroll har vi egentligen över vad som sker på den nivån?
Instruktioner som ges till en dator kan komma från en mycket högre nivå. Betrakta detta BASIC-program:
FOR A=1 TO 10 PRINT A NEXT
I detta fall är Myras påstående princip sant. Denna programkod kommer att översättas till maskinkod av en kompilator, och maskinkoden kommer att matas till processorn som utför instruktionerna. I detta fall ber vi datorn att räkna till 10, och datorn utför exakt det. Vill du testa, kan du köra BASIC-kod i webbläsaren här.
Instruktioner som ges kan bero på kontext. Betrakta följande SQL-program:
SELECT CustomerName FROM Customers WHERE CustomerName LIKE "A%"
Programmet beskriver egentligen inte vad datorn ska göra, utan vad användaren vill ha gjort: Ha tillbaka namnet på alla kunder vars namn börjar på bokstaven A. Exakt vad detta kompileras ner till för instruktioner, beror på lite olika saker. Är det mycket data? Finns det många namn som börjar på A? Finns det ett index att slå i? Och så vidare. Jag som människa har förmodligen lättare överskåda strategier och möjliga val, än vilka val som kommer att göras i en given situation. Det är fortfarande människor som i ett tidigare steg har berättat om de olika strategierna för datorn, men vilka maskinkodsinstruktioner som till slut utförs av processorn för att lösa uppgiften, är inte lika självklart som i BASIC-exemplet. Vill du testa, kan du köra SQL-kod i webbläsaren här.
Och så här rullar det på, från nivå till nivå, ända till oigenkännbarhet. I några steg längre upp har vi den artificiella intelligensen som ska lösa problem åt oss, där programmeraren inte vet hur man löser problemet, och snarare skriver kod som ska leta efter samband i ett dataset. För att producera en lösning kan evolutionära algoritmer användas, och härifrån kan man antingen låta evolvera eller låta en artificiell intelligens producera kod. I framtiden kanske det är en artificiell intelligens som konstruerat den artificiella intelligens som ska producera koden, men redan idag har vi tappat kontrollen över vad som händer på själva plåten. Om gud skapade universum och sedan klev åt sidan, kan man då verkligen säga att det är guds fel att två bilar kolliderade på E4:an i torsdags, eller har han lämnat ifrån sig kommenderingen till någon annan? Att säga att datorer är fastlåsta i bara utföra instruktioner från sin husbonde, är att förneka modern datavetenskap.
JobRunner är ett klientprogram för att starta, köra och övervaka andra program, typiskt kommandon för att publicera, ladda hem, rendera bilder, texter eller XML-flöden. I version 1.2 finns möjligheten att logga körningen. Programmet (och dess källkod) finns att ladda hem här: https://github.com/Anders-H/JobRunner
Om du vill hålla dig à jour med vad som är stulet och vad som inte är det, är podcasten Stulet gods något för dig. Här avhandlar jag och Henrik Andersson (påstådda) låtstölder genom tiderna.
I det första avsnittet avhandlas Edison Lighthouse och Eiffel 64.
Vi behöver inte backa många år för att hitta forskare som anser att ett parti schack är något som kräver egenskaper som endast människan har, men idag vet vi att datorer lämpar sig ganska väl för den uppgiften. Sedan dess har tilltron till datorers framtida förmåga ökat kraftigt, kanske för att man har sett de senaste 40 årens utvecklingshastighet, från persondatorns födelse till dagens mobila superdatorer i fickformat som ständigt är uppkopplade till enorma datorfarmar som de matar med data, som sedan används i olika mycket sofistikerade analyser. Dagens serverhallar förvaltar och analyserar inte bara data som samlas in från användares datorer och mobiltelefoner, utan även publika dataset som produceras av t.ex. statliga myndigheter och andra kommersiella dataset som skapas av olika branscher. Och när man tittar på vad som kan åstadkommas med data, förstår man varför data är dagens hårdvaluta. Väldigt mycket kan man experimentera med hemma på sin egen dator, utan att det behöva kosta något. Det finns gott om öppna dataset, som t.ex. väderdata från SMHI, brottsstatistik från BRÅ eller befolkningsstatistik från SCB. Själva intelligensen kan sedan erhållas antingen från t.ex. Microsofts publika programmeringsgränssnitt, Cognitive Services, eller TensorFlow som har öppen källkod. Sen finns kommersiella AI-produkter (artificiell intelligens) man också kan köra på sin egen utrustning, som t.ex. Machine Learning Services för Microsoft SQL Server. Idag kommer nästan alla programmerare i kontakt med någon eller flera av dessa.
Artificiell intelligens kan innefatta en hel del olika ting, och för den vanliga programmeraren handlar det oftast om att förstå strukturerat data. Strukturerat data är data som har en formellt beskriven struktur, typiskt en tabell, XML eller JSON. Ostrukturerat data är t.ex. svensk text, ljud, bild eller video. Jag har ingen erfarenhet av att jobba med att tolka ostrukturerat data, men jag visar här hur man kommer igång och leker på egen hand. Det första steget för en självkörande bil är att strukturera det ostrukturerade data som samlas in visa bilens sensorer. Idag har en självkörande bil ungefär dubbelt så många incidenter per hundratusen körtimmar jämfört med en manuellt framförd bil, men även om utvecklingen går fort framåt är det viktigt att tänka på att vissa saker som är enkelt för en människa är svårt för en dator, och vissa saker som är enkelt för en dator är svårt för en människa.
En riktigt intressant hantering av ostrukturerat data är deep dreaming, där datorn kan fylla i med information som skulle kunna vara rimlig. Tänk dig en övervakningskamera med en mycket lågupplöst bild på en inbrottstjuv, som i förstoring rent av ser pixlad ut. Med deep dreaming kan man ersätta pixlarna med en högupplöst bild. Problemet är bara att resultatet förmodligen inte är en högupplöst bild på den som faktiskt fastnat på filmen, utan ett exempel på hur personen som var där skulle ha kunnat se ut, men utan mer data så vet vi egentligen inte. Ett sätt att mäta kvalitén på vad datorn drömmer ihop skulle kunna vara följande: Man kan mata datorn med ett filmklipp föreställande strutsar som springer på ett fält, och begära ut ett filmklipp som visar hur det skulle ha sett ut om det inte vore strutsar som sprang på fältet, utan giraffer. Därefter matar man datorn med det nya klippet på giraffer, och begär ut ett filmklipp som visar hur det skulle ha sett ut om det istället vore strutsar. Därefter kan man titta på skillnaderna mellan de filmade strutsarna (ursprungsklippet) och de framdrömda strutsarna. Att låta datorn fundera ut hur det skulle se ut om en skådespelare istället vore t.ex. en känd politiker kallas för deep fake, vilket du också kan laborera med hemma på kammaren tack vare Python-scriptet DeepFaceLab.
Men med god tillgång till formellt strukturerat data (och en kraftfull dator med snabb processor, stora och snabba hårddiskar och massor av RAM-minne) är det ganska enkelt att se in i framtiden. Låt säga att man har data över låntagare, och frågan är om nästa potentiella låntagare kommer att ha råd med sitt önskade lån. Varje låntagare är en post som håller kolumner med data om ekonomi, tidigare anmärkningar, och framför allt, om lånet som togs var framgångsrikt eller om det genererade en ny missad inbetalning. Machine learning handlar om att låta datorn räkna ut vilka kolumner och vilka värden i dessa som är utmärkande för kunder som klarar av att betala tillbaka sitt lån, och vilka kolumner och värden som är utmärkande för kunder som misslyckas. En skicklig ekonom klarar detta, men en dator som inte kan ett smack om ekonomi skulle i teorin kunna klara det ännu bättre, för en dator kan ta in så oerhört många exempel och söka efter mönster i datamängder som en riktig (mänsklig) ekonom inte skulle kunna behandla på en livstid, än mindre få en överblick över.
Datorer gör såklart fel. Låt säga att en ny kund ser ut att passa in i kategorin av kunder som kommer att sköta sitt nya lån, och inte gör det, så bidrar den kunden till att samma misstag inte begås igen. Ibland måste man till och med medvetet tala om att vissa parametrar ska viktas lite mer eller lite mindre, men generellt sett ger mer data mer kött på benen för nästa förutsägelse. En intressant detalj är att datorn inte behöver bry sig om huruvida korrelationer är kausala eller ej, för fungerar sambanden för att göra förutsägelser, så fungerar sambanden för att göra förutsägelser. Potentiellt sett odlas det alltså en hel del stereotyper ute i våra serverhallar.
När vinner kompetens över AI? När datamängden inte beskriver alla potentiella situationer, eller när felaktiga antaganden har visat sig fungera under den initiala upplärningsfasen och sedan belastar framtida inlärande. En abnormitet som datorn aldrig sett kan inte datorn förutse, och om den sker för sällan kanske datorn inte klarar att förutse när den kommer att inträffa nästa gång. För datorns del är lösningen alltid mera data. Inte alltid bara det, men alltid det. Det kommer alltså säkert alltid att finnas situationer av en sådan karaktär att en akademiker, med sin jämförelsevis lilla rådatakapacitet men jämförelsevis stora hjärnkapacitet, kommer vara överlägsen, och det finns redan idag exempel där akademiker som vigt sitt liv åt att studera ett ämne, blir ifrånsprungen av en cellar dweller med computing power, som inte vet ett smack om ämnet, men som gör körningarna som krävs. Tänk hur många månaders jobb och hur mycket pengar som Lucasfilm lade på låta en ung Carrie Fisher vara med i en ny Star Wars-film, och hur mycket bättre en amatör lyckades göra samma jobb på sin hemdator på ett par timmar.
Det är förmodligen möjligt att bygga ett datorchack utan mer kunskap än själva spelreglerna. Man måste veta hur pjäserna får förflytta sig, inklusive specialdragen (uppgradering, passant, rockad), att inte egna kungen får ställas i schack och kriterierna för vinst, förlust eller möjligtvis remi (och kriterierna för remi).
Som mänsklig spelare kan man troligtvis inte analysera alla tänkbara drag speciellt långt in i framtiden (åtminstone kan inte jag göra det) utan får istället jobba med strategier som t.ex. skulle kunna vara att identifiera spelplanskonfigurationer där vissa drag tenderar att vara mer eller mindre lönsamma.
En dator som spelar mot en människa borde kunna göra en grundlig analys av spelplanen för att veta vilket drag som öppnar för ett framtida segerdrag, och tittar man på logiken bakom en sådan implementation så är den inte speciellt avancerad. Men det håller inte.
Låt säga att varje given konfiguration av schackbrädet har 40 rimliga drag. Det innebär att 40 bräden i nästa generation måste analyseras för att se vilket drag som är lönsamt eller ej. Men det ligger också i sakens natur att ett drag som inte direkt ger något, kan vara antingen förödande eller väldigt lönsamt längre fram. Så varför inte kosta på sig att titta på varje drags nästa generation?
I snitt har varje nästa generation 40 rimliga drag, vilket innebär att vi måste analysera ytterligare 40*40 (1600) drag. Men det är förmodligen inte slut där. För att hitta ljuset i tunneln behöver man troligen titta på draget därefter, där varje alternativ i sin tur har 40 rimliga konsekvenser (40 * 1600) vilket ger oss 64 000 spelplaner att analysera. Om matchen sträcker sig över tre drag måste vi titta på (64 000 * 40) 2,5 miljoner drag. Och så håller det på.
Låt oss fortsätta att anta att varje given situation i snitt bjuder 40 rimliga drag, så ger det följande effekt:
Men eftersom vi inte vet vad den mänskliga spelaren tänker göra, måste vi efter varje tänkt drag skapa en gren för varje rimligt motdrag. Så egentligen ser 10 generationer ut så här:
1 drag kräver 1 600 analyser samt ytterligare 64 000 analyser av möjliga motdrag. 2 drag kräver 2,6 miljoner analyser samt ytterligare 102 miljoner analyser av möjliga motdrag. 3 drag kräver 4 miljarder analyser samt ytterligare 164 miljarder analyser av möjliga motdrag. 4 drag kräver 6 553 miljarder analyser samt ytterligare 262 144 miljarder analyser av möjliga motdrag. 5 drag kräver 10 485 760 miljarder analyser samt ytterligare 419 430 400 miljarder analyser av möjliga motdrag. 6 drag kräver 16 777 216 biljoner analyser samt ytterligare 671 088 640 biljoner analyser av möjliga motdrag. 7 drag kräver 26 843 triljoner analyser samt ytterligare 1 073 741 triljoner analyser av möjliga motdrag. 8 drag kräver 42 949 672 triljoner analyser samt ytterligare 1 717 986 918 triljoner analyser av möjliga motdrag. 9 drag kräver 68 719 476 triljarder analyser samt ytterligare 2 748 779 kvadriljoner analyser av möjliga motdrag. 10 drag kräver 109 951 kvadriljarder analyser.
Och eftersom en analys tar några bytes att hålla i datorns arbetsminne, kan man konstatera att det fallerar av den anledningen. Processtiden även på en väldigt stark dator kommer vara ett annat problem.
Genom att lära sig strategier kan man identifiera vilka situationer man bör undvika och vilka situationer man bör premiera, och på så vis reducera antalet analyser som behöver göras. Vilka öppningar är bra? Kanske ungefär 5 över 2 generationer. Då har vi åtminstone i startsituationen reducerat från över hundra miljoner analyser till en handfull. Ju fler sådana strategier man har, desto fler nonsensanalyser skär man bort. Men frågan är hur långt man kan komma genom att slumpa vilka analyser som faktiskt ska göras? Kan ett enkelt C#-program vinna mot en seriös schackdator genom att slumpmässigt välja vilka grenar som ska analyseras på vilket djup?
Idag uppmuntrade jag en konstnär att måla en upphittad C64 i en Facebook-grupp.
Jag skrev bl.a. att jag själv lackade min Amiga på 80-talet. Det hela eskalerade ganska fort.
Ok, fel av mig. Givetvis ska man vara rädd om gamla grejer, oavsett om det bara handlar om färgen på ett chassi. Hur som helst så frågade jag vad mer man behöver för att kunna laga den ifall den går sönder.
Och vips spottar man på “vårt gemensamma kulturarv”. Jag skulle kanske ha sagt att den C64 som ligger i en container ska stanna i en container. Eller skippa näsduken nästa gång.
Det är ofta ett säkert kort inom filmindustrin att göra en uppföljare, eftersom man kan spela an på en framgång. Det blir ett slags varumärkesexploatering som inte alltid utnyttjar sin fulla potential. Ibland blir inte uppföljaren lika bra som sin föregångare, och här är tre exempel på hur budget förhåller sig till bruttointäkt i filmserier som inte lyckades följa upp sitt original. De filmer som inte når upp till 1,0 har alltså inte dragit in pengarna de kostade att producera, och här är tre exempel på “dåliga uppföljare”. Så här ser en flopp ut:
Highlander, inspelningsbudget och bruttointäkt (miljoner dollar):
Förhållande, inspelningsbudget och bruttointäkt:
Stålmannen, är en filmserie som varit igång sedan 1940-talet, men för de tidigaste filmerna är det inte riktigt känt vilka pengar som var inblandade, så här är inspelningsbudget och bruttointäkt (miljoner dollar) en bit in i serien, när Christopher Reeve klev in i serien:
Förhållande, inspelningsbudget och bruttointäkt:
Här ser vi exempel på där pengarna som står på spel varit så extremt framgångsrik i sitt ursprungsförfarande, så att jag var tvungen att introducera en decimal. Och trots att uppföljaren var en total flopp, så har den så pass stöd från sitt varumärke att siffrorna framöver varit svarta. Precis som i fallet med Stjärnornas krig, så har vi inte riktigt facit för filmserien än, för fler filmer är planerade i serien.
Alla helgons blodiga natt, inspelningsbudget och bruttointäkt (miljoner dollar):
Vissa filmer får uppföljare och spin offs till synes utan ände. Inte sällan efter en framgångsrik start, verkar bolagen vara redo att skjuta till mer pengar för att krama mer ur det varumärke som utgör en framgångsrik film. Här är pengarna som satsats och spelats in från tre kända filmserier.
Star Wars, inspelningsbudget och bruttointäkt (miljoner dollar):
Förhållande, inspelningsbudget och bruttointäkt:
Gissningsvis kommer den näst sista filmen dra in lite mer pengar över åren, och för den sista filmen finns ingen uppgift om intäkter än. Förmodligen kommer den vara mer lönsam i förhållande till vad den kostat än de två tidigare filmerna.
Terror på Elm Street, inspelningsbudget och bruttointäkt (miljoner dollar):
Förhållande, inspelningsbudget och bruttointäkt:
I den sista filmen, som är en nyinspelning av den första, är det inte Robert Englund som spelar Freddy Krueger.
The Terminator, inspelningsbudget och bruttointäkt (miljoner dollar):
Förhållande, inspelningsbudget och bruttointäkt:
Så troligen är det ett bra förhållande mellan satsade och tjänade pengar som avgör hur många uppföljare en film får.
Jag tänkte visa en komplett implementation av 2-dimensionella metabollar i C#. Denna teknik skulle även kunna användas i 3D. Effekten ser ut så här:
Effekten beskrivs här, och denna implementation prioriterar prestanda för att fungera i realtid. I videon ovan används 20 positiva bollar (alltså bollar som tenderar att smeta ihop) och 10 negativa bollar (alltså bollar som tenderar att sluka andra bollar) och samtliga rör sig i sinusbanor på en yta av 320×200 pixlar. Renderingen bygger på Windows Forms och klassen Bitmap.
För att få rörelserna mjuka har jag satt formulärets egenskap DoubleBuffered till true. Dessutom har jag placerat en Timer på formuläret och satt dess Interval till 1 för att få så bra prestanda som möjligt utan att köra dedikerat, men om man ställer ännu högre krav på användarupplevelsen, skulle man välja ett annat bibliotek än Windows Forms. Dessa inställningar har jag ställt in i Visual Studio, så de syns inte i koden.
Här är formulärets kod:
using System;
using System.Collections.Generic;
using System.Drawing;
using System.Drawing.Drawing2D;
using System.Windows.Forms;
namespace Metaballs
{
public partial class Form1 : Form
{
private IRenderer _renderer;
private Bitmap _bitmap;
private int[,] _pixels;
private double _counter = 0.0;
private readonly List<Ball> _balls = new List<Ball>();
public Form1()
{
InitializeComponent();
}
private void Form1_Shown(object sender, EventArgs e)
{
Refresh();
_renderer = new MetaRenderer();
_bitmap = new Bitmap(320, 200);
_pixels = new int[320, 200];
for (var i = 0; i < 30; i += 3)
{
_balls.Add(new Ball(MovementDescription.Randomize(), i, false));
_balls.Add(new Ball(MovementDescription.Randomize(), i + 1, false));
_balls.Add(new Ball(MovementDescription.Randomize(), i + 2, true));
}
timer1.Enabled = true;
}
private void timer1_Tick(object sender, EventArgs e)
{
//Clear array.
for (var y = 0; y < 200; y++)
for (var x = 0; x < 320; x++)
_pixels[x, y] = 0;
foreach (var ball in _balls)
_renderer.Apply(ball, _pixels);
//Draw.
_renderer.Draw(_pixels, _bitmap);
foreach (var ball in _balls)
ball.Tick(_counter);
_counter += 1.0;
Refresh();
}
private void Form1_Paint(object sender, PaintEventArgs e)
{
if (_bitmap == null)
return;
e.Graphics.InterpolationMode = InterpolationMode.NearestNeighbor;
e.Graphics.DrawImage(_bitmap, 0, 0, 640, 400);
}
}
}
De resurser som används är _renderer som ansvarar för att bestämma hur bollarna påverkar varandra och hur det ska se ut, _bitmap som är ytan jag renderar till, _pixels som är min matris för beräkningar, _counter som används för sinusbanorna och _balls som är mina metabollar. Notera att jag, likt inställningarna jag nämnde tidigare, låtit Visual Studio mappa upp mina events, så dessa syns inte i koden. Men de kan läsas av från namngivningen av procedurerna.
Som synes av den sista kodraden zoomar jag resultatet med 50%. Om man vill se resultatet i naturlig storlek behöver man inte ange InterpolationMode (efter som ingen pixelinterpolering då sker) eller någon ny storlek (640, 400).
Jag har valt att peka ut renderingen med ett interface (IRenderer) eftersom det är mycket troligt att man vill ha olika renderingskod under tiden man designar sitt alster och när man är nöjd. T.ex. är det rimligt att man tydligt vill se sina bollar flytta sig över skärmen när man kalibrerar deras banor, men när det är färdigt vill man självklart se hur de påverkar varandra, eftersom det är det som är syftet (och det som visas i videon ovan). Här är IRenderer:
En debug-implementation kanske skulle låta Apply färgsätta de individuella bollarna olika och låta Draw visa det. Däremot är en produktionsimplementation av IRenderer hjärtat i programmet. Där skulle Apply addera eller subtrahera en boll på spelplanen, och Draw skulle visa en kontur baserat på det. En boll (Ball) representerar en position och en rörelse för en boll, och för att kunna hitta tröskelvärden när två bollar är nära varandra, består dessa av en cirkel med låga värden nära konturen och höga värden nära centrum. På så vis kan en godtycklig kontur skapas från summan som skapas när bollarna adderats till ytan (eller subtraherats, för de negativa bollarna). I min implementation är varje boll 98×98 pixlar stor, varför deras centrum ligger 49 pixlar i varje riktning från sin position, vilket framgår av Apply:
using System.Drawing;
namespace Metaballs
{
public class MetaRenderer : IRenderer
{
private Color[] _colors;
public MetaRenderer()
{
_colors = new Color[100];
for (var i = 0; i < _colors.Length; i++)
_colors[i] = Color.Black;
var j = 60;
for (var c = 0; c < 255; c += 30)
{
_colors[j] = Color.FromArgb(c, c, c);
j++;
}
for (var c = 255; c >= 0; c -= 30)
{
_colors[j] = Color.FromArgb(c, c, c);
j++;
}
}
public void Apply(Ball source, int[,] target)
{
var ballX = (int)source.X - 49;
var ballY = (int)source.Y - 49;
for (var y = 0; y < 98; y++)
{
for (var x = 0; x < 98; x++)
{
var xp = ballX + x;
if (xp < 0 || xp >= 320)
continue;
var yp = ballY + y;
if (yp < 0 || yp >= 200)
continue;
if (source.Negative)
target[xp, yp] -= DataDefinitions.Ball98[x, y];
else
target[xp, yp] += DataDefinitions.Ball98[x, y];
}
}
}
public void Draw(int[,] source, Bitmap target)
{
for (var y = 0; y < 200; y++)
{
for (var x = 0; x < 320; x++)
{
target.SetPixel(x, y,
source[x, y] < _colors.Length
&& source[x, y] >= 0
? _colors[source[x, y]]
: Color.Black);
}
}
}
}
}
(Anti-aliasing-effekten uppnås av den toning som konfigureras i konstruktorn ovan.) Så här ser en boll ut:
using System;
namespace Metaballs
{
public class Ball
{
private const double CenterX = 159.0;
private const double CenterY = 99.0;
private readonly MovementDescription _d;
public double X { get; private set; }
public double Y { get; private set; }
public int Index { get; }
public bool Negative { get; }
public Ball(MovementDescription movementDescription, int index, bool negative)
{
_d = movementDescription;
Index = index;
Negative = negative;
X = 159;
Y = 99;
}
public void Tick(double counter)
{
X = CenterX + Math.Sin(counter / _d.SinFactor1) * _d.SinRadius1
+ Math.Sin(counter / _d.SinFactor2) * _d.SinRadius2;
Y = CenterY + Math.Cos(counter / _d.CosFactor1) * _d.CosRadius1
+ Math.Cos(counter / _d.CosFactor2) * _d.CosRadius2;
}
}
}
MovementDescription är en struktur som samlar data om hur sinusbanan ska se ut. Som man kunde ana från huvudprogrammet erbjuder strukturen en möjlighet att låta slumpen avgöra hastighet och radie.
using System;
namespace Metaballs
{
public struct MovementDescription
{
private static Random Rnd;
public double SinFactor1 { get; }
public double SinFactor2 { get; }
public double CosFactor1 { get; }
public double CosFactor2 { get; }
public double SinRadius1 { get; }
public double SinRadius2 { get; }
public double CosRadius1 { get; }
public double CosRadius2 { get; }
static MovementDescription()
{
Rnd = new Random();
}
public MovementDescription(
double sinFactor1,
double sinFactor2,
double cosFactor1,
double cosFactor2,
double sinRadius1,
double sinRadius2,
double cosRadius1,
double cosRadius2)
{
SinFactor1 = sinFactor1;
SinFactor2 = sinFactor2;
CosFactor1 = cosFactor1;
CosFactor2 = cosFactor2;
SinRadius1 = sinRadius1;
SinRadius2 = sinRadius2;
CosRadius1 = cosRadius1;
CosRadius2 = cosRadius2;
}
public static MovementDescription Randomize() =>
new MovementDescription(
Rnd.Next(10, 100),
Rnd.Next(10, 100),
Rnd.Next(10, 100),
Rnd.Next(10, 100),
Rnd.Next(10, 100),
Rnd.Next(10, 100),
Rnd.Next(10, 100),
Rnd.Next(10, 100)
);
}
}
Därmed är det enda som återstår själva bollen som ovan refereras till som Ball98, uppkallad efter sina sidors storlek. För att göra det enkelt, ritade jag boll genom att välja penselverktyget i Photoshop och skrev ett enkelt program som konverterade det hela till en int array i C#, enligt följande:
Sent om sidor lyckades jag installera rätt version av Windows 10 för att få ladda hem förhandsversionen av Windows Terminal, och efter att ha testat den så måste jag säga att jag å ena sidan inte har några stående ovationer att bjuda på, men måste samtidigt säga att det verkligen är hög tid att Windows fick en bra konsol-emulator.
För den som inte är varm i kläderna när det gäller grafiska användargränssnitt (GUI) av WIMP-typ så vill jag påpeka att dessa ofta behöver en konsol-emulator som erbjuder användaren att köra applikationer som inte har något passande grafiskt gränssnitt, utan en enkel kommandotolk, inte minst för att komma åt operativsystemets egna funktioner och tjänster. I Windows 10 handlar det om den gamla CMD, om den lite nyare PowerShell och sedermera även om Bash, men när helst textkommandon ska skrivas i en WIMP-miljö, behövs en konsol-emulator.
Det har funnits lite olika alternativ att välja på i Windows 10, men den enda som Microsoft har erhållit är cmd.exe, som är så pass eftersatt att möjligheten att klippa ut, kopiera och klistra in text är att betrakta som relativt ny funktionalitet. Men det är cmd.exe som använts för den som vill köra CMD, PowerShell eller Bash.
Windows Terminal verkar som sagt inte vara någon revolution (än) men är definitivt ett behövligt tillskott till Windows 10. Fönstret bjuder på ett plus-tecken där man kan öppna en ny flik med någon installerad kommandotolk (vilket endast är CMD och PowerShell om man inte lagt till någon tredjepartstolk).
Ett irritationsmoment i den här förhandsversionen är att du inte kan flytta själva fönstret genom att dra i fönstertiteln utanför PowerShell-fliken, före plus-symbolen. Det är endast området mellan plus-symbolen och minimeringsknappen som kan användas för att positionera fönstret. Det måste väl ändå vara en bugg?
Om man väljer att ändra inställningarna för Windows Terminal startar den editor du valt att använda för JSON, vilket i mitt fall (tydligen) är Visual Studio. Fördelen med att inställningarna är lagrade i INI-filer, XML-filer eller JSON-filer är att det är enkelt att redigera och förvalta dem, men nackdelen är att man får konsultera Bing (eller motsvarande) för att få reda på vad som går att göra. Men eftersom Windows Terminal installeras med stöd för CMD och PowerShell och eftersom jag titt som tätt använder Developer Command Prompt for Visual Studio (DCPVS), så tänker jag att jag vill lägga till den under plus-tecknet.
Inställningsfilen (som av någon anledning heter profiles.json) innehåller ett objekt per flik, så genom att klippa och klistra, och justera så borde man enkelt kunna lägga till DCPVS.
Trodde jag. Men på den punkten får jag inget gensvar. Min nya post visas, men kommandot jag vill exekvera, körs inte.
Det kan såklart handla om skit bakom spakarna, men om så är fallet, så behöver åtminstone jag mer tydlighet. Så för att köra DCPVS måste jag fortfarande snällt köra VsDevCmd.bat manuellt, min konfiguration till trots.
Detta projekt behövs, och jag kör som sagt en förhandsversion av Windows Terminal, men hittills är jag inte jätteimponerad.
Ibland behöver man skapa binära filer, t.ex. för att testa en egenutvecklad file header. För att göra detta kan man starta HxD och peta in de bytes man vill ha i filen. Men om man vill trycka in tal större än 255 eller textsträngar så är det en del att hålla i huvudet. Programmet MkBin bygger en binärfil efter instruktioner i en textfil.
Programmet tar två argument. Först -source som anger textfilen som beskriver binärfilen och -target som anger den binära filen som ska skrivas.
Tal som anges i textfilen antas vara bytes (8-bitarstal mellan 0 och 255), men det går att skriva in kontrollord framför för att ändra datatyp, vilket exemplet i bilden ovan visar.
Om man vill laborera med vilka texter som ger vilket binära resultat, kan man starta programmet med växeln -prompt istället för -source och -target, bara genom att skriva:
MkBin.exe -prompt
Då kan man skriva text och få direkt feedback på vad som skulle hamna i en textfil. Kontrollord som byte, short, int och long, eller 8-bit, 16-bit, 32-bit eller 64-bit anger formatet på efterföljande tal och uttryck som anges inom citat antas vara strängar med UTF-8-kodning. Exempel:
JobRunner är ett program som exekverar andra processer i turordning, vilket t.ex. är användbart för den som behandlar RSS-filer eller jobbar med genererade HTML-sidor. Mer information och nedladdningslänk finns här: https://github.com/Anders-H/JobRunner
Jag äger en nytillverkad klassisk argadmaskin som spelar Jamma-kassetter, där skärmen tyvärr gav upp. Som synes klarar arkadspelet antingen vertikala eller horisontella spel med digital styrning. Jag använder den för vertikala spel.
Det var enkelt att skruva loss den gamla skärmen och sätta den nya panelen på plats, men jag upptäckte naturligtvis lite för sent att jag satte den nya panelen 1,5 millimeter för långt till höger.
Framför skärmen sitter två glasskivor med ett motivtryckt papper emellan, för att dölja skärmens kant.
Här är glasskivorna på plats och listen som håller fast dem är fastskruvade. Här såg jag mitt lilla misstag, men beslutade mig för att skruva ihop den ändå, och justera panelens position i sidled vid ett senare tillfälle.
Så här ser spelkassetterna ut. Idag finns även nytillverkade spelkassetter med flera spel på, men typiskt innehåller kassetterna spel från Pac Man- och Galaga-eran. Så här ser den ut med Ms. Pac Man laddad:
Så nu är det bara att stoppa in en femma och köra igång!
Sprdef är en sprite-editor för Windows 10 som används vid spelutveckling för Commodore 64 med Windows som utvecklingsmiljö. Version 1.5 integrerar med CBM prg Studio, har undo/redo-buffer, fungerar i både single- och multicolor-läge och kan importera/exportera BASIC-data. Ladda hem programmet här.
A photograph usually requires 24 bits (3 bytes) per pixel. One strategy for reducing memory is to reduce the number of bits used to describe the color of each pixel, but that also reduces the number of possible colors that the format can display. A high-resolution image on the Amiga 500 typically consist of a table of 16 colors, which often is a bit too few colors for most photographic images. This is a 24-bit oroginal:
And this is the 4-bit 16-color version, that could be displayed on an Amiga:
In the 16-bit version, each pixel is a 3-byte color description, but in the 4-bit version, each pixel is a reference to a color in a 16-records long table of color. The decrease of memory consumption causes a rather obvious loss in image quality.
Hold-and-modify (HAM) allows for displaying more colors than the 16 colors stored in the table. The Amiga implementation of HAM uses a 16-color palette, and the byte array that make out the image data uses two control bits and four data bits. The control bits decide if the next four bits of the byte describes a color set (an index reference), a red modify, a green modify, or a blue modify. The last two bits per byte are not used.
So, a while a regular 16-color image uses 4 bits per pixel (a reference to a color in the table), a HAM image uses 6 bits per pixel, and if the first two is a color set, then the next four are still just a reference, like all pixels are in a regular 16-color image. But the other control bits indicate that the next four bits carries information on how the pixel color is different from the pixel to the left. It could be that it contains more red or less green, and so on, allowing up to 4096 colors to be displayed.
This method works very well on photographic images, but sharp edges may cause bleeding colors, because any pixel that is not a reference to a color table depends on its neighbor to the left. But the method works well for displaying full color images using only 6 bits per pixel instead of 3 bytes. The artifact can be observed in this classic HAM animation by Ken Offer (1987):
An image is a two-dimensional array of colored pixels, in this case 200 rows pf 320 pixels (320×200), today typically a 2-dimensional pixel array. Color indexing is the concept of replacing the 24-bit pixels with an 8-bit pointer to a color palette, thus reducing the memory required to represent the image. Character compression is the concept of replacing the pixel matrix with a matrix of references to a palette of 8×8 cells. Fewer bits per pixel results in poorer quality, but higher probability of finding similar 8×8 cells, and therefore a smaller image. More bits per pixel results in higher quality, but less probability of finding similar 8×8 cells, and therefore a larger image. The technique does not work well on photographic images. I use these original images:
1-bit (2 colors)
2-bit (4 colors)
3-bit (8 colors)
4-bit (16 colors)
5-bit (32 colors)
8-bit (256 colors)
In total, a 320×200 (64000) pixels image (8000 bytes) consist of 40×25 (1000) characters. On a blank image, only one of them are unique and needs to be stored. If the image contains just one set pixel, then the image contains two unique characters. One blank and one containing the pixel. Using character compression, the one pixel image requires 2000 bytes for the character index (1000 entries of 2 bytes each), 8 bytes for the empty character and 8 bytes for the character with a pixel. 2016 bytes in total, instead of the 8000 bytes that is required to store a 1-bit 320×200 pixel image.
The first (1-bit) image in this example contains 716 of 1000 unique characters and the 2000-byte index, meaning that the compressed images requires 716×8 + 2000 bytes (7728 bytes). Here is one example of matchig characters:
And here are all the matches highlighted:
By reducing the size of the character, you increase the likelihood to find duplicated character, but you increase the size of the character registry.
The probability of finding duplicate characters decrease when more colors are added (the 8-bit version of the image does not contain any duplicated characters) so a strategy for achieving better compression would be to allow a certain degree of mismatch. If two characters are similar to a certain degree, they can be treated as same. If the threshold for treating two characters as similar is too high, no compression will be achieved. If the threshold is too low, the image will look a bit off.
Uncompressed, the 8-bit image consumes one byte per pixel (not counting the color table of 256 colors). The pixel data requires 64000 (320×200) bytes and the color table requires 768 (256×3) bytes. If we use character compression to reduce the number of unique 8×8 pixel cells from 1000 to 500, the table (1000 entries, 2000 bytes) and 500 unique characters (32000 bytes) and the color palette (768 bytes), we would have reduced the memory required from 64768 bytes to 34768 bytes. However, the uncompressed image might be slightly distorted.
If I only look at average color of the character, these 429 cells are similar enough to be interchanged with another character:
Here is the compressed version of the image. The original 8-bit image consists of a color palette (768 bytes) and a pixel array of 64000 bytes. The compressed version consists of the same color palette, a 2000 byte character index and 571 characters, each requiring 64 bytes (36544 bytes).
Of course, the compression level should be slightly lowered for a perfect result, but there are lots of other measures that can be taken. Similarity can be defined in a more sophisticated way than a close average brightness and hue. For photographic images: The threshold for equality could be higher when the detail level is high (in this case, in the center of the image) and lower when the detail level is low. But for pixeled images, top-down-left-right-scanning is good enough. As a conclusion, this is the same image with a slightly lower compression level, still with room for the previous mentioned possible improvements:
A slightly lower compression level increases the output quality significantly, but I am convinced that a more intelligent compression engine will do an even better job.
SQLite är en mjukvara för datalagring, skriven i C, som fungerar på i princip vilken enhet som helst, från t.ex. Windows Phone till Linux. Mjukvaran är Public Domain, så företaget som utvecklar den försörjer sig istället på att sälja t.ex. support, tilläggsfunktioner eller drift.
Den utvecklare som ska bidra till den officiella produkten måste leva upp till en uppförandekod på 72 punkter som finns publicerad som en del av dokumentationen på deras hemsida (läst 2018-10-23). T.ex. får man inte mörda (punkt 3), vänsterprassla (punkt 4) eller vara stolt (punkt 34), samtidigt som man måste respektera äldre (punkt 68), älska sina fiender (punkt 31) och älska att fasta (punkt 13).
Jag kan ibland vara naiv och utgå ifrån att mina kompanjoner inte är mördare, och kan därför rentav tycka att det är lite nedlåtande att behöva be någon jag ska jobba med att skriva under på det. Och ska jag vara helt ärlig så har jag över huvudet taget svårt att vara kollega med den sortens människa som antas behöva ha en uppförandekod för att inte mörda. Men om jag kan se bortom det, så vill jag naturligtvis hellre jobba med en humanist än mördare. Så vad har fastan med saken att göra?
Det är nog ingen idé att försöka förstå, för det visar sig att SQLite utvecklas av vidskepliga idioter. T.ex. finns det ingen som bidrar till produkten som inte älskar en 2000 år gammal krigsgud från Mellanöstern (punkt 1) eller som inte ger denna övernaturliga entitet äran för sina egna insatser (punkt 42). Som mjukvaruutvecklare i behov av datalagring bör du fundera på om den som behöver denna uppförandekod, och vidare, den som lever efter denna uppförandekod, är någon som du vill ha att göra med? Över huvudet taget, på något tänkbart vis? I så fall har du problem.
Fredagen den 13/7 var jag i Kalmar för att föreläsa om religion och moral på en krogträff som anordnades av Humanisterna Kalmar. I samband med det gjordes en kort intervju där vi pratade om bl.a. Vetenskap och Folkbildning, Humanisterna, podcasts och om skepticism.
Jag ogillar verkligen att SVT använder “mannen på gatan”, men när de väl slänger kameran i ansiktet och frågar, så svarar man. Så den som tittar här, 9:30 minuter in, får veta av mig vilka nyhetskällor som är pålitliga.
Eftersom frågan kom på tal, så måste jag tillstå att jag gillar SVT och jag gillar Sveriges Radio P1. Jag vet om att de är min politiska motståndare, men jag uppskattar deras ambition att leverera objektiv och oberoende samhällsinformation.
Jag har den stora äran att spana om nakenhet i senaste avsnitt av Manspodden, vilket föder lite intressanta tankar. Klicka här för att lyssna! (Triggervarning – det blir mycket naket!)
Harter-Heighways drakkurva är en enkel och vacker linjär fraktal med många intressanta attribut. Dels är dess kontur självrepetitiv och kan pusslas ihop med lika dana konturer på många olika sätt, och linjen som kurvan består av korsar aldrig sig själv, oavsett hur lång drakkurva man väljer att rita. En drakkurva kan beskrivas som en serie av höger- och vänstersvängar. Första iterationen består av en sväng, normalt höger. Alla iterationer efter den första innehåller lika många instruktioner som den föregående, multiplicerat med två och plus 1. Alltså 1, 3, 7, 15, 31, och så vidare. Den första generationen består alltså av en högersväng (H):
H
För att skapa nästa iteration utgår man från den föregående och lägger till svängarna från den, baklänges, samtidigt som man byter ut högersvängar till vänstersvängar (V). Man avgränsar föregående iteration från den nya iterationen med en högersväng, alltså:
HHV
Tecken 1 (H) är första iterationen, nästa tecken 2 (H) är avgränsaren mellan den gamla och nya generationen, och den sista vänstersvängen (V) är vårt H från första iterationen, ersatt med ett V. Vidare, HHV baklänges blir VHH och byter man ut alla H mot V och alla V mot H så får man HVV. Då är generation tre alltså HHV, H som avgränsare och sist HVV.
HHVHHVV
Och så vidare! Nästa generation kompletteras med föregående generation baklänges, med höger ändrat till vänster och vänster ändrat till höger. Och ett H i mitten:
HHVHHVVHHHVVHVV
Ett papper kan vikas som en drakkurva, men inte i särskilt många generationer. I C# skulle man kunna använda en sådan här struktur för att beskriva ett enda steg i drakkurvan.
Egentligen behövs bara en boolesk egenskap för att hålla reda på om steget representerar en höger- eller vänstersväng, men jag vill hålla reda på var en generation börjar och slutar för att kunna rendera den med olika färger.
Här är listklassen som anropas för att bygga kurvan. Funktionen GetDragonSequence skapar en sekvens av höger och vänster-svängar i form av en lista av strukturen vi nyss såg. När man fått listan, handlar det bara om att välja en startposition och en startriktning, och sedan svänga åt höger eller vänster enligt vad som står i listan.
publicclass DragonCurveGenerator
{ publicstatic List<DragonStep> GetDragonSequence(int generations)
{ var ret = new List<DragonStep>(); if (generations <= 0) return ret; if (generations > 0)
ret.Add(new DragonStep(true)); if (generations <= 1) return ret; for (var i = 1; i < generations; i++)
{ var lastGenerationFinalIndex = ret.Count - 1;
ret.Add(new DragonStep(true, true)); for (var x = lastGenerationFinalIndex; x >= 0 ; x--)
ret.Add(new DragonStep(!ret[x].IsRightTurn));
} return ret;
}
}
Jag definierar upp de möjliga riktningarna med en enumeration, för enkelhetens skull:
publicenum Direction { Up, Right, Down, Left }
Sen är det bara en fråga om att rita kurvan, alltså följa sekvensen av svängar. Här får varje sväng representeras av en pixel. Notera att jag utnyttjar avgränsaren mellan iterationer för färgsättning.
publicclass DragonCurveRenderer
{ publicstaticvoid Draw(List<DragonStep> steps,
Graphics g, Point startPosition, Direction startDirection,
Brush color1, Brush color2, int first)
{ if (steps == null || steps.Count <= 0) return; var direction = startDirection; var x = startPosition.X; var y = startPosition.Y; var color = color1; var index = 0; foreach (var step in steps)
{ if (step.IsIterationSeparator)
{
color = color == color1 ? color2 : color1;
index++;
} if (index >= first)
g.FillRectangle(color, x, y, 1, 1);
ApplyDirection(direction, ref x, ref y); if (step.IsRightTurn)
{ if ((int) direction < 3)
direction++; else
direction = Direction.Up;
} else
{ if (direction > 0)
direction--; else
direction = Direction.Left;
}
}
} privatestaticvoid ApplyDirection(Direction direction, refint x, refint y)
{ switch (direction)
{ case Direction.Up:
y--; break; case Direction.Right:
x++; break; case Direction.Down:
y++; break; case Direction.Left:
x--; break; default: thrownew ArgumentOutOfRangeException();
}
}
}
Bilden föreställer en drakkurva på 18 generationer där generation 6 (med index 5) är den förste som ritas ut. Alltså totalt 13 fält, varannan är vit, varannan är svart. Så här kan användningen se ut (Windows Forms):
using System; using System.Collections.Generic; using System.Drawing; using System.Windows.Forms;
The Atari 2600 was a home gaming console from 1977. The 2600 was a rather primitive machine compared to the later Commodore 64 (1982), but it supported hardware sprites and color graphics, which the Sinclair ZX didn’t. But the introduction price was rather high. $199 back then corresponds to more than $800 today.
Many games were released for the 2600, but one of the most talked about, E.T., was a huge commercial failure. You play as the alien E.T. on Earth, and the objective of the game is to help E.T. get home. Every move you make costs energy, but you can pick up pieces of candy to gain energy.
First, you need to pick up three parts that make up a special phone that can be used to contact the home planet. You can swap 9 pieces of candy for a part, if you like. The parts are found in pits that you fall into, and can levitate out of. To levitate, press fire so that E.T.’s neck is stretched, and when the neck is stretched, you simply levitate higher by pushing the joystick forward.
E.T. has three lives. E.T.’s friend Elliot can bring him back to life when he dies. There is a special object that persuades Elliot to give E.T. a fourth life if it is carried. The game contains two protagonists, a scientist and an FBI agent, who can capture E.T. or steal phone parts from him. If you manage to find all three phone parts, you need to locate a place where the phone works. And after finding this place, you have to locate the place where the spaceship lands, and stay there and await the ship. If you succeed, you progress to the next level where the objective is the same, but the conditions are harder.
The game looks quite good for its time, but it is it is rather buggy and unpredictable. You can fall into a pit without any warning, and it is sometimes rather hard to get out of a pit without falling in again. The best thing about this game, is that you can chat with a friend while playing – the game does not require full attention. This video shows how to complete the first level:
26 år har passerat sedan Galenskaparna och Aftershave hade premiär med sin revy Grisen i säcken, och jag har precis sett om den versionen jag bandade på VHS i mitten av 90-talet. Revyn består av tre akter, där akt två och tre håller det format som vi är vana att se från gruppen – ett slags sofistikerat studentspex. Men det är första akten som gör denna revy speciell, och därför lämnar jag övrigt okommenterat. Den första akten är en sammanhängande musikal som gruppen själva beskriver som en dansbandsopera, viket flörtar med den för tiden populära genren rock opera, som representerades av t.ex. Pete Townshend, Savatage, Dave Clark och Styx.
Den utspelar sig 1991, vilket var året revyn hade premiär. 1991 var ett turbulent år i politiken. Ekonomin hade kraschat och stödet Socialdemokraterna var lågt. De förlorade makten till Moderaterna under Carl Bildt. Kristdemokraterna kom in i riksdagen, tillsammans med missnöjespartiet Ny Demokrati som styrdes av Ian Wachtmeister och Bert Karlsson. Det är Ny Demokratis uppgång och fall som utgör handlingen för akten – eller möjligtvis partiet Ny Deodorant som existerar i ett parallellt universum, under ledning av Rune och sedermera greven Douglas. Att Rune motsvarar Bert och Douglas motsvarar Ian är helt uppenbart för den som sett Grisen i säcken, men jag nämner det ifall du inte sett den och ändå vill förstå vad jag pratar om.
Budskapet i första akten är fortfarande aktuellt, och många händelser går att applicera på Sverigedemokraterna, men förutsättningarna är helt annorlunda. Bert och Ian (och så även Rune och Douglas) var företagsamma och mer eller mindre framgångsrika entreprenörer, medan Sverigedemokrater är frustrerade gräsrötter, helt utan tidigare erkännande i samhället de verkar i. Ny Demokrati (och även Ny Deodorant) havererade redan under första mandatperioden.
Rimligen kan inte Galenskaparna och Aftershave ha känt till hur historien om Ny Demokrati skulle sluta, när de lät sitt fiktiva parti Ny Deodorant haverera – Rune och Douglas blev tillslut programledare i tv. I valet 1994 fick Ny Demokrati 1,4 procent av väljarstödet och både Bert och Ian hoppade av. Ian fick en talkshow på TV3, “I grevens tid”, medan det gullades med Bert i Melodifestivalen – inget förlåter rasistisk politik som exploaterandet av unga artister.
När jag såg Grisen i säcken för första gången var jag V-väljare, och jag applåderade den politiska träffsäkerheten. Idag tillhör jag den politiska mitten, men tycker ändå att detta verk har åldrats väl. Jag behöver inte hålla med om allt för att förstå Claes Erikssons briljanta manus och gruppens utmärkta framförande. Men med det sagt, så delar jag förmodligen Erikssons syn på Ny Demokrati. Och kanske även på Sverigedemokraterna, men det vet jag egentligen inte.
Min första mobiltelefon var någon gammal Ericsson som både lät mig ringa (för hutlös minuttaxa) och skicka SMS. Min första handdator* var en svartvit Sony CLIÉ med Palm OS. Den virtuella upplösningen var 320 x 320 punkter, men den fysiska upplösningen var på 640 x 640 punkter, vilket innebar att den kunde återge vektorgrafik och text betydligt bättre än bitmapsbilder. Dessutom kunde den visa 16 gråskalor. Man kunde surfa på Internet genom att koppla den till sin PC:s USB-bort och ladda hem de sidor man ville läsa senare under dagen.
Idag har dessa två enheter fusionerats till en enda enhet, som i princip är en handdator med en ringfunktion**. Många har försökt, men det var Apple som lyckades göra denna nya produkt till en kommersiell succé i slutet på 00-talet. När man idag säger “mobil” eller “telefon” så menar man en handdator som har ringfunktion (som numera knappt används). Vill man förtydliga, kan man säga “smart telefon”, men idag är det nästan som att säga “platt-tv”.
Det var inte förrän Apple gav sig in i leken som handdatorn med ringfunktion blev var mans ägo, och det var inte heller förrän Apple gav sig in i leken med produkten iPad som “surfplattan” blev en kommersiellt framgångsrik produkt. Skillnaden mellan en smart telefon och en surfplatta är att surfplattan saknar ringfunktion, och är därmed alltså en handdator.
När Microsoft på allvar ger sig in i matchen med en surfplatta uppstod förvirringen på allvar. Microsofts Surface Pro saknar tangentbord, precis som iPad, och den har touchscreen precis som iPad. Men eftersom den levereras med bättre anslutningsmöjligheter till andra enheter och med ett bredare utbud av mjukvara antas den istället vara “en dator”, vilket omkullkastar allt jag hittills sagt.
För rent tekniskt, är inte en surfplatta en telefon utan ringfunktion, utan en dator. Precis på samma sätt som en smartphone faktiskt är en dator med ringfunktion. Och eftersom dessa enheter är datorer, så är det hårdvaran och operativsystemet som påverkar deras användbarhet. En iPad har ett operativsystem (IOS) som utvecklats för informationskonsumenter, som sakta rör sig mot att även kunna tillgodose producenter. En Surface Pro har ett operativsystem som utvecklats för informationsproducenter, som sakta för sig mot att även tillgodose konsumenter. Men det är fortfarande datorer!
Nu när intresset för att ringa telefonsamtal har minskat, och Nokia släppt en traditionell mobiltelefon som kostar några hundralappar, ser jag två potentiella konsekvenser. För det första tror jag att intresset för telefoni minskar bland både producenter och konsumenter av dyra handdatorer. För det andra tror jag att den som vill kunna ringa, i framtiden kommer att köpa en telefon (i ordets traditionella bemärkelse), typ en Nokia 3310.
Apples enorma framgång med iPhone kommer göra att det annalkande paradigmskiftet dröjer, men när det väl kommer, tror jag att det innebär att den lilla handdatorn tappar sin ringfunktion, men erhåller egenskaper som gör att den ersätter PC:n. När man kör Visual Studio, Cubase, SQL Server, med mera, i sin “telefon man inte kan ringa med”, så är det “telefonen” man dockar in till skärm och tangentbord på jobbet. Men det är inte den man kommer att ringa med. Om man vill ringa, så köper man en Nokia 3310.
*) En handdator är en mycket portabel dator – så pass portabel att den kan bäras i en hand när den är i drift. En handdator har tryckkänslig skärm (touchscreen) och möjlighet till batteridrift.
**) Inte ens respektabla Cambridge Dictionary innehåller en definition av ett telefonsamtal (alltså nyttjandet av en ringfunktion), utan nöjer sig med att säga att ett telefonsamtal är vad som sker när man “använder en telefon”.
MacWorld presenterar “11 klockrena argument” för att Mac är bättre än PC. Rent tekniskt är en Mac en PC från Apple, men det som menas här är att en Mac är bättre än en annan PC, som t.ex. en Microsoft Surface, en HP Elitebook eller en Chromebook. För detta levereras 11 “klockrena” argument (som alla utom det 4:e är korrekta), vars styrka och kvalité jag tänker nosa lite på, genom att jämföra dem med Microsoft.
1. Mac OS främjar hälsan
När OS X var nytt, var det extremt buggigt, men nu är det hyfsat stabilt. Det är viktigt för användarens mentala hälsa. Dessutom har inte mycket förändrats, vilket inte ställer frustrerande krav på användaren. Windows 8 såg inte alls ut som Windows 7, vilket var frustrerande. Detta stämmer! Däremot kan man inte säga att en modern Macbook är mindre kraschbenägen än t.ex. en modern Surface – idag hittar du Windows t.ex. i atomubåtar och i kärnkraftverk.
2. Ekosystem i världsklass
En Mac och en Iphone samspelar bra, men det råder inga som helst tvivel om att både Google och Microsoft har kommit längre än Apple i arbetet med att fusionera sina plattformar, men Apple är fortfarande världsklass med en hedrande tredje plats.
3. Färre val gör dig lyckligare
Få modeller ger få val, vilket ger mindre beslutsångest. Man skriver att Apple har sju datorer i produktion – fyra bärbara och tre stationära. Microsoft har sin Surface Pro i lite olika utföranden, en Surface Book och en Surface Studio, och det är väldigt tydligt vilken produkt som vänder sig till vilken användare. Om färre val gör dig lyckligare, blir man då ännu lyckligare av ännu färre val? Då vinner Microsoft över Apple, men här jämför man sig med Lenovo, HP eller Dell, som alla har ett större produktutbud.
4. Du slipper virus
Det du inte vet, mår du inte dåligt av – när säkerhet verkligen är ett krav, hittar man nästan alltid Windows eller Linux.
5. Du får grymma program på köpet
När man jämför mjukvaruutbudet på Windows Phone med IOS så vinner Apple. Jämför man Windows 10 med Mac OS så vinner Windows 10. Utbudet av kvalitativ mjukvara som antingen ingår i Windows-licensen eller finns som open source för Windows, är oslagbart. Men om färre val gör dig lyckligare, så är det Windows Phone och Mac OS som tar hem priset.
6. Du får vad du betalar för
“Vill du ha en dator som baseras på den senaste tekniken och har en elegant design är Apples datorer ett utmärkt val. Men visst, om det viktiga är en billig dator som klarar surfande och Facebook finns det bättre alternativ.” En Mac är inte speciellt prisvärd eller up to date, och ofta blir de tiotusentalskroners Facebook-maskiner.
7. Det bara fungerar
Allt fungerar out of the box, men det kan vara svårt att byta ut komponenter på egen hand. Detta är inte unikt för Apple. Jag kan t.ex. inte byta batteri på min Surface Pro, men självklart levereras en märkesdator fullt installerad, utan bloatware. Det gäller naturligtvis även Microsoft.
8. Skärmarna är fantastiska
Det råder inga tvivel om att Microsoft är stråt vassare här, men skärmarna är bra! De har dessutom touch, stöd för penna och Surface Dial.
9. Fri telefonsupport
Du kan inte ringa Microsoft hur som helst när du vill ha support, du får nöja dig med att ta det i text om det ska vara gratis. Här vinner Apple, något som du förmodligen betalar för när du köper adaptrar till överpris – there is no such thing as a free lunch.
10. Touch Bar är en innovation
Det är verkligen mer innovativt att dra och rita direkt på skärmen, men visst, detta är en innovation. Inte alla modeller har någon touch bar, dock.
11. Du kommer att bli nöjd
Om du köper en produkt som är dyr, så kommer du intala dig att du är nöjd, av psykologiska skäl. Så du kommer troligen bli nöjd, av helt fel orsak.
Min slutsats är att vi inte har att göra med “11 klockrena argument”, men väl “10 argument”.
Jag har slängt ihop två nya SID-låtar som kan avnjutas på din Commodore 64.
Den ena (the_roger_boogie.sid) är ett resultat från ett demo-jam på jobbet tillsammans med Klas Dahlén, Roger Johansson och Erik Sandberg. Den är egenkomponerad och använder en samtida playerrutin (SID 8580). Förhandsgranskning finns på YouTube.
Den andra, som är en cover på låten I Touch Myself av Divinyls, slände jag ihop igår kväll. Den körs på en rutin som är anpassad till den gamla brödburken (SID 6582).
Paul Feig lämnade nästan garantier på att rebooten av Ghostbusters skulle vara dålig. En kass trailer, en hip hop-remix av soundtracket, rasstereotyper, könsstereotyper och en provokativ damage control. Under resans gång lyckades Reddit publicera filmens synopsis och regissör Paul Feig lät hälsa att den så kallade “nördkulturen” innehåller några av planetens minst sympatiska människor.
Det sista vill jag kommentera, eftersom nördkulturen är något som ligger mig varmt om hjärtat. Jag är inte någon nörd, ens i ordets nya, positiva bemärkelse. Visst har jag fastnat lite i gamla Commodore-maskiner och Linda och Valentin-böckerna, men det jag gillar med nördkulturen är de riktiga nördarna. Och jag känner tillräckligt många för att kunna säga att man får leta på andra platser om man verkligen vill hitta några av planetens minst sympatiska människor.
Tvärt emot det intryck som trailern gav, så fungerade faktiskt många skämt. Det havererade lite när karaktären Kevin anställdes mot Abbys vilja, för att både Erin och Jillian hade mindre professionella motiv att vilja anställa honom. Den situationen hade kanske varit ännu värre om spökligan vore män som anställde en kvinna.
Trots att filmen hade högre budget än originalet, var specialeffekterna märkbart sämre. Personkemin mellan spökjägarna fungerade sisådär, men var och en var de jättebra. Regin var undermålig, vilket är det absolut bästa man kan förvänta sig av Feig.
En av de viktigaste orsakerna till att den nya Ghostbusters-filmen inte behöll samma spökliga som vi såg på bio 1984, är naturligtvis Harold Ramis bortgång. Men vi fick faktiskt se resten av gänget, Bill Murray, Ernie Hudson och Dan Aykroyd, skymta förbi. Förmodligen under tvång, med tanke på filmens rykte. Jag klickade på 6 av 10 på IMDb, och bidrog därmed till att (i skrivande stund) höja filmens snitt.
Denna bloggpost är ett resultat av mitt första försök att skapa en plattformsoberoende app med Visual Studio 2015 och Cordova, som pratar med ett Web API.
När man väljer att skapa en Cordova-app i Visual Studio, får man med lite kod som man kanske inte vill ha med när man testar lite själv. Jag valde att rensa innehållet i den div vars klass heter “app”, helt tömma CSS-filen från innehåll, och rensa upp allt utom “pause” och “resume” från index.js.
Därefter installerade jag jQuery och jQuery Mobile. Här finns det två saker att tänka på. För det första passar inte nödvändigtvis den senaste jQuery Mobile ihop med den senaste jQuery. Efter en googling kunde jag konstatera att version 1.4.5 av jQuery Mobile fungerar med version 2.1.4 av jQuery, så dessa installerade jag.
Det andra att ha i åtanke är att script-filerna installeras i mapparna Scripts respektive Content. Men i en Cordova-app ska dessa ligga under www/scripts respektive www/css, så man måste manuellt flytta dem dit, genom att dra och släppa i Solution Explorer. Sen är det bara att inkludera i head-sektionen på index.html.
Inuti min div (“app”) placerar jag två bilder, “firstScreen” och “secondScreen”, där jag låter den första innehålla ett enkelt formulär och den andra vara dold.
Koden för att skicka innehållet i formuläret till servern, antar att jag har ett enkelt Web API igång. Om det gick bra, presenterar jag svaret på den nya sidan och visar den. Om det inte gick bra, skriver jag fail i en textbox.
Cordova-appen pekar ut en ASP.NET Web API-applikation, som är väldigt lik exempelapplikationen som man får om man väljer att skapa en sådan i Visual Studio 2015. Jag pekar på den exempelcontroller som följde med, Values. Eftersom jag gör en http-post förväntar jag mig att metoden Post ska svara. Argumentet som jag tar emot, har två properties vars namn stämmer överens med datat i formuläret: p1 och p2. Funktionen gör just inget annat än att skicka tillbaka strängen “From server!” till Cordova-appen.
