Svenska ElektronikForumet

Det är väl ingen som säger att dina matriser inte ska vara dynamiska (i storlek misstänker jag att du menar), bara att minnesblocken ska vara fix i storlek för den största matrisen du vill supporta.

Du kan väl ha samma syntax, bara det att allokeringen av minnet går fortare och inte riskeras att fragmenteras...

Det extremt snabba sättet är att inte allokera det dynamiskt, ska du ha en terminalpromt där man ska knappa in algoritmerna, eller hur knappar man in de i uC?

Al_Bundy skrev:> Varför måste det vara dynamiskt?
För att matriser är dynamiska.

På vilket sätt menar du? Jag skulle vilja påstå att matriser är statiska i storlek men värdena kanske är dynamiska. Operationer som görs på matriser skulle jag argumentera skapar nya matriser.

Okej. Det är inget problem för mig att ha en fix 2D matris för kolumner. Jag vet om att C stödjer inte 2D matriser, om man inte skickar en matris som argument t.ex. float [max_rad][max_kolumn] för alla matriser.

Eller vad tror du om man har en fixerad 2D matris i en struct och sedan skickar man runt minnet för denna struct?

Shimonu skrev:

Al_Bundy skrev:> Varför måste det vara dynamiskt?
För att matriser är dynamiska.

På vilket sätt menar du? Jag skulle vilja påstå att matriser är statiska i storlek men värdena kanske är dynamiska. Operationer som görs på matriser skulle jag argumentera skapar nya matriser.

Det är det dem inte är. Dem varierar enormt hela tiden.

Det hindrar dig fortfarande inte från att använda samma koncept

Självklart inte. Frågan är hur mycket jag vinner.
Om jag använder ca 100 stycken statiska matriser där varje matris är 100x100. Då får jag ganska mycket att lagra på minnet.

I slutändan så tror jag det inte blir så bra idé. GNU Scientific Library använder sig av allokerade matriser.

Var inte din max matris storlek 36x36?

Al_Bundy skrev:Självklart inte. Frågan är hur mycket jag vinner.
Om jag använder ca 100 stycken statiska matriser där varje matris är 100x100. Då får jag ganska mycket att lagra på minnet.

I slutändan så tror jag det inte blir så bra idé. GNU Scientific Library använder sig av allokerade matriser.

Om du använder 1 matris på 2x2 så blir det väldigt enkelt att lagra

Ibland 36x36, ibland inte. Men max är 36x36 för just det program jag tänker använda. Men det blir många matriser.

Eller menar du att jag ska endast ha vissa statiska matriser för vissa enskilda funktioner typ som jag har gjort med filen det.c. Ta en titt på den.

Och du behöver alla matriser samtidig?

Nej. En åt gången, ibland 3, max 4 tror jag. Aha! Då förstår jag. Skapa globala matriser?

Eller så har man en fix 100x100 matris i en struct, tillsammans med storleken på datan i matrisen. Så om matrisen är 100x100, så är datan t.ex. 4x6. Sedan så skickar man runt adressen med strukturen till olika funktioner.

Du måste testa och/eller uppskatta hur många matriser du behöver kunna använda samtidigt.
I den senaste testkoden använder du som mest 12st matriser samtidigt (och det går att optimera till betydligt färre), men du gör 5545 allokeringar istället för att återanvända minnet.

Jag skyller på bekvämligheter. Det är svårt att skapa ett bibliotek som använder sig av statiska matriser.
Jag kan göra så att man max kan använda 10 matriser samtidigt. Nackdelen är att om jag vill ha matrisen i en struktur så måste jag allokera minnet. Annars går det inte.

Hm....

Det jag verkligen skulle kunna göra är att jag använder endast statiska matriser i svd.c, ini.c, qr.c och lu.c filerna. Förutom argumenten förstås. Där skulle jag kunna spara mycket minne.

Men frågan är hur mycket tid jag vinner. Jag kanske förlorar tid. Jag vet varför malloc inte ska användas inom inbyggda system och det har med att det kan vara lättare att göra fel med minnet om man inte hanterar det.

Jag testade att göra lite matrixberäkningar med att använda statiska matriser......mmmm...såg inte så bra ut. Det var mer bök och mer kodskrivning och skriva in dimensioner manuellt. Så jag föredrar att använda malloc, än fast det kan innebära risker för inbyggda systemet. Men men, med dagens utvecklingsverktyg så kan den skanna av projektet och peka på fel.

Varför måste du allokera minnet för att du har det i en struct?