Svenska ElektronikForumet

mankan skrev:Om du gör en ny version av cut som du använder internt i t.ex. qr funktionen så kan du slippa malloc.

Kod: Markera allt

matrix* cutNoMalloc(matrix* a, int start_n, int stop_n, int start_m, int stop_m, matrix* out)

Implementationen jämfört med vanliga cut: ta bort första raden och behåll resten.

Sedan anropar du den så här:

Kod: Markera allt

float c2Data[n + 1];
matrix c2Stack = { n + 1, 1, c2Data};
matrix* c2 = &c2Stack;
c2 = cutNoMalloc(q, 0, n, k,k, c2);

Glöm inte att ta bort anropet till freeMatrix(c2) också.

Det går säkert skriva kortare och även göra ett makro för att snygga till det hela.

Jag tror inte det är malloc som ställer till segheten. Jag tror att det är dessa for-loopar som behöver gås igenom.

Det kanske inte var så smart att använda floats som flyttal i C, trots allt. Som ni ser här så visar Octave singulära värden på e-14 och e-15, medan C visar minst 0.000012, dvs 1.2000e-05.

Om inte double går att använda i STM32, då måste jag köra på heltal hela tiden? Eller hur? Orsaken varför jag inte har valt heltal, har med att jag jobbar med analoga värden. Så jag har nu krockat och funderar på att byta språk samt plattform om inte något mirakel sker.

Det finns många olika typer/implementeringar av "float" beroende på plattform o.s.v.
Det kan vara något i rutinerna som ger avrundningsfel eller liknande som sprider
sig upp till slutvärdena.

Vad är förresten "singulära värden"?

EDIT: Ah, det var ju lätt som en plätt...
http://www.maths.lth.se/matematiklth/pe ... 05/svd.pdf

> då måste jag köra på heltal hela tiden?

Om de korrekta värdena ligger vid e-14 och e-15, så kan det bli problem
med skalfaktorerna med heltals ("fixed point") aritmetik.

Singulära värden är icke-negativa värden. Jag brukar använda SVD för att beräkna och jag kan lova er att SVD är det bästa matrisverktyg någonsin. Man kan typ göra allt med det. Filtrera, lösa ekvationer, beräkna partiklar, beräkna statistik och machine learning osv.

Ja. Oftast kommer dessa värden ligga mellan e-7 och e-16. Dem har ganska stor betydelse då man tar roten ur matriser, vilket blir rätt stora tal om dem är små. Sista utvägen är att gå tillbaka till Java igen.

Kolla databladet. Stm32f7, stm32h7 har fpu med double. Kanske har stm32f4 det också. Annars rekommenderar jag igen devkitet med stm32h7 för 200 kr....

stm32f4 är baserad på cortex-m4

https://www.digikey.se/en/product-highl ... gLH-fD_BwE

Cortex-m4 har single-precision FPU
https://www.st.com/content/ccc/resource ... 047230.pdf

Då kanske Nucleo 144 passar mig.

Nucleo 144 specar inte vilken processor det är, bara att det är ett Nucleos kort med en 144 pinnars kapsel.
Och det kan man få tex en F4 i också.. (Vilket väl var det du redan körde?)

Har du satt några brytpunkter och stegat igenom koden för att verifiera att det inte finns någon bugg? Är anledningen till att du får 10^-5 istället för 0,0 eller 10^-15 endast att beräkningarna körs på float och inte double?

Är det möjligt att tvinga Matlab/Octave att göra alla beräkningar på 32-bit floats?
I så fall kan du ju jämföra resultatet.
Inom bilindustring används ofta Matlab/Simulink för att utveckla algoritmer. Och sedan brukar man generera C-kod direkt från Simulink, och lägga denna på mikrocontrollern. Men för att öka hastigheten måste man gå från Matlabs double till 32-bit float, eller oftast 16/32-bits heltal/fast kommatecken. Och då finns det verktyg för att jämför double-beräkningarna och den reducerade implementeringen. Man kan plotta grafer och se hur mycket precision som försvinner och så. Det behövs sällan så många decimalers precision för att få ett bra resultat i praktiken.

Jag är tyvärr inte så insatt i dessa matrisalgoritmer (svd, qr) mfl. Men ofta går saker och ting att optimera när det väl ska implementeras. Kanske gör dessa algoritmer en del generella beräkningar som i slutändan inte behövs för att nå resultatet som söks. Och då går det sannolikt att snabba upp implementeringen om det behövs, genom att skriva en specialfunktion som tar hand om det aktuella fallet.

AndLi skrev:Nucleo 144 specar inte vilken processor det är, bara att det är ett Nucleos kort med en 144 pinnars kapsel.
Och det kan man få tex en F4 i också.. (Vilket väl var det du redan körde?)

Okej. Tack för informationen. Jag har en F401RE.

bearing skrev:Har du satt några brytpunkter och stegat igenom koden för att verifiera att det inte finns någon bugg? Är anledningen till att du får 10^-5 istället för 0,0 eller 10^-15 endast att beräkningarna körs på float och inte double?

Jag kör koden varje dag och hittills har jag inte hittat någon bugg.
Jag har inte verifierat om det skulle bli e-15 om jag har double istället för float. Men troligtvis så är det datatypen som bråkar med mig.

Är det möjligt att tvinga Matlab/Octave att göra alla beräkningar på 32-bit floats?

The simplest form of a numeric constant, a scalar, is a single number. Note that by default numeric constants are represented within Octave by IEEE 754 double precision (binary64) floating-point format (complex constants are stored as pairs of binary64 values). It is, however, possible to represent real integers as described in Integer Data Types.

https://octave.org/doc/v4.4.0/Numeric-Data-Types.html

I så fall kan du ju jämföra resultatet.
Inom bilindustring används ofta Matlab/Simulink för att utveckla algoritmer. Och sedan brukar man generera C-kod direkt från Simulink, och lägga denna på mikrocontrollern. Men för att öka hastigheten måste man gå från Matlabs double till 32-bit float, eller oftast 16/32-bits heltal/fast kommatecken. Och då finns det verktyg för att jämför double-beräkningarna och den reducerade implementeringen. Man kan plotta grafer och se hur mycket precision som försvinner och så. Det behövs sällan så många decimalers precision för att få ett bra resultat i praktiken.

Jag har tyvärr inte dessa verktyg. Men jag känner väl till C-code generator ToolBox. Hur bra C-koden blir, vet jag inte.

Jag är tyvärr inte så insatt i dessa matrisalgoritmer (svd, qr) mfl. Men ofta går saker och ting att optimera när det väl ska implementeras. Kanske gör dessa algoritmer en del generella beräkningar som i slutändan inte behövs för att nå resultatet som söks. Och då går det sannolikt att snabba upp implementeringen om det behövs, genom att skriva en specialfunktion som tar hand om det aktuella fallet.

I detta fall är jag nöjd med just denna hastighet. Jag ska ju bara ha 1 sekunds samplingsintervall.

Är det någon som har fått mer information om hur malloc beter sig hos STM32? Jag menar, STM32 verkar vara i framkant på allt, så dem kanske har löst det där med minnesallokeringen?

Al_Bundy skrev: I detta fall är jag nöjd med just denna hastighet. Jag ska ju bara ha 1 sekunds samplingsintervall.

Då kanske det räcker att köra mjukvaruräknad double? Varför jaga prestanda när det finns gott om tid över?

Al_Bundy skrev:Är det någon som har fått mer information om hur malloc beter sig hos STM32? Jag menar, STM32 verkar vara i framkant på allt, så dem kanske har löst det där med minnesallokeringen?

Hur menar du med löst minnesallokeringen?
Det är nog enbart du som designar programmet som kan avgöra det.

Al_Bundy skrev:Är det någon som har fått mer information om hur malloc beter sig hos STM32? Jag menar, STM32 verkar vara i framkant på allt, så dem kanske har löst det där med minnesallokeringen?

Nu får du nog backa några steg, det finns ingen malloc hos STM32, malloc() är ett c-anrop. Frågan bör alltså vara, har aktuell kompilatortillverkare löst det på något annat sätt än att allokera minnet på heap:en.
Och har de löst det på något annat sätt för att microprocessorarkitekturen har någon smart feature för detta, svaret på den frågan i alla fall för IAR verkar vara nej.