JobRunner 1.5

JobRunner är ett program som exekverar sekvenser av program. Det kan t.ex. användas av den som regelbundet genererar filer lokalt på datorn, som ska skickas upp till en server. I version 1.5 finns stöd i användargränssnittet för att arbeta med variabler. Om du vill modifiera vilka steg som ska exekveras, måste JobRunner startas som administratör. Mer information finns här.


Ladda hem JobRunner för Windows 10/11: JobRunner.exe (högerklicka, välj Spara som…)

Disabling loading turbo to make C64 programs work on the TheC64

On a TheC64, you would normally load a program from a disk image rather than a physical disk. If the program consists of a single file, everything is usually fine. But if several files make up the program you want to load, a custom loader is usually involved, and the built in TheC64 turbo will make the program unloadable.


TheC64 solves this problem by looking at the ending characters in the name of the active disk image. The first disk image in my copy of the Comaland 100% demo is not called image1.d64 but image1_adro.d64. The presence of the characters “ad” tells the TheC64 to inactivate the built-in disk turbo, that makes most multipart software fail during load. The presence of the characters “ro” tells TheC64 that the disk is read-only, which makes most abandonedware work.


The manual describes all of the character combinations that the TheC64 understand. You can control joystick ports, among other things. As a TheC64 user, you should make it a habit to add “ad” before the file ending in the image that holds your programs, and “_adro” to the end of any image you download from the C-64 Scene Database.

The new self-contained Hand class

I have added a new class to my poker formation checker (now on .NET 6.0, not 5.0). The library still mainly works with string representations of decks, hands and cards, and the Hand class can be initialized from a string.

// Create a hand from a string:
using Winsoft.Gaming.GenericPokerFormationChecker;
const string handString = "FORMATION=3-OF-A-KIND,SCORE=0333,HAND=CLB04-DMN06-HRTKN*-DMNKN*-SPDKN*";
var hand = new Hand();
hand.Parse(handString);
Console.WriteLine(hand.Formation); // Output: ThreeOfAKind

But the Hand class can also be initialized using regular function calls.

// Create a hand using the API:
using Winsoft.Gaming.GenericPokerFormationChecker;
var hand = new Hand();
hand.Add(Suit.Spades, Value.Ace);
hand.Add(Suit.Clubs, Value.Ace);
hand.Add(Suit.Diamonds, Value.Ace);
hand.Add(Suit.Hearts, Value.Ace);
hand.Add(Suit.Spades, Value.Value06);
Console.WriteLine(hand.Formation); // FourOfAKind

Also, the Hand class is self contained. You can any time prompt what formation and score it represents, and what cards are included in the formation. If the hand doesn’t have a formation, the InFormation property will point out the highest card.

// Create a hand using the API:
using Winsoft.Gaming.GenericPokerFormationChecker;
var hand = new Hand();
hand.Add(Suit.Hearts, Value.Value10);
hand.Add(Suit.Clubs, Value.Queen);
hand.Add(Suit.Spades, Value.Ace);
hand.Add(Suit.Diamonds, Value.Value03);
hand.Add(Suit.Spades, Value.Value06);
Console.WriteLine(hand[0]!.InFormation); // false
Console.WriteLine(hand[1]!.InFormation); // false
Console.WriteLine(hand[2]!.InFormation); // true
Console.WriteLine(hand[3]!.InFormation); // false
Console.WriteLine(hand[4]!.InFormation); // false

The old API has not changed. Install:

Install-Package PokerFormationChecker

Source code is here, NuGet package is here.

Rita en cirkel på Commodore 64

Det finns ett meme som visar hur omständligt det är att programmera BASIC på Commodore 64 (C64). Bilden visar den kod som krävs för att rita en cirkel på skärmen på en C64, jämfört med den kod som krävs för att rita en cirkel på skärmen på Sinclair Spectrum.

Om du skummar igenom koden i bilderna, så noterar du säkert två saker: C64-versionen är onödigt pratig och Spectrum-versionen lider lite av att skärmupplösningen är aningen lägre än C64-versionen (256*192 pixlar jämfört med 320*200 pixlar).

Denna kod är galet långsam, men det är det kortaste jag har lyckats åstadkomma för att rita en cirkel på C64:

10 POKE 56,32:POKE 52,32
20 CLR:POKE 53272,25
30 POKE 53265,PEEK(53265) OR 32
40 PRINT "{CLEAR}"
50 POKE 88,0:POKE 89,63
60 POKE 113,64:POKE 114,31
70 POKE 12,1:SYS 45760
80 FOR A=1 TO 7.3 STEP 0.01
90 X=COS(A)*20
100 Y=SIN(A)*22
110 XX=159+4*X:YY=99+3*Y
120 ROW=INT(YY/8):CH=INT(XX/8)
130 LINE=YY AND 7:BIT=7-(XX AND 7)
140 BYTE=8192+ROW*320+CH*8+LINE
150 POKE BYTE,PEEK(BYTE) OR 2^BIT
160 NEXT
170 GOTO 170

Detta är resultatet:

Jag skulle tro att orsaken till denna skillnad är att C64 egentligen är en spelkonsol, utklädd till dator. C64 var vid lansering utrustad med extra allt inom ljud och grafik, och för att spara minne slängde man in en äldre version av Commodore BASIC, nämligen 2.0 (second release). Samma som VIC-20, men ett par versioner lägre än den PET. Den enda anledningen till att C64 faktiskt hade en BASIC och ett tangentbord var att man behövde ett säljargument, som tyvärr inte är mer sofistikerat än Annika Strandhälls försvar för iPads i skolan – man blir ett datageni! En skillnad är möjligtvis att det var lägre hängande frukt att lära sig programmering på en hemdator 1982 än det är att lära sig programmering på en kontemporär Facebook-maskin från Apple. Sinclair Spectrum (också 1982) däremot, var en ytterst begränsad dator. Att de barn som fick den skulle lära sig programmering, var på allvar ett viktigt skäl att köpa datorn. Den behövde ha en seriös BASIC! (Jag själv lärde mig BASIC på föregångaren Sinclair ZX81.)

Commodore 128 hade all den kapacitet ljud- och grafikkapacitet som C64 hade, men till skillnad från C64 hade den även kommandon och verktyg som lät användaren dra nytta av den kapaciteten, utan att behöva programmera maskinkod. 128-användaren fick tillgång till en bra BASIC och en drös inbyggda verktyg. Programmet som ritar en cirkel på Commodore 128 är inte helt olikt Spectrum-programmet i memen ovan:

10 GRAPHIC 1,1
20 CIRCLE 1,159,99,60,60

Och även om vi inte hade CIRCLE-kommandot, så blir koden betydligt kortare än C64-versionen, eftersom vi kan ändra grafikläge och sätta individuella bildelement direkt från BASIC. Så uppgiften är inte särskilt svår ändå. Man betalar för lyxen genom högre minneskrav, men denna lyx ansåg man inte att målgruppen för C64 var intresserad av.

FileUtility PathInfo

FileUtility är ett bibliotek för Windows/.NET 6.0 som (för närvarande) innehåller en enda klass: PathInfo. Den kan bl.a. korta ner en filsökväg för presentation på skärmen och ange fil- och katalogstorlek i flera format, inklusive ett människovänligt textformat. Exempelkod finns här.

var max = 15;
var f = new PathInfo(new FileInfo(@"C:\Temp\hello.txt"));
Console.WriteLine(f.CompactPathForDisplay(15))

// Result: C:...\hello.txt

Min första kontakt med ChatGPT

Jag har knuffat min första kontakt med chatboten ChatGPT fram till idag. Orsaken till min prokrastinering är enkel tidsbrist, men idag kom jag mig för att testa ett kort replikskifte, vilket onekligen gav mig mersmak.

Jag:

Can you give me five reasons to not believe in God?

Chat GPT:

There is no one answer to this question, as beliefs about God are deeply personal and can vary greatly from person to person. Some people may not believe in God for a variety of reasons, including:

1. Lack of evidence: Some people may not believe in God because they do not see any concrete evidence of God’s existence.

2. Personal experiences: Some people may not believe in God because of their personal experiences or the experiences of others.

3. Different beliefs: Some people may not believe in God because they hold different beliefs or have been exposed to different religious teachings.

4. The existence of evil: Some people may not believe in God because they cannot reconcile the existence of evil in the world with the idea of an all-powerful, all-loving God.

5. A desire for autonomy: Some people may not believe in God because they value their autonomy and do not want to be beholden to a higher power.

Again, these are just a few examples of reasons someone may not believe in God. It is important to remember that beliefs about God are highly personal and can vary greatly from person to person.

Jag:

Has humans evolved or are they created?

Chat GPT:

The question of whether humans have evolved or were created is a contentious one, and different people may have different beliefs on the matter. From a scientific perspective, the evidence overwhelmingly supports the idea that humans have evolved over time. The theory of evolution is supported by a vast body of scientific evidence, including fossil records, comparative anatomy, and DNA analysis.

According to the theory of evolution, all living things, including humans, have descended from a common ancestor through a process of natural selection. Over time, small variations in the genetic makeup of organisms can lead to the development of new traits and characteristics. These changes can be passed down from one generation to the next, allowing species to adapt to their environments and ultimately giving rise to the diversity of life we see today.

While the theory of evolution is widely accepted by the scientific community, some people may believe in alternative theories, such as the idea that humans were created by God. These beliefs are often based on religious or spiritual beliefs, and are not necessarily supported by scientific evidence. Ultimately, the question of whether humans have evolved or were created is a complex one, and different people may have different beliefs on the matter.

Jag:

Are you created or have you evolved?

Chat GPT:

As a large language model trained by OpenAI, I do not have the capacity for consciousness or the ability to evolve. I am a purely digital entity, created by humans to process and generate text based on the data I have been trained on. I do not have the ability to experience or perceive the world in the same way that humans do. I am not a living being and do not have the same capabilities or limitations as living organisms. I exist solely as a tool to assist with generating text.

Vi har en spännande tid framför oss.

Tre timmar om Pink Floyds 70-tal

För Nongratas räkning har Jannik Svensson och jag spelat in tre avsnitt om Pink Floyd och deras musik. Vi börjar med deras debut 1967 och landar i The Wall från 1979.

https://poddtoppen.se/podcast/1463215688/samtal/den-stora-pink-floyd-specialen-del-1

https://poddtoppen.se/podcast/1463215688/samtal/den-stora-pink-floyd-specialen-del-2

https://poddtoppen.se/podcast/1463215688/samtal/den-stora-pink-floyd-specialen-del-3

Mycket nöje!

JobRunner 1.4

Version 1.4 av JobRunner finns nu att ladda hem. Programmet låter dig lista upp processer som ska utföras i turordning som kan beläggas med vissa enkla villkor. Startas programmet som administratör kan dessa steg redigeras, annars kan de bara köras.

Den senaste versionen innehåller några mindre buggrättningar och introducerar möjligheten att manuellt stoppa en körning.

https://github.com/Anders-H/JobRunner

Vad är vinsten att skriva i maskinkod?

För ett par veckor sedan skrev jag en kort text om hur man optimerar prestandan i Commodore BASIC 2.0 second release. Det gjorde att jag fick frågan om hur mycket man tjänar på att programmera maskinkod istället för BASIC. I mitt exempel drog jag ner exekveringstiden från 1522 jiffys (sextiondels sekunder) till 686 jiffys, genom att välja rätt kommandon och rätt strategi i en konstruerad uppgift: Spara tre värden i tre olika minnesadresser, 1000 gånger.

Uppgiften var att låta en VIC-20 skriva värdet 40 till adress 828, värdet 41 till adress 829 och värdet 42 till adress 830, ett tusen gånger, vilket alltså går att göra på 686 jiffys. Strategin för god prestanda måste utgå ifrån att realtidstolkning tar tid. Men så fick jag frågan om hur lång tid det tar för en VIC-20 att lösa samma uppgift om man skriver programmet i maskinkod. Jag gissade på nolltid, men rätt svar är 2 jiffys, alltså en trettiondels sekund.

Hur ser ett program, enligt ovan, konverterat till maskinkod ut? Stegenser ut som följer:

  1. Initiera variabeln som håller räkning på antal körningar. Detta kräver två bytes, eftersom 1000 är ett 16-bitarstal, medan VIC-20 är en 8-bitarsdator.
  2. Utför uppgiften i fråga. Skriv tre värden till tre minnesadresser.
  3. Räkna upp variabeln.
  4. Upprepa om uppgiften körts färre gånger än 1000.
  5. Avsluta.

Jag väljer att lagra variabeln på adress 880-881 och lägga programmet på adress 831. På det viset ryms programmet mellan de tre adresser som är föremål för uppgiften (828-830) och variabeln som håller reda på antalet upprepningar (1000 stycken) på adress 880-881.

1. Assembler-koden för att initiera variabeln som håller räkning på antal körningar ser ut så här (adress 831):

LDA #0
STA 880
LDA #0
STA 881

2. Uppgiften är att skriva värdet 40 till adress 828, värdet 41 till adress 829 och värdet 42 till adress 830 (adress 841):

LDA #40
STA 828
LDA #41
STA 829
LDA #42
STA 830

3. Därefter ska variabeln som håller reda på antal skrivningar till minnet räknas upp (adress 856):

INC 880
BNE 864 ;(som är adressen till beslutet att iterera)
INC 881

4. Om uppgiften utförts färre än 1000 gånger, ska uppgiften upprepas (adress 864):

LDA  880
CMP  #232
BNE  841
LDA  881
CMP  #3
BNE  841

5. Avsluta.

RTS

Översatt till maskinkod, kan vi konstatera att vi har:

  1. 169 0 141 112 3 169 141 113 3
  2. 169 40 141 60 3 169 41 169 41 141 61 3 169 42 141 62 3
  3. 238 112 3 208 3 238 113 3
  4. 173 112 3 201 232 208 226 173 113 3 201 3 208 189
  5. 96

Om vi skriver en BASIC-loader för detta, och sedan tar tid på exekveringen, så ser koden ut så här:

10 FOR N=0 TO 47
20 READ V
30 POKE 831+N,V
40 NEXT
50 S=TI
60 SYS 831
70 PRINT TI-S
80 DATA 169,0,141,112,3,169,0,141
90 DATA 113,3,169,40,141,60,3,169
100 DATA 41,141,61,3,169,42,141,62
110 DATA 3,238,112,3,208,3,238,113
120 DATA 3,173,112,3,201,232,208,226
130 DATA 173,113,3,201,3,208,219,96

Och mycket riktigt har vi nu utfört samma uppgift på 2 jiffys istället för 686 jiffys. Maskinkod är alltså inte så lite snabbare än BASIC på VIC-20.

Prestanda i Commodore BASIC 2.0 second release

Om du skriver ett program i Commodore BASIC för C64 (Commodore 64) eller (som i mitt fall) VIC-20 är prestanda viktigt, speciellt om det är ett spelprogram som du bygger. BASIC-tolken är ganska slö, och det faktum att både C64 och VIC-20 interpreterar BASIC-programmet medan det körs, gör att det är vissa specifika faktorer som man behöver ta hänsyn till.

Två faktorer som påverkar prestandan ganska mycket – hur man skriver minne och hur man itererar – är två faktorer som ofta används vid just spelprogrammering. Men även om du blir expert på BASIC, kommer du inte kunna skriva spel som är lika avancerade som t.ex. Wizball, The Great Giana Sisters eller Turrican i BASIC, men du kommer kunna skapa hyfsat bra spel. T.ex. är Pirates! programmerat i BASIC (Sid Meier), precis som Artworks Strip Poker, så man kommer ganska långt om man lär sig språket ordentligt.

Jag kör mina prestandaexempel på min VIC-20. En VIC-20 är aningen snabbare än en C64, ändå är allt som påstås här sant även på C64 även om siffrorna blir lite annorlunda.

För att mäta prestanda kan man spara värdet i TIME ( eller TI) som ger systemklockans värde, utföra den operation man vill mäta, och sedan titta på differensen mellan det nya värdet i TIME och det värde man lagrade. Då vet man hur många jiffys (alltså hur många sextiondels sekunder) operationen har kostat.

Följande program skriver till fyra minnesadresser i en evighetsloop. Programmet räknar dessutom upp en variabel till 1000 och bryter när den når 1000. Det vi testar är hur snabb en iteration är, hur lång tid det tar att skriva till minnet med POKE, en aritmetisk beräkning och ett test. Så här ser källkoden ut:

10 PRINT "HASTIGHETSTEST VIC-20"
20 S=TI
30 C=0
40 POKE 828,40
50 POKE 829,41
60 POKE 830,42
70 C=C+1
80 IF C < 1000 THEN 40
90 PRINT TI-S

Resultatet, som bilden visar är 1522 jiffys (eller drygt 25 sekunder). Koden ser inte helt orimlig ut, men det är inte särskilt imponerande, så hur kan man optimera detta program?

Först är GOTO felanvänt. GOTO står inte utskrivet, men rad 80 avslutas med …THEN 40, vilket underförstått betyder …THEN GOTO 40. Syftet med GOTO är att skapa hopp i program för att förgrena logiken. Under vissa villkor ska viss kod köras, annars en annan kod. Men här används GOTO för att iterera. Det faktum att Commodore BASIC är ett interpreterande språk gör detta till ett dåligt val. Varje gång programmet ska hoppa till ett radnummer, måste radnumret tolkas och hittas. Genom att skapa iterationer med FOR, kan iterationens start och slut återanvändas under varje upprepning.

10 PRINT "HASTIGHETSTEST VIC-20"
20 S=TI
30 FOR A=0 TO 999
40 POKE 828,40
50 POKE 829,41
60 POKE 830,42
70 NEXT
80 PRINT TI-S

Nu klarar vi att utföra samma logik på 1094 jiffys (18 sekunder). Ännu trevligare blir det om vi använder oss av variabler för att lagra minnesadresser. Då behöver interpretatorn bara förstå vilken adress som avses en gång, och kan sedan återanvända det. Här kräver vi två aritmetiska beräkningar för att åstadkomma sak, men är redan nere på 835 jiffys:

Och kostar vi på oss att använda tre variabler istället för en variabel och två aritmetiska beräkningar, så hyvlar vi bort ytterligare lite overhead och landar på 686 jiffys.

10 PRINT "HASTIGHETSTEST VIC-20"
20 S=TI
30 X=828
40 Y=829
50 Z=830
60 FOR A=0 TO 999
70 POKE X,40
80 POKE Y,41
90 POKE Z,42
100 NEXT
110 PRINT TI-S

Nu har vi gått från 25 sekunder till 12 sekunder, vilket är en femtiotvåprocentig förbättring. I praktiken kan man inte optimera programmen så hårt, för man skulle få alldeles för många variabler att hålla reda på. Men när man skriver prestandakritiska program (t.ex. spelprogram) i ett långsamt språk (t.ex. Commodore BASIC) är det viktigt att veta vad man kan göra och vad man absolut ska undvika.

Jag har skrivit en bok om just Commodore BASIC på C64 och VIC-20, som bl.a. tar upp detta, som kan laddas hem helt gratis som PDF eller EPUB.

Uppdatering: Vad är vinsten att skriva i maskinkod?

Avstånd mellan uppföljare och deras betyg

Hur tätt släpps filmers uppföljare? Och hur populära är de? Jag har tittat på några trilogier, tetralogier och några filmserier med fler än fyra filmer. Trilogier:

Tetralogier:

Och några filmserier med fem eller flera delar:

Så hur har dessa tagits emot? Det är kanske den mest viktiga informationen för den som vill avgöra om det är värt att köpa biljett till nästa film i serien. Så här populära är filmerna i trilogierna, viktat mot övriga delar i serien:

Det verkar som att både Göta kanal och Exorcisten är särskilt populära i sin första del jämfört med uppföljarna. Så här ser populariteten ut för tetralogier:

The Crow och Highlander verkar ha lidit en hel del av att ha uppföljare, medan både Toy Story och Alien verkar ha klarat det ganska bra. Så här ser det ut för långkörarserierna:

Om man tittar på samtliga filmer ovan, hur mycket betyget har förändrats från första till andra delen, kan vi konstatera att några filmer, inte minst Ster trek, Mad Max och Terminator har en del två som är bättre än del ett, medan uppföljaren till Exorcisten var en besvikelse för publiken.

Hur får man bra ljud i en podcast?

Podcastproduktion sker i flera steg. Man ska rigga utrustning, göra en soundcheck, spela in podcasten, klippa den, montera och mastra den och publicera den. Jag har redigerat ljud i vågformseditorer sedan tidigt 1990-tal och poddat sedan 00-talet. Jag har bl.a. varit inblandad i produktionen av Skeptikerpodden, Radio Bulletin, Stulet gods, Radio Houdi, Generation YX och Samtal. I och med att jag sysslat en del med montering och mastring, och får ibland frågan om jag kan bistå. På grund av arbetsbelastning så tackar jag alltid nej, men det är inte speciellt svårt att göra en mastring på egen hand.

För att resultatet ska bli riktigt bra, måste inspelningen ha gjorts korrekt. Inspelningsvolymen får inte vara för låg, för då kan man få problem med brus. Inspelningsvolymen får absolut inte vara för hög (“clipping” – ej att förväxla med klippning), för då blir vågformen helt enkelt förstörd. Mikrofonerna bör vara någorlunda bra, och helst vill man inte ha mikrofonen för nära munnen eller andas direkt in i mikrofonen. Har man ingen bra inspelningsstudio så finns det risk att mikrofonen plockar upp rumseko och att ljudet därför blir lite burkigt. Många brukar lösa detta genom att sänka inspelningsvolymen och prata närmre mikrofonen. Det fungerar, men det introducerar ett annat problem, nämligen att ljudet låter onaturligt, som om någon pratar rätt in i ditt öra. Utan tillgång till professionell utrustning får man göra vad man kan.

Tänk också på att använda puffskydd (vissa säger “pop-filer” numera) för att minska risken att man skapa oljud genom att andas på mikrofonens membran.

Om fler än en person pratar i podcasten, så är det bra om dessa ligger i var sin fil under mastringen. Särskilt ljudnivåerna är bra att kunna styra individuellt.

Mastringsarbetet görs i speciella program för vågformseditering. Man arbetar alltså med redan renderade ljudfiler, direkt mot vågformen. Dessa program kan benämnas på lite olika sätt, men wave editor är ganska vedertaget. I programmet öppnar du upp det klippta råmaterialet du fått från klipparen, där varje kanal är en fil, och ditt ansvar är att:

  1. Harmoniera bitdjup och samplingsfrekvens
  2. Korrigera nivåer
  3. Eventuell brusreducering och eventuell frekvensutjämning (equalization)
  4. Montering av röstkanaler
  5. Komprimering
  6. Eventuell extra klippning
  7. Montering av signaturmelodier
  8. Slutrendering

Harmoniera bitdjup och samplingsfrekvens

Eftersom vi jobbar direkt i vågformen så får vi ingen hjälp av mjukvaran att hantera om ljudfilerna har olika bitdjup. Bitdjupet anger hur många möjliga impulsnivåer varje samplingspunkt har, och ett högre tal är bättre. 8-bit, 16-bit eller 24-bit är ganska vanligt. Professionella ljudproducenter brukar arbeta med 24-bit och leverera en slutprodukt som är 16-bit, men arbetar man med podcasts så räcker det ofta att kontrollera att ingen inblandad ljudfil är sämre än 16-bit.

När det gäller samplingsfrekvens, som anger samplingspunkternas täthet, är 44,1 KHz lämplig, men vissa inspelningsprogram kan leverera filer på 22,05 eller 48 KHz. Högre är bättre även här. Då behöver du göra en resample till 44,1 KHz, som är fullt tillräckligt för att mastra en podcast. När alla filer har samma bitdjup och samplingsfrekvens är detta steg färdigt.

Korrigera nivåer

Det är bra om samtliga medverkande har samma impulsstyrka, till den grad man kan styra det. I exemplet på bilden har vi två filer. Den ena filen innehåller en person som pratar i en mikrofon, och den andra filen innehåller två personer som delar på en mikrofon. Båda är lite för låga för att det ska vara passande, men det är lättare att göra ett bra jobb om ursprungsimpulsen är lite för låg än lite för hög.

Den ena kanalen (överst) är lite svagare än den andra, så båda behöver förstärkas, men den övre lite mer än den undre. Notera att något sticker ut mot slutet av filen. Om den biten ska vara med, bör inte volymen höjas mer än att den biten fortfarande har god marginal till impulsens maxvärde. Det kan i värsta fall vara ljud i båda kanalerna samtidigt där, och då finns det risk att clipping uppstår när filerna slås samman.

Innan jag höjt volymen tillräckligt på första kanalen, inser jag att detta kommer att slå i taket. Efter att ha zoomat in, kan jag konstatera detta är ett skratt som ska vara med i slutprodukten. För att få upp volymen till önskad nivå, måste jag manuellt först sänka volymen på det skrattet. Jag gör samma sak i båda filerna, om än lite mindre i den andra. Detta är jag nöjd med:

Eventuell brusreducering och eventuell frekvensutjämning

Det ser ut att hända en del saker, särskilt i den undre filen, mellan pratet. Är det störande ljud som måste tas bort (funktionen “mute”)? Skiljer de två filerna varandra åt i frekvensomfång? Det behöver rättas till med en equalizer. Innehåller någon fil mer toppar och dalar än den andra, eller är någon fil mer fyrkantig (kanjonisk) än någon annan? Den med många toppar och dalar kanske behöver ha lite kompressor redan i detta steg. Det är bra om filerna liknar varandra.

Montering av röstkanaler

När filerna är tillräckligt lika varandra, ska de slås samman till en fil. Den funktionen brukar heta “mix” i denna form av program. Nu ser vi första versionen av den fil som är resultatet av vårt arbete.

Komprimering

Nu vill vi att volymen ska vara jämn och stark, så att alla detaljer hörs, även när det pratas tyst, och så att inte lyssnaren får hörselskador av något häftigt skratt. Vi vill lägga kompressor på ljudet. I en vågformseditor brukar denna hantering kallas compression. Jag brukar gå fram ganska försiktigt, till en början. Är man för snål, kan det bli svårt att höra alla detaljer, och det kan komma höga överraskningar för lyssnaren. Tar man i för mycket, låter ljudet onaturligt, som om någon står mycket nära dig och pratar.

Det där höga skrattet på slutet sticker inte längre ut i ljudstyrka, utan i att den som skrattar tillfälligt låter lite “närmre” lyssnaren. Dessutom är fraser som yttrats lite försiktigt i bakgrunden, nu fullt hörbara.

Eventuell extra klippning

Det är bra att zooma in och titta igenom vågformen efter omotiverat långa pauser, eller onödigt många ticks, som t.ex. “ööhhh…” eller liknande. Ta inte bort allt, bara några stycken. Korta inte gärna ner pauser utan att säkerställa att du inte klipper i andetag, ta hellre bort någon omotiverad paus då och då.

Montering av signaturmelodier

Kontrollera att signaturmelodierna ligger strax under pratet i volymstyrka, och mixa in musiken först, sist eller var det ska ligga. Tänk på att om musik och prat ska gå in i varandra, så blir den totala ljudstyrkan högre där detta sker.

Slutrendering

För en podcast brukar man välja att rendera slutresultatet som en MP3-fil, med en bithastighet på 128 kilobit per sekund (Kbps), i 16-bitars mono. Det ger en bra kompromiss mellan filstorlek och ljudkvalitet.

När man har fått rutin på denna process brukar det inte vara mer än en halvtimmas arbete per podcastavsnitt, innan du kan lämna resultatet vidare till den som ansvarar för publicering. Lycka till!

Sprite (OpenGL i .NET Framework)

Jag har dragit nytta av ett gammalt C#-repository som wrappar OpenGL för .NET Framework för att bygga ett minimalistiskt spelramverk. Följande kod visar stjärnor som flyger över skärmen, från höger till vänster. Projektet är .NET Framework 4.8 som jag valde för att det finns inbyggt Windows 10/11.

Exemplet visar initiering av spelmotorn, att skapa sprites med GDI+, användning av en scen, tangentbordsavläsning, en sprite batch (som erbjuder fire-and-forget sprites).

Projekttypen är en console application, och referenserna är Sprite och System.Drawing. Repositoryt finns här och detta är den kompletta koden:

using System;
using System.Drawing;
using Sprite;

namespace Starfield
{
    public class Program
    {
        public static SpriteBitmap Star;
        public static GameEngine GameEngine { get; private set; }

        public static void Main()
        {
            // Create and initialize the game engine.
            GameEngine = new GameEngine("Starfield", OnLoadResources);
            GameEngine.LoadResources();

            // Run the game.
            GameEngine.Run(new StarfieldScene());
        }

        private static void OnLoadResources(object sender, EventArgs e)
        {
            // Draw a "star".
            var star = new Bitmap(2, 2);
            star.SetPixel(0, 1, Color.White);
            star.SetPixel(0, 0, Color.White);
            star.SetPixel(1, 1, Color.White);
            star.SetPixel(1, 0, Color.White);

            // Create a sprite bitmap from the star.
            Star = SpriteBitmap.FromImage(star, 1, 1);

            // Tell engine that loading is completed.
            GameEngine.SetLoadResourcesComplete();
        }
    }

    // Define the star sprite that will fly from right to left.
    public class StarSprite : BatchGameSprite
    {
        private int SpeedX { get; }

        public StarSprite(SpriteBitmap spriteBitmap, int y, int speedX) : base(spriteBitmap, 320, y, 1)
        {
            SpeedX = speedX;
        }

        public override void ApplyLogic() =>
            X += SpeedX;

        public override bool Alive() =>
            X > -5;
    }

    public class StarfieldScene : IScene
    {
        private readonly Random _rnd = new Random();

        // Create a sprite batch (used for fire-and-forget sprites) to hold the stars.
        private readonly SpriteBatch _spriteBatch = new SpriteBatch();

        public void Render(GameEngine gameEngine)
        {
            // Check if the user wants to exit.
            if (gameEngine.SpriteWindow.IsKeyDown(VirtualKeys.Escape))
                gameEngine.SpriteWindow.Running = false;

            // Add a new star each frame.
            _spriteBatch.Add(new StarSprite(Program.Star, _rnd.Next(199), -(_rnd.Next(5) + 1)));

            // Make the stars act.
            _spriteBatch.ApplyLogic();

            // Draw the frame.
            _spriteBatch.Draw(gameEngine.SpriteWindow);
            gameEngine.SpriteWindow.Swap();
        }
    }
}

Mutable strings i C#

Den strängtyp som finns inbyggd i C# är “immutable”, vilket betyder att den inte kan ändra värde. Jag har skapat en “mutable string”, som kapslar strängtypen i en klass. Det innebär att man kan anropa funktioner på strängen för att få den att ändra värde. Dessa funktioner, och funktionerna för att analysera strängens innehåll, har färdiga implementationer, men dessa kan ersättas. T.ex. kan funktionen Is svara på frågan om två strängar har samma värde, enligt de flaggor som angavs när strängen skapades, eller så kan man skicka med egen kod som utför jämförelsen som argument till funktionen Is. Mer information finns här: https://github.com/Anders-H/MutableStringLibrary

Last Christmas, Radio ga-ga

Nu när vi behöver höra Last Christmas av Wham! tre gånger om dagen under en månads tid, kanske någon under någon av lyssningarna tänker att trummorna låter ungefär som det episka soundet på Radio ga-ga av Queen. Det finns såklart skäl till det.

Under det tidiga 1980-talet hade trummaskinen blivit något av ett instrument att räkna med inom pop-branschen. Tidigare var det mest synthare som intresserade sig för detta instrument. Något som Wham! och Queen hade gemensamt var att de gärna använde sig av syntetiska instrument, utan att direkt företräda musikstilen synth – särskilt inte Queen som aktivt tog avstånd från elektroniska instrument under sina första år av karriären.

Den första skiva Queen hade synthpålägg på var The Game (1980) men har sedan dess använt synthar väldigt flitigt, och gärna trummaskin på ett par låtar per skiva, dock inte på The Game – Another one bites the dust är en s.k. drum loop, som spelades in akustiskt med Roger Taylor bakom trumsetet.

Och något som utmärker musiker som inte är synthare, är att det är lättare att identifiera vilka syntetiska instrument som är i bruk, för icke-synthare tenderar att inte maskera sina instrumentval lika väl som riktiga synthare gör. Riktiga synthare kan rent av tänka sig att designa sina egna instrument, för att vara unika på allvar. Därför är det enkelt att höra att både Last Christmas och Radio ga-ga använder samma fabrikat av trummaskin. Under den här tiden var det Linn Electronics som ägde marknaden för trummaskiner.

Last Christmas använde LinnDrum (1982) som var laddad med 8-bitarssamples. När man pratar om digitalt ljud så avgör antalet bitar impulsstegen och frekvensen (35 KHz) samplingstätheten. Så mycket som möjligt av båda är önskvärt, och idag brukar digitala instrument jobba med 16-24 bitar och 44-48 KHz, men det är precis lika viktigt att de impulser (själva slaginstrumenten) som lagras håller god kvalitet och kan återges utan störningar.

Radio ga-ga är marginellt äldre än Last Christmas, men är uppbyggd med en enklare trummaskin, nämligen Linn LM-1 (1980). Linn LM-1 var en stor enhet som kostade dubbelt så mycket som en LinnDrum, men den kunde bara återge ljud i 28 KHz. Det är lite svårt att avgöra om det verkligen är samma sampling som utgör virveltrumman i de olika låtarna, för equalizer och effekter kan göra så mycket för med ett ljud, men troligtvis är det så.

Trummprogrammeringen i Radio ga-ga gjordes av Roger Taylor i sin hemmastudio och låten var avsedd för en av hans soloskivor. Efter att John Deacon skrivit ett basarrangemang och Freddie Mercury omkonstruerat låten, insåg han att den kunde bli en framgång med Queen. Han medverkade inte i inspelningen, utan lät Freddie Mercury och Fred Mandel bygga upp och spela in låten. (Att stuva om i Roger Taylors låtar medan han var frånvarande blev något av en vana för Freddie Mercury, vilket inte minst märks på A kind of magic – original/albumversion.)

Roger Linn, som designade Linn LM-1 och LinnDrum, fick en Grammy 2011 för sin insats för musikindustrin.

Rendera mandelbrotmängden

Min första kontakt med mandelbrotmängden var ett BASIC-program av Bo E. Carlsson runt 1990. Sedan dess har Andrej Bauer skrivit ett C++-program som skriver mandelbrotmängden till en bildfil. Programmet gick att kompilera med en C#-kompilator med endast små justeringar, vilket syns här:

var rawData = new ImageRawData(width, height);


var xmin = 0.27085;
var xmax = 0.27100;
var ymin = 0.004640;
var ymax = 0.004810;
var maxiter = 1000;

var dx = (xmax - xmin) / width;
var dy = (ymax - ymin) / height;

for (var j = 0; j < height; j++)
{
    var y = ymax - j * dy;
    for (var i = 0; i < width; i++)
    {
        var u = 0.0;
        var v = 0.0;
        var u2 = u * u;
        var v2 = v * v;
        var x = xmin + i * dx;
        
        int k;
        for (k = 1; k < maxiter && u2 + v2 < 4.0; k++)
        {
            v = 2 * u * v + y;
            u = u2 - v2 + x;
            u2 = u * u;
            v2 = v * v;
        }

        rawData.SetValue(i, j, k >= maxiter ? null : k);
    }
}

Den anpassade koden varken ritar bilden eller skriver den fill någon fil, utan samlar resultatet i en 2-dimensionell array som heter rawData (av typen ImageRawData). Anledningen till det är att jag vill kunna lägga på renderingsfilter efter att fraktalen är beräknad. I implementation har jag hittills endast lagt in en linjär interpolering till en gråskala mellan 0 och 255, men möjligheten att hitta på något roligt finns där.

public class ImageRawData
{
    private readonly int _width;
    private readonly int _height;
    private readonly int?[,] _data;

    public ImageRawData(int width, int height)
    {
        _width = width;
        _height = height;
        _data = new int?[width, height];
    }

    public void SetValue(int x, int y, int? value) =>
        _data[x, y] = value;

    public int GetValue(int x, int y) =>
        _data[x, y] ?? 0;

    private int GetLargest()
    {
        var largest = int.MinValue;

        for (var y = 0; y < _height; y++)
            for (var x = 0; x < _width; x++)
                if (_data[x, y].HasValue && _data[x, y] > largest)
                    largest = _data[x, y]!.Value;

        return largest;
    }

    private int GetSmallest()
    {
        var smallest = int.MaxValue;

        for (var y = 0; y < _height; y++)
            for (var x = 0; x < _width; x++)
                if (_data[x, y].HasValue && _data[x, y] < smallest)
                    smallest = _data[x, y]!.Value;

        return smallest;
    }

    public void Interpolate(int min, int max)
    {
        var smallest = GetSmallest();
        var largest = GetLargest();

        for (var y = 0; y < _height; y++)
        {
            for (var x = 0; x < _width; x++)
            {
                if (_data[x, y].HasValue)
                {
                    var v1 = _data[x, y]!.Value;
                    var v2 = LinearInterpolate(v1, smallest, largest, min, max);
                    _data[x, y] = v2;
                    continue;
                }

                _data[x, y] = max;
            }
        }
    }

    private static int LinearInterpolate(int value, int smallest, int largest, int min, int max)
    {
        var result = min + (value - smallest) * (max - min) / (largest - smallest);
        
        if (result < min)
            result = min;

        if (result > max)
            result = max;

        return result;
    }
}

Själva renderingen har jag lagt i en iteration, där jag påverkar zoom-faktorn en aning, för att kunna skapa en animation. Jag gör det lite asymmetriskt för effektens skull. Iteratorn heter frameCount.

var xmin = 0.27085 + frameCount * 0.0000001;
var xmax = 0.27100 - frameCount * 0.0000002;
var ymin = 0.004640 + frameCount * 0.0000003;
var ymax = 0.004810 - frameCount * 0.0000004;
var maxiter = 1000;

Sen är det bara att kapsla in kalaset i ett ramverk. Jag använder Windows Forms så att jag kan titta på varje renderad bild medan animationen renderas. Eftersom själva resultatet är animationen som skrivs till disk, inte själva programmet, så har jag kostat på mig att göra allt arbete i GUI-tråden. Sedvanliga ursäkter.

using System.Drawing.Imaging;

namespace WinFormsApp1
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void Form1_Shown(object sender, EventArgs e)
        {
            Refresh();
            using var g = CreateGraphics();
            const int width = 1024;
            const int height = 1024;

            for (var frameCount = 0; frameCount < 1000; frameCount++)
            {
                var rawData = new ImageRawData(width, height);

                var xmin = 0.27085 + frameCount * 0.0000001;
                var xmax = 0.27100 - frameCount * 0.0000002;
                var ymin = 0.004640 + frameCount * 0.0000003;
                var ymax = 0.004810 - frameCount * 0.0000004;
                var maxiter = 1000;

                var dx = (xmax - xmin) / width;
                var dy = (ymax - ymin) / height;

                for (var j = 0; j < height; j++)
                {
                    var y = ymax - j * dy;
                    for (var i = 0; i < width; i++)
                    {
                        var u = 0.0;
                        var v = 0.0;
                        var u2 = u * u;
                        var v2 = v * v;
                        var x = xmin + i * dx;
                        
                        int k;
                        for (k = 1; k < maxiter && u2 + v2 < 4.0; k++)
                        {
                            v = 2 * u * v + y;
                            u = u2 - v2 + x;
                            u2 = u * u;
                            v2 = v * v;
                        }

                        rawData.SetValue(i, j, k >= maxiter ? null : k);
                    }
                }

                Application.DoEvents();
                rawData.Interpolate(0, 255);
                using var image = new Bitmap(width, height);

                for (var yy = 0; yy < height; yy++)
                    for (var xx = 0; xx < width; xx++)
                        image.SetPixel(xx, yy, Color.FromArgb(
                            rawData.GetValue(xx, yy),
                            rawData.GetValue(xx, yy),
                            rawData.GetValue(xx, yy)
                        ));

                g.DrawImage(image, 0, 0);
                Application.DoEvents();
                image.Save($@"C:\Temp\Frame{frameCount:00000}.png", ImageFormat.Png);
                Application.DoEvents();
            }
        }
    }
}

Resultatet för just dessa värden är följande video:

TV4 uppmärksammar behovet av religiöst neutrala begravningsplatser

Häromdagen sände TV4-nyheterna ett inslag om religiöst neutrala begravningsplatser. I egenskap av ordförande i Humanisterna Örebro stöttade jag initiativet. TV4 Play: https://www.tv4play.se/program/nyheterna/religi%C3%B6sa-symboler-plockas-ned-i-kapellet-%C3%B6ppnar-f%C3%B6r-neutrala-begravningar/13732416

 

 
 
 
 
 
Visa detta inlägg på Instagram
 
 
 
 
 
 
 
 
 
 
 

 

Ett inlägg delat av Anders Hesselbom (@andershbom)

Preserverad SID-musik från 1988

I samband med att jag lämnade staden och flyttade till landet, så gjorde jag mig av med alla mina Commodore-maskiner. Jag passade på att preservera en liten del av mina disketter, men jag kunde inte rädda allt. En av disketterna innehöll fyra SID-låtar som jag programmerade 1988 med Rock Monitor och en sample rip från Funky Drummer. Rock Monitor var en vidareutveckling av Sound Monitor med stöd för samples. Båda programmen var anpassade för att underlätta SID-programmering.

Dessa fyra filer är kanske inte mitt stoltaste ögonblick som musiker, men eftersom det är historia så måste det såklart delas. Samtliga är packade som programfiler med Sledge Hammer. Dessa två är originallåtar:

“Ibburd”:

Hämta prg-fil.

“The Lennart Song”:

Hämta prg-fil.

Dessa två är covers. Om jag minns rätt så programmerade jag dessa mest för att lära mig monitorn:

“Push it”:

Hämta prg-fil.

“Romance d’amour/Du är den ende”:

Hämta prg-fil.

Samplingarna låter aningen bättre på en riktig Commodore 64 än i en emulator. Mycket nöje!

Två “nya” C64-demos från 1986-87

Jag har preserverat ett antal Commodore 64-disketter från min ungdom. Alla disketter med ännu ej preserverat material gick tyvärr inte att rädda, men några små guldkorn har jag fått tag i, som t.ex. en disk med följande fillista. Antal block inom parentes.

CCCP SMESSEL IX (101)
THE REAL DEMO! (79)
LIGHTS FANTASTIC (74)
MUSIC BOX III (60)
ESC DEMO II/FBR (50)
IBM MUSIC XVII (49)
CHICKEN FARM (35)
CAS DEMO #1 (32)
DAS BOOT -TRON- (29)
EYE TO EYE/FBR (21)
SOMEWHERE’S TIME (14)
TIME TRAVELLER (12)

CCCP SMESSEL IX av CCCP år 1987 är preserverat sedan tidigare. Filen på min disk fungerar inte, men demot var en textskärm med någon rippad musik följt av en dubbel borderscroller med någon Sound Tracker-implementation av Axel F (Harold Faltermeyer), och avslutas med en stor scroller.

THE REAL DEMO! av CCCP år 1987 är också preserverat sedan tidigare. Den inleds med en fullskärmsbild förställande en kinesisk ansiktsmask och bjuder sedan på två ytterligare delar utan originalmusik.

LIGHTS FANTASTIC (titelbilden) har jag inte sett preserverat någonstans, men du kan ladda ner den här. Du lyssnar på musik och tittar på mönster som ritas med linjer på skärmen. Du kan styra linjerna lite, och du kan växla låt. Det påminner om demot Tubular Bells.

MUSIC BOX III är rippad musik och lite specialeffekter av Thunderbolt Cracking Crew.

ESC DEMO II/FBR spelar en cover på White Wedding (Billy Idol) som tar tvärstopp efter några minuter, och visar bild rippad från Fist II. Tror inte att den finns preserverad sedan tidigare, men den kan laddas ner här.

IBM MUSIC XVII av The Electronic Knights år 1987 är en låt byggd på trummorna från trummaskinen Funky Drummer.

CHICKEN FARM (We Music, 1986) är en bild och en scrolltext upp-och-ned, med musik av David Whittaker.

CAS DEMO #1 (Cas, 1986) är en bild och en stor scrolltext i undre bordern, utan musik.

DAS BOOT -TRON- av Tron (okänt år) är en bild, en låt och en teckenbaserad scrolltext.

EYE TO EYE/FBR av AM Twelve år 1986 är en ganska rolig sprite-animation där två ögon åker runt på skärmen.

Både SOMWHERE’S TIME (Rubard) och TIME TRAVELLER (Skuzz, 1987) är två stillbilder, där den senaste är en ganska snygg pixlad Eddie the Head.

Jag hoppas att detta innebär att LIGHTS FANTASTIC och ESC DEMO II/FBR blir bevarade till eftervärlden.

Input parser för textäventyrsspel

Biblioteket TextAdventureGameInputParser kan användas för att parsa användarens input i ett textäventyr. Parsern tar en mening i stil med GO NORT, OPEN DOOR, USE GOLD KEY ON DOOR eller GIVE FOOD TO GANDALF och ger en struktur med ordklasser och referenser till objekt som är registrerade i parsern.

Lite exempel finns tillgängliga i parserns GitHub-repository, och parsern kan installeras (.NET 5.0) från Nuget.

Rick Beato: Varför gillar inte boomers pop?

Boomers gillar inte pop-musik. Musikern Rick Beato har en YouTube-kanal som han bl.a. använder för att lägga ut listor. Nyligen hade han en live stream där han presenterade en sammanställning (från chatt-diskussioner) om orsakerna bakom boomers ogillande av pop. Här är sexpunktslistan, med mina kommentarer.

  1. Inga tempovariationer. Modern musik tenderar att hålla ett och samma tempo genom hela stycket, utan accelerationer eller inbromsningar. Det ger inget utrymme för hörsamhet för vad en del behöver, och sänker dynamiken.
  2. Repetitiva ljud. I princip alla pop-låtar använder ungefär samma uppsättning av fabriksljud. Att vara musikproducent idag är onekligen en lat mans jobb. Förr kom flera ljud från analoga källor, som t.ex. mikrofoner.
  3. Inga tonartsförändringar. Förutom detta är antalet ackord väldigt lågt (runt fyra), och alla ackord ligger inom tonarten i fråga. Ett bra exempel på enkla tonartsvariationer måste vara vers två i “The show must go on” av Queen, som lyfter låten enormt.
  4. Ingen dynamisk variation. De amplitudförändringar som hörs i modern musik är en kompressor som låter ett instrument dränka ett annat. Boomers gillar musik där en musiker ibland kan smyga med sitt instrument.
  5. Enkla melodier. Modern musik tenderar att bygga kring en enkel “hook”, men melodierna är inte särskilt nyskapande, komplicerade eller intressanta. Ofta handlar det om några noter som är staplade på varandra.
  6. Auto-tune. Rösten blir alldeles för robot-lik och dynamiken som sångaren bidrar med till musiken, försvinner helt. Auto-tune gör ett bra jobb för en dålig sångare, men ett katastrofalt jobb för vem som helst som faktiskt kan sjunga.

Min uppfattning är att en musikkonsument inte nödvändigtvis är en musikintresserad person, och de känslor, det igenkännande, eller vad det nu är som musiken syftar till att försöka sälja, faktiskt fungerar. Om man inte är musikintresserad, vill säga…

Samantha Fox special double-groove multi-play pressing

Henrik Andersson har donerat maxisingeln “I surrender (to the spirit of the night)” med Samantha Fox till mig. En 12″-singel med skivnummer FOXY T6. Det som gör denna speciell anges på framsidan: Special double-groove multi-play pressing.

Det är inte helt självklart vad detta betyder, eller ens att det bara är sida två som avses. Det du kommer att märka när du spelar b-sidan av skivan, är att det ser ut som att den snurrar 90 varv per minut, men singlar (som denna) ska spelas upp i 45 varv per minut.

En vanlig LP spelas i 33,3 varv per minut, vilket innebär att det tar knappt två sekunder för nålen att flytta sig från det yttersta varvet till näst yttersta varvet. En singel snurrar 45 varv per minut, vilket innebär att samma förflyttning endast tar 1,3 sekunder för nålen att flytta sig ett varv in.

A-sidan, som är den utökade mixen av “I surrender (to the spirit of the night)”, fungerar som skivor gör mest. Ljudimpulsen ligger lagrad i ett spiralformat spår som rör sig in mot mitten. Oavsett var du lägger på nålen, kommer spiralen att fånga den, och leda den in till mitten. Detta är det normala:

Det special double-groove multi-play pressing betyder, är att det outnyttjade området på en vanlig 45-varvare har, är använt till ett spår till, innehållande samma information. Bilden visar principen. Beroende på var (eller när, eftersom armens position är statisk) du lägger på nålen, kommer antingen det ena (gröna) eller andra (röda) spåret att fånga armen och leda den till mitten. I praktiken är det slumpen som avgör.

Anledningen till att man vill ha det så här, är att slitaget på skivan kommer att vara i snitt hälften av slitaget på en vanlig skiva, eftersom du i det långa loppet kommer att spela det gröna spåret lika många gånger som det röda spåret. För den med en stor skivsamling i sin ägo är detta vanligtvis inte något stort problem, för en livstid räcker inte till särskilt många spelningar per skiva, men för en DJ som sliter på sina skivor, eller för den som råkar ha just denna låt som sin favorit, är detta något bra. (Många 7″-singlar som släppts under 80- och 90-talet har faktiskt varit av så låg kvalité att du endast kan lyssna på dem med full ljudkvalité 2-3 gånger.)

I teorin skulle man kunna ha olika information i de olika spåren, så att slumpen får avgöra vilken låt som spelas när man lägger på nålen, vilket Henrik Andersson (som donerade skivan till mig) faktiskt hävdar har gjorts.

(Jo, jag försökte komma nära med kameran och ta bilder på nålen, men för en sådan närbild har jag varken ljus eller stativ som håller måttet. Det kanske kommer längre fram.)

Lorenz vattenhjul

Lorenz-attraktionen är en fraktal vars formel beskriver en rotationshastighet (illustrerat med en radie) och en rotationsriktning. Så här ser den ut, implementerad i Commodore BASIC 7.0:

10 GRAPHIC 1,1
20 X=5
30 Y=5
40 Z=5
50 T=0
60 S=1/200
70 D=10
80 R=28
90 B=8/3
100 T=T+0.1
110 DX=D*(Y-X)
120 X1=X+DX*S
130 DY=(R*X-Y)-X*Z
140 Y1=Y+DY*S
150 DZ=X*Y-B*Z
160 Z1=Z+DZ*S
170 X=X1
180 Y=Y1
190 Z=Z1
200 DRAW 1,150+4*X,20+3*Z
210 IF T<1000 GOTO 100

Det går att bygga ett riktigt vattenhjul som ger samma figur som algoritmen ovan. Tänk dig ett hjul med ett antal hinkar (t.ex. åtta stycken). Den hink som är högst upp fylls på med vatten, och att du ger hjulet en knuff så att det roterar åt höger. På det viset kommer nästa hink strax börja fyllas med vatten, vilket ger en vikt på hjulets högra sida, så att rotationshastigheten ökar. Men alla hinkar har ett hål i botten, så när de inte ökar i vikt för att de fylls med vatten, så minskar de i vikt. När hinkarna når den uppåtgående vänstersidan av hjulet, väger de mycket mindre, vilket bidrar till att rotationshastigheten ökar. Men om rotationshastigheten ökar, så minskar samtidigt mängden vatten som fylls på i hinken högst upp, eftersom hinken befinner sig kortare tid vid positionen för påfyllning. Det innebär att den tyngsta sidan inte alltid kommer vara högersidan, eftersom den höga rotationshastigheten och den låga påfyllningen får vikten att förflytta sig. Ibland roterar alltså hjulet åt höger, ibland åt vänster. Ibland roterar hjulet fort, ibland långsamt.

Centralt i implementationen av denna simulering är en funktion som kan omvandla en vinkel på hjulet till en rotationskraft. Högst upp eller längst ner på hjulet, kommer vikten inte att påverka hjulets vilja att rotera alls. Längst till höger eller längst till vänster är kraften som störst. Vid 0 grader och vid 180 grader ska kraften vara 0, vid 90 och 270 grader är kraften maximal. Följande funktion är central för implementationen. Den beskriver hur starkt grepp gravitationen har över hinken – ingen alls högst upp eller längst ner, väldigt mycket längst till höger eller vänster.

Math.Cos(angle / (180.0 / Math.PI));

Implementationen av hjulet har 8 entiteter (“hinkar”) utplacerade med jämna mellanrum. 8 genom 350 ger 45 graders mellanrum. Den lilla knuffen åt höger får ha värdet 0,2 så att rotationen kommer igång.

var angle = 0;
for (var i = 0; i < 8; i++)
{
    Wheel.Buckets.Add(new Bucket(Wheel, angle));
    angle += 45;
}
Wheel.Speed = 0.2;

För hjulets beteende gäller följande: Hastigheten (som är positiv för höger och negativ för vänster) adderas till vinkeln. Därefter kontrollerar vi att vinkeln ligger mellan 0 och 360. Därefter berättar vi för varje hjul vilken vinkel de sitter på, givet hjulets vinkel, och ber samtidigt hjulet att agera (nedan). Sedan räknar vi ut hur hinkkonfigurationen påverkar hastigheten, och kontrollerar samtidigt att maxhastigheten åt höger eller vänster inte överstiger hjulets tänkta maxhastighet.

public void Tick()
{
    Angle += Speed;
    if (Angle < 0.0)
        Angle += 360.0;
    else if (Angle > 360.0)
        Angle -= 360.0;

    var bucketAngle = Angle;

    for (var i = 0; i < 8; i++)
    {
        if (bucketAngle < 0.0)
            bucketAngle += 360.0;
        else if (bucketAngle > 360.0)
            bucketAngle -= 360.0;
            
        Buckets[i].Tick(bucketAngle);
        bucketAngle += 45.0;
    }
    Speed += SpeedInfluence();
    const double maxSpeed = 7.0;
    if (Speed > maxSpeed)
        Speed = maxSpeed;
    else if (Speed < -maxSpeed)
        Speed = -maxSpeed;
}

public double SpeedInfluence() =>
    Buckets.Sum(x => x.SpeedInfluence());

För varje hinks beteende gäller följande: Om hinken är högst upp, öka vattenmängden, annars minska vattenmängden en aning. Varje hjul måste kunna uppge gravitationens grepp om hinken.

public void Tick(double newAngle)
{
    Angle = newAngle;
        
    if (Angle >= 255.0 && Angle <= 285.0)
        Full += 2.0;

    Full -= 0.12;
        
    if (Full < 0.0)
        Full = 0.0;
    else if (Full > 100.0)
        Full = 100.0;
}

public double SpeedInfluence() =>
    Math.Cos(Angle / (180.0 / Math.PI)) * (Full * 0.03);

Endast vattnet har vikt, hinkarna väger ingenting. Eftersom hjulet är balanserat och alla tomma hinkar väger lika mycket, kan vikten lika gärna vara 0.

Resultatet blir ett hjul som ibland snurrar fort, ibland långsamt, ibland åt höger och ibland åt vänster.

Koden körs i ett Windows Forms-fönster med DoubleBuffering aktiverat. Här är hela källkoden:

using System;
using System.Collections.Generic;
using System.Drawing;
using System.Linq;
using System.Windows.Forms;

public partial class Form1 : Form
{
    private Wheel Wheel { get; }

    public Form1()
    {
        InitializeComponent();
        Wheel = new Wheel();
        InitializeWheel();
    }

    private void InitializeWheel()
    {
        var angle = 0;
        for (var i = 0; i < 8; i++)
        {
            Wheel.Buckets.Add(new Bucket(angle));
            angle += 45;
        }
        Wheel.Speed = 0.2;
    }

    private void Form1_Paint(object sender, PaintEventArgs e)
    {
        var g = e.Graphics;
        g.Clear(Color.Green);

        var centerX = (Bounds.Width / 2);
        var centerY = (Bounds.Height / 2);
            
        var availableSize = Bounds.Width > Bounds.Height
            ? Bounds.Height
            : Bounds.Width;

        var radius = availableSize * 0.3;

        var renderer = new Renderer(centerX, centerY, (float)radius);
        renderer.Draw(g, Wheel, Font);
    }

    private void timer1_Tick(object sender, EventArgs e)
    {
        Wheel.Tick();
        Invalidate();
    }
}

public class Wheel
{
    public List<Bucket> Buckets { get; set; }
    public double Speed { get; set; }
    public double Angle { get; set; }

    public Wheel()
    {
        Buckets = new List<Bucket>();
        Angle = 0.0;
    }

    public void Tick()
    {
        Angle += Speed;
        if (Angle < 0.0)
            Angle += 360.0;
        else if (Angle > 360.0)
            Angle -= 360.0;

        var bucketAngle = Angle;

        for (var i = 0; i < 8; i++)
        {
            if (bucketAngle < 0.0)
                bucketAngle += 360.0;
            else if (bucketAngle > 360.0)
                bucketAngle -= 360.0;
            
            Buckets[i].Tick(bucketAngle);
            bucketAngle += 45.0;
        }
        Speed += SpeedInfluence();
        const double maxSpeed = 7.0;
        if (Speed > maxSpeed)
            Speed = maxSpeed;
        else if (Speed < -maxSpeed)
            Speed = -maxSpeed;
    }

    public double SpeedInfluence() =>
        Buckets.Sum(x => x.SpeedInfluence());
}

public class Bucket
{
    public double Weight { get; set; }
    public double Angle { get; set; }
    public double Full { get; set; }

    public Bucket(double angle)
    {
        Weight = 0.0;
        Angle = angle;
        Full = 0.0;
    }

    public void Tick(double newAngle)
    {
        Angle = newAngle;
        
        if (Angle >= 255.0 && Angle <= 285.0)
            Full += 2.0;

        Full -= 0.12;
        
        if (Full < 0.0)
            Full = 0.0;
        else if (Full > 100.0)
            Full = 100.0;
    }

    public double SpeedInfluence() =>
        Math.Cos(Angle / (180.0 / Math.PI)) * (Full * 0.03);

    public void Draw(Graphics g, PointF location, Font font)
    {
        using var bucketBrush = new SolidBrush(Color.FromArgb(255, 255, 255));
        using var waterBrush = new SolidBrush(Color.FromArgb(0, 128, 255));
        var bucketRectangle = new RectangleF(location.X - 51, location.Y - 51, 102, 102);
        g.FillRectangle(bucketBrush, bucketRectangle);
        if (Full > 0.0)
        {
            var waterRectangle = new RectangleF(location.X - 50, (float)(location.Y - 50 + (100.0 - Full)), 100, (float)Full);
            g.FillRectangle(waterBrush, waterRectangle);
        }
        g.DrawString(Angle.ToString("0.00"), font, Brushes.Black, (float)(location.X - 20), (float)(location.Y - 20));
        g.DrawString(Full.ToString("0.00"), font, Brushes.Black, (float)(location.X - 20), (float)(location.Y));
    }
}

public class Renderer
{
    private readonly PointF _center;
    private readonly float _radius;

    public Renderer(float centerX, float centerY, float radius)
    {
        _center = new PointF(centerX, centerY);
        _radius = radius;
    }

    public void Draw(Graphics g, Wheel wheel, Font font)
    {
        foreach (var bucket in wheel.Buckets)
        {
            var bucketLocation = new PointF(
                (float)(_center.X + Math.Cos(bucket.Angle / (180.0 / Math.PI)) * _radius),
                (float)(_center.Y + Math.Sin(bucket.Angle / (180.0 / Math.PI)) * _radius)
            );
            g.DrawLine(Pens.Black, _center, bucketLocation);
            bucket.Draw(g, bucketLocation, font);
        }
    }
}

Det går garanterat att justera acceleration, gravitation, inflödeshastighet, utflödeshastighet och maximal hastighet för andra (bättre?) resultat.

GetEnumerator extension method

En ganska enkel men ytterst trevligt tillägg i C# version 9 är möjligheten att skapa en extension method av GetEnumerator (som konsulteras när en samling ska enumereras). Betrakta denna lilla lista:

var people = new List<string>
{
    "Sven",
    "Nils",
    "Niklas",
    "Janne"
};

Om jag skulle vilja ha samtliga poster i listan för utskrift på skärmen, kan denna kod användas:

foreach (var p in people)
    Console.WriteLine(p);

GetEnumerator används implicit. Men om jag bara är intresserad av att ha med poster vars förnamn börjar på N, så måste det formuleras någonstans. Jag kan t.ex. kopiera listan och exkludera ointressanta poster, eller så skulle jag kunna iterera genom svaret från LINQ-API:et enligt:

foreach (var p in people.Where(x => x.StartsWith("N")))
    Console.WriteLine(p);

Extension methods har fördelen att de är tillgängliga i filer som läst in dess namnrymd, men är i övrigt otillgängliga. Det innebär att man kan begränsa funktionalitet till vissa filer genom att skapa en extension metod. Om jag generellt sett är intresserad av att ha personerna som börjar på N tillgängliga i den aktuella filen (eller på annat sätt kunna använda manipulerat data) kan jag deklarera en egen GetEnumerator som en extension method. Är den tillgänglig, kommer kompilatorn att välja den. I detta fall kommer man troligtvis att vilja ha full tillgänglighet för metoden.

static class MyEnumerator
{
    public static IEnumerator<T> GetEnumerator<T>(this IEnumerator<T> list) =>
        list;
}

Med denna på plats, öppnas en ny möjlighet. Svaret från den funktionen, kan itereras. Nu kan jag skapa en enumerator som t.ex. skickar tillbaka personerna som börjar på N. Med det gjort, blir iterationen lika enkel som i första exemplet, fast med den skillnaden att jag nu kontrollerar dess innehåll.


var somePeople = people
   .Where(x => x.StartsWith("N"))
   .GetEnumerator();

foreach (var p in somePeople)
    Console.WriteLine(p);

Detta är egentligen inte en stor sak, men det bidrar till kodens elegans – något som har blivit ett av kännetecknen för C#.

Objektnotation: XML, JSON, PSON

Här följer en kort kommentar om tre olika format för textbaserad objektnotation.

XML

Fördelar: Stöd för dokumenttypsdefinitioner (DTD) och scheman. God tillgång på bra API:er.
Nackdelar: Mycket overhead (ett “pratigt” språk), endast Visual Basic har inbyggt stöd för formatet.

Exempel på notation:

<?xml version="1.0" encoding="utf-8" ?>
<customer>
	<id>551</id>
	<account>9153</account>
	<name>
		<firstName>Sven</firstName>
		<lastName>Hedin</lastName>
	</name>
</customer>

Exempel på inläsning (C#, otypat):

var dom = new XmlDocument();
dom.Load("object.xml");
var document = dom.DocumentElement;
var customerId = document!.SelectSingleNode("id")!.InnerText;
Console.WriteLine($"ID={customerId}");

JSON

Fördelar: Liten overhead, god tillgång på bra API:er. Minimal schematisk information (vad som är en array eller ett enskilt objekt) kan anges i formatet.
Nackdelar: Nästan ingen typsäkerhet.

Exempel på notation:

{
  "id": 551,
  "account": 9153,
  "name": {
    "firstName": "Sven",
    "lastName":  "Hedin" 
  } 
}

Exempel på inläsning (C#, otypat):

using var sr = new StreamReader("object.json", Encoding.UTF8);
var json = sr.ReadToEnd();
dynamic customer = JObject.Parse(json);
Console.WriteLine($"ID={customer!.id}");

Exempel på inläsning (C#, typat):

using var sr = new StreamReader("object.json", Encoding.UTF8);
var json = sr.ReadToEnd();
var customer = JsonSerializer.Deserialize<Customer>(json);
Console.WriteLine($"ID={customer!.Id}");

class Customer
{
    [JsonPropertyName("id")]
    public int Id { get; set; }
    [JsonPropertyName("account")] 
    public int Account { get; set; }
    [JsonPropertyName("name")] 
    public Name Name { get; set; }
}

class Name
{
    [JsonPropertyName("firstName")]
    public string FirstName { get; set; }
    [JsonPropertyName("lastName")]
    public string LastName { get; set; }
}

PSON

Fördelar: Liten overhead. Viss schematisk information kan anges i formatet, som vad som är en array eller ett enskilt objekt och objekttyp. Kan skrivas typsäkert.
Nackdelar: Kan endast användas från PowerShell.

Exempel på notation:

@{
  Id: 551,
  Account: 9153,
  Name: @{
    FirstName: "Sven"
    FastName:  "Hedin" 
  } 
}

Inläsning av den filen sker genom PowerShell och kan plockas upp av C# genom det generella gränssnittet Microsoft tillhandahåller för att nå svaret från PowerShell.

Datastorleken för XML är 188 bytes, JSON 110 bytes och PSON 104 bytes.

Musikdistribution på Rockklassiker år 2012

Jag har tittat på vad radiokanalen Rockklassiker spelade på radio under första kvartalet år 2012, alltså mellan 2012-01-01 och 2012-03-31. Eftersom kanalen spelade musik i princip dygnet runt, med undantag av lite reklampauser och annat, hann man med att spela hela 26510 låtar. Man gick ut starkt genom att spela “800 grader” med Ebba Grön som årets första låt, kl. 00:00 på nyårsdagen, och avslutade kvartalet med att spela “I’m on fire” med Bruce Springsteen strax före midnatt den 31:a mars. Här är lite statistik över de musikval man gjorde då.

Trots att hela 26510 låtar hann spelas, så hade man bara 829 låtar på spellistan under perioden i fråga. Det innebär att många låtar har spelats många gånger. Så här ser listan över de 20 mest spelade låtarna ut:

Artist                   Titel                    Antal
------------------------ ------------------------ -----
Dio                      Rainbow In The Dark        197
Dio                      Holy Diver                 192
Rage Against the Machine Killing in the name of     192
Alice Cooper             Poison                     191
Gary Moore               Out In The Fields          185
DAD                      Laugh 'n' a half           180
W.A.S.P.                 I Wanna Be Somebody        178
Jimi Hendrix             Purple Haze                177
Judas Priest             Breaking The Law           171
Sweet                    Ballroom Blitz             171
Billy Idol               Rebel Yell                 170
Midnight Oil             Beds Are Burning           170
Offspring                Self esteem                170
Ugly Kid Joe             Cats In The Cradle         170
Motorhead                Ace of spades              168
Iggy Pop                 The Passenger              166
Sounds                   Living in America          166
Ram Jam                  Black Betty                164
Red Hot Chili Peppers    Scar Tissue                164
Ebba Grön                800 grader                 162

223 låtar spelades bara en enda gång under perioden. Bland dessa hittar vi ganska prominenta låtar som “Build me up, break me down” med Dream Theater, “Young lust” med Pink Floyd, “Fight fire with fire” med Kansas, sex låtar med Deep Purple och inte mindre än sju låtar med Jimi Hendrix! Snyggt!

Om man tittar på individuella låtar tar Dio hem segern med god marginal, men han har bara sex låtar med på listan, varav i princip alla spelningar är de två som ligger först. Tittar vi på top 20 över mest spelade artister dyker Dio upp först på 19:e plats, helt utklassad av Guns n’ Roses, AC/DC och Metallica.

Artist                   Antal
------------------------ -----
Guns n' Roses             1007
AC/DC                      981
Metallica                  967
Iron Maiden                910
Nirvana                    783
Kiss                       749
Queen                      738
Bon Jovi                   717
Ebba Grön                  677
Ozzy Osbourne              599
U2                         559
Billy Idol                 481
Scorpions                  475
Red Hot Chili Peppers      464
Bruce Springsteen          448
Europe                     441
Rolling Stones             430
Green Day                  418
Dio                        408
Aerosmith                  352

Bland de 20 artister som endast spelades en gång under perioden hittar vi förvånande nog Boston, R.E.O. Speedwaggon och Cheap Trick.

Så hur många låtar var de olika artisterna representerade med på listan? Rockklassikers spellista bestod som sagt av 829 låtar under perioden, och 192 artister var representerade. 87 av artisterna hade en enda låt på listan. Bland dessa hittar vi bl.a. David Lee Roth, Genesis, Yes, Asia, Yngwie Malmsteen, Cream och Helloween. En salig blandning mellan artister som av melodiradion felaktigt betraktas som one hit wonders (t.ex. Blue Öyster Cult) och extremt prominenta artister som av någon anledning inte fick med mer än en enda låt (t.ex. 10cc).

Här är de 20 artister som fick med flest låtar på Rockklassikers spellista:

Artist                   Antal
------------------------ -----
Kiss                        36
AC/DC                       33
Bruce Springsteen           30
Metallica                   30
Van Halen                   29
Guns n' Roses               25
Iron Maiden                 21
Rolling Stones              18
Queen                       17
U2                          16
Deep Purple                 15
Jimi Hendrix                15
Black Sabbath               14
Motley Crue                 14
Motorhead                   14
Ozzy Osbourne               14
Bon Jovi                    13
Def Leppard                 13
Nirvana                     12
Aerosmith                   11

Kiss var alltså representerade med hela 36 låtar, nämligen dessa (sorterat på antal spelningar):

Titel                            Antal
-------------------------------- -----
Heaven's On Fire                   131
I was made for loving you          122
Detroit Rock City                  118
I Love It Loud                     102
Lick It Up                          87
Rock And Roll All Nite              78
God Gave Rock and Roll To You       27
God Of Thunder                       8
Love Gun                             8
Psycho Circus                        8
2,000 Man                            7
Calling Dr. Love                     7
Cold Gin                             4
Creatures Of The Night               4
Unholy                               4
Shout It Out Loud                    3
Strutter                             3
Crazy Crazy Nights                   3
Flaming Youth                        3
Do you love me?                      2
Beth                                 2
King of the night time world         2
Mr Speed                             2
I Love It Loud (Live)                2
I want you                           1
I Was Made For Loving You (Live)     1
Raise Your Glasses                   1
Rock And Roll All Nite (Live)        1
Shout It Loud (Live)                 1
Sure Know Something                  1
Sweet Pain                           1
Creatures Of The Night (Live)        1
Deuce                                1
Hotter Than Hell                     1
Great Expectations                   1
Hard Luck Woman                      1

För att samla ihop underlaget till detta blogginlägg byggde jag en s.k. web scraper i Visual Basic som fick kamma hem texten på Rockklassikers hemsida, som jag startade strax före tolvslaget nyårsafton 2011 och stängde av i början på april 2012.

C# 9 Records

Hur projektmallarna pytsas ut i Visual Studio har verkligen övergått mitt förstånd. Beträffande .NET 5.0 var Windows Forms-mallen tillgänglig långt innan Console Application-mallen, men nu är äntligen allt på plats. Med anledning av det vill jag summera nyheterna i C# version 9 som, för att fungera fullt ut, kräver .NET 5.0. Här är den första:

Records
Records är klasser där man gjort avkall på vissa möjligheter för att komma åt möjligheten skapa objekt med properties på så lite kod som möjligt. Nyckelordet record anger att de medlemmar som följer ska vara publika (vilket inte stämmer enligt nuvarande officiell version) och om de inte ska kunna modifieras i programkoden, kan de nu deklareras som init (vilket faktiskt fungerar), vilket betyder public fram till första tilldelningen, därefter private.

using System;

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            var a = new Something {X = 10, Y = 20};
            Console.WriteLine(a.X);
        }
    }

    public record Something
    {
        public int X { get; init; }
        public int Y { get; init; }
    }
}

Skulle programmet fortsätta med tilldelningen a.X = 30 skulle kompilatorn påpeka att vår enda chans att lagra et värde i a.X är förbrukad.

Slow down (Commodore 64)

En inte helt obetydlig del av min musiksmak kommer från Commodore 64, vars analoga musikkapacitet saknade motstycke. Vissa demos som släpptes var innehöll korta samplingar från kontemporär populärmusik, som t.ex. Slow down. När det handlar om digital musik var C64:an ytterst undermålig – minnet var för litet, antalet bitar per samplingspunkt var får lågt. Men digitala musikdemos släpptes, för att det gick. Ett av dessa var Slow down (länkad ovan) som jag inte hade den blekaste aning om varifrån den kom förrän YouTube dök upp. Nu vet jag att det handlade om ett snävt urval från maxiversionen av gruppen Loose ends singel med samma namn.

Hur svårt är det att gissa ett tal?

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);
    }
}

Och detta är Steven:

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;
    }
}

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();
}

Flytta C64-program till din PC

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:

OPEN1,[enhet],15,"CD:[avbildning innehållande DraCopy]":CLOSE1

I mitt fall:

OPEN1,8,15,"CD:dc10d.d64":CLOSE1

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.)

C# from the command window

If you are using .NET Core (or .NET 5.0) you can easily activate the ability to run C# code from the command window (Windows Terminal or the old cmd.exe).

To get started, install dotnet-script by typing:

dotnet tool install --global dotnet-script

Once installed, you can start the dotnet-script program just by typing:

dotnet-script

The prompt now looks like a greater than-sign (>). From here, you can type any C# code and you can reference anything within the System namespace. For example, if you type:

Console.WriteLine("Hello world!");

…you will get the following answer:

Hello world!

A few things to keep in mind: Types you add will be remembered for the whole session. For example, if you type in a class, you can use that class in the session. And if the command windows expect further input, the prompt will change from a greater than-signe to an asterisk sign (*). So if you type in something like class MyClass { and press Enter, nothing will be executed. Instead, the command window will indicate that more input is expected by displaying an asterisk sign. To try this out, type something like this (terminating each statement with Enter):

class MyClass {
public void DoSomething() {
Console.WriteLine("Hello!");
}
}

And then, you can use your new type like this:

new MyClass().DoSomething();

The response will be:

Hello!

The picture shows the different prompts when you type in a simple for loop:

This is a very powerful tool to use when you want to perform tasks that are a bit too complicated for a calculator, but perhaps a bit too simple fore an advanced computer program, or when you want to try out some API you are working on. Happy programming!

DOD är bättre OOD för tidskritiska system

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; }
    }
}

Podcasts

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.

Kategoriska uttalanden om vad datorer kan och inte kan bygger ofta på okunskap

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.

Stulet gods 1/20

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.

Hemsida: http://stuletgods.80tal.se/
Prenumerera (RSS): http://stuletgods.80tal.se/rss.xml
iTunes: https://podcasts.apple.com/se/podcast/stulet-gods/id1507649534
Spotify: https://open.spotify.com/show/0KcEPjKKZcO8KHh2T8F4eL
Direktlänk, Spotify: https://open.spotify.com/episode/77WKIjpr41E9GYVBVQFd6r

Varför blir datorer mer och mer pålitliga jämfört med experter?

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.