Maskinellt lärande i inbyggda system - Vem är på?

[DanielM]

Tar multiplikation mer tid än addition?

Ja. Jag använder matriser. Men har lite andra funderingar nu om man inte ska använda matriser. Jag har insett att måste använda sig utav float för att lösa detta problem. Eller gå tillbaka till histogrammen.

Metod 1:
Jag skapar min matris \(A\) från mitt histogram. Egentligen behöver jag bara använda histogrammet då det redan är i praktiken en matris på 16x16.

Sedan behöver jag sätta en etikett som jag vill träna mot. Alltså \(b\). Då löser jag \(Ax=b\) där \(x\) blir float och \(b\) kan vara t.ex. radnummret fast i binär form.

När jag sedan ska verifera så skapar jag min matris \(A\) och multiplicerar det med \(Ax\) för att hitta \(b\). Där efter måste jag hitta ett \(b\) som omvandlas till ett binärt värde.

Det problem jag har stött på är:

• Minsta kvadratmetoden måste användas, dvs LU, QR, SVD osv för att beräkna \(x\)
• När jag sedan ska verifiera med en godtyckligt \(A\) så måste \(x\) vara så anpassat så inte \(b\) blir andra värden. Minsta kvadratmetoden är för precision och här ska jag inte ha någon precision. Jag ska bara ha ett si så där med stora felmarginaler.
• Minsta kvadratmetoden är endast till för linjära system. Linjära system fungerar bra om det är hög upplösning och många ekvationer.

Fördelen med denna metod är att jag kan spara minne radikalt!

Metod 2:
Jag återgår till vanliga metoden jag körde innan (Rom byggdes inte över en natt) och utvecklar mer villkor.

• Totala summan av absoluta felvärdet måste vara det minsta. Denna fungerar bra!
• Antalet absoluta felvärden som ej överstiger en viss nivå. Denna funderar jag på lägga till. Tänkte då kanske man kommer förbi brus?

Exempel:
En blå blomma i en röd bakgrund har felvärdet 50 och antal felvärden som ej överstiger ett valt värde är 78.
När jag byter bakgrund till en fläckig svartvit bakgrund så ökar felvärdet till 150, men antal felvärden som ej överstiger ett valt värde är fortfarande 78.

Förstår ni hur jag menar?

Exempelvis så skulle man lära sig att avgöra hur man kan räkna på skillnader i ett bar-diagram.

[Lennart Aspenryd]

Fel!
Rom byggdes inte på en dag heter det.
På min tid, när processorn bara hanterade en tråd i taget, diskuterade vi vad varje kommando tog i cykler. Jag är säker på att den kunskapen finns även idag. Varje assemblerinstruktion tar ju sina steg. Att då veta vad som händer med addition respektive multiplikation är rätt väsentligt.
Du är säkert på rätt väg DanielM ,
men unna dig lite grundläggande kunskap om cykeltider hos processorn så kan du bli professor på detta.
Och ta gärna till dig lite , i varje fall visa att du läst, de andra kommenterar.

robo10.png

Good Luck!

[DanielM]

Jag lägger allt på minnet. Men som sagt så om jag tjänar 1ms på att skriva om alla kod så kanske det inte är värt

[bearing]

Hur många cykler en multiplikation tar kan du läsa i manualen för processorn. Den länkade jag till för säkert ett år sedan när vi diskuterade samma sak. Generellt: Ja. Nu behövs det visserligen inte någon multiplikation i ditt fall, eftersom att du använder faktorn 256, som är en multipel av två. Så om faktorn alltid är 256 kan skillnaden vara mindre än att det vore värt mödan att skriva om.
Sen är det ju en fråga om läsbarhet också. Det är generellt helt okej att välja en mindre snabb lösning ifall det ökar läsbarheten. I ditt fall skulle det nog både öka läsbarheten, öka hastigheten, samt underlätta kodunderhållet, med en loop.

[DanielM]

Jag har använt en loop, mest bara för läsbarhetens skull

[hummel]

Det är bara 1 rad
Jag gör så istället för att ha en for-loop. Har man en for-loop så tar det tid. Men gör man exakt allt på en enda rad så går det snabbt.

Ser ut att generera mer än en rad assembler ...

Notera att det inte gick att klistra in assemblerkoden här "Ditt meddelande innehåller 210009 tecken. Det maximala antalet tillåtna tecken är 60000."
Jag tog bort nästan 6000 rader av koden!

Kod: Markera allt

 
Ltmp35:
	.loc	1 100 18 prologue_end   ## DM2/main.c:100:18
	movq	-16(%rbp), %rdx
	.loc	1 100 35 is_stmt 0      ## DM2/main.c:100:35
	movzwl	-2(%rbp), %edi
	.loc	1 100 34                ## DM2/main.c:100:34
	shll	$8, %edi
	.loc	1 100 29                ## DM2/main.c:100:29
	movslq	%edi, %rsi
	.loc	1 100 16                ## DM2/main.c:100:16
	movzbl	(%rdx,%rsi), %edi
	.loc	1 100 46                ## DM2/main.c:100:46
	movq	-24(%rbp), %rdx
	.loc	1 100 44                ## DM2/main.c:100:44
	movzbl	(%rdx), %ecx
	.loc	1 100 42                ## DM2/main.c:100:42
	subl	%ecx, %edi
	.loc	1 100 12                ## DM2/main.c:100:12
	callq	_abs
	.loc	1 101 16 is_stmt 1      ## DM2/main.c:101:16
	movq	-16(%rbp), %rdx
	.loc	1 101 33 is_stmt 0      ## DM2/main.c:101:33
	movzwl	-2(%rbp), %ecx
	.loc	1 101 32                ## DM2/main.c:101:32
	shll	$8, %ecx
	.loc	1 101 27                ## DM2/main.c:101:27
	movslq	%ecx, %rsi
	.loc	1 101 14                ## DM2/main.c:101:14
	movzbl	1(%rdx,%rsi), %ecx

	popq	%rbp
	retq

[hummel]

Det är bara 1 rad
Jag gör så istället för att ha en for-loop. Har man en for-loop så tar det tid. Men gör man exakt allt på en enda rad så går det snabbt.

Ser ut att generera mer än en rad assembler ...

Notera att det inte gick att klistra in assemblerkoden här "Ditt meddelande innehåller 210009 tecken. Det maximala antalet tillåtna tecken är 60000."
Jag tog bort nästan 6000 rader av koden!

Kod: Markera allt

 
Ltmp35:
	.loc	1 100 18 prologue_end   ## DM2/main.c:100:18
	movq	-16(%rbp), %rdx
	.loc	1 100 35 is_stmt 0      ## DM2/main.c:100:35
	movzwl	-2(%rbp), %edi
	.loc	1 100 34                ## DM2/main.c:100:34
	shll	$8, %edi
	.loc	1 100 29                ## DM2/main.c:100:29
	movslq	%edi, %rsi
	.loc	1 100 16                ## DM2/main.c:100:16
	movzbl	(%rdx,%rsi), %edi
	.loc	1 100 46                ## DM2/main.c:100:46
	movq	-24(%rbp), %rdx
	.loc	1 100 44                ## DM2/main.c:100:44
	movzbl	(%rdx), %ecx
	.loc	1 100 42                ## DM2/main.c:100:42
	subl	%ecx, %edi
	.loc	1 100 12                ## DM2/main.c:100:12
	callq	_abs
	.loc	1 101 16 is_stmt 1      ## DM2/main.c:101:16
	movq	-16(%rbp), %rdx
	.loc	1 101 33 is_stmt 0      ## DM2/main.c:101:33
	movzwl	-2(%rbp), %ecx
	.loc	1 101 32                ## DM2/main.c:101:32
	shll	$8, %ecx
	.loc	1 101 27                ## DM2/main.c:101:27
	movslq	%ecx, %rsi
	.loc	1 101 14                ## DM2/main.c:101:14
	movzbl	1(%rdx,%rsi), %ecx

	popq	%rbp
	retq

[bearing]

Jag har använt en loop, mest bara för läsbarhetens skull

Du menar att du har ändrat din kod som bestod av 256 rader, och alltså numera är en loop?
Eller pratar du om något annat?
Oavsett så har ju såklart inte ett enda inlägg i tråden varit till din hjälp enligt dig va? Utan du har såklart bara, helt apropå ingenting, och helt oberoende av trådens inlägg, ändrat din kod, bara för läsbarhetens skull. Japp.

Att en rad C-kod normalt inte är snabbare än flera rader som gör precis samma sak, det är liksom grundläggande, samt har varit en fråga på de skriftliga prov som jag fått göra i anställningsprocessen för några av jobben jag haft.

[DanielM]

Jag har ändrat efter rekommendationer av er.

Jag har varit lite upptagen angående bildigenkänningen.

Jag har hittat en lösning nu. Den tar dock mycket minne. Men det är väldigt logisk och träffsäker.

[DanielM]

Nu har jag gjort klart min lösning.
Local Binary Pattern Histogram heter metoden. Passar klassificering och är väldigt snabb. Den är robust mot linjär ljusförändringar. Nackdelen är att den tål inte riktigt brus bra.

Men detta metod har jag bakat in Linear Discriminal Analysis. Det låter häftigt, men det är bara medelvärdet delat i variansen för att minimera \(J\).

\(J = \frac{(\mu_1 - \mu_2)^2}{s_1^2 + s_2^2}\)

I detta fall så har jag delat upp LDA så jag jämför klasserna igenom att sumera \((\mu_1 - \mu_2)^2\) och \(s_1^2 + s_2^2\). Gillar inte att det finns en risk att dividera med 0. Dela med heltal är något som jag inte rekommenderar när det kommer till beräkningar.

Koden finns på https://elektronikforumet.com/forum/vie ... 0#p1514530