Matrisberäkningar med för STM32?

PIC, AVR, Arduino, Raspberry Pi, Basic Stamp, PLC mm.
bearing
Inlägg: 11231
Blev medlem: 2 mars 2006, 01:01:45
Ort: Ängelholm

Re: Matrisberäkningar med för STM32?

Inlägg av bearing »

Al_Bundy skrev:Du ska inte säga så där. Du vet inte modellreducering är för något och hur det fungerar.
Det har ju inte riktigt med varandra att göra =)
Och jag jobbar inte i något projekt där jag behöver kunna det.

Många kan hjälpa dig. Du behöver bara formulera dom rätta frågorna, så kommer det lösa sig.
Användarvisningsbild
AndLi
Inlägg: 17048
Blev medlem: 11 februari 2004, 18:17:59
Ort: Knivsta
Kontakt:

Re: Matrisberäkningar med för STM32?

Inlägg av AndLi »

Jag tror inte det längre hjälper att ställa de rätta frågorna, efter alla dissningar och ignoreringa av svar på tidigare frågor...
Användarvisningsbild
Al_Bundy
Inlägg: 2889
Blev medlem: 11 september 2012, 23:59:50
Ort: The U.S - Chicago
Kontakt:

Re: Matrisberäkningar med för STM32?

Inlägg av Al_Bundy »

Det är detta som verkligen gör detta forum så unikt. :mrgreen: När det inte passar för "meningsmotståndaren" så är det frågeställaren som är fel på. Grova generaliseringar och små fina "pisk" på fingrarna för att söka lite uppmärksamhet i tråden.
bearing skrev:
Al_Bundy skrev:Du ska inte säga så där. Du vet inte modellreducering är för något och hur det fungerar.
Det har ju inte riktigt med varandra att göra =)
Och jag jobbar inte i något projekt där jag behöver kunna det.

Många kan hjälpa dig. Du behöver bara formulera dom rätta frågorna, så kommer det lösa sig.
Nu till svar.
Grejen är att C kunde inte tolka e-17 tal för Lapack. Redan där sprack det. GNU Octave kunde dessutom räkna ut inversen på stora matriser snabbare än vad C Lapack kunde göra. Jag vet inte hur, men troligvis har det med att GNU Octave har varit i branschen över 30 år så dem har nog lös detta problem för 20 år sedan säkert. Innan någon är snabb för att smälla mig på fingrarna "Men Lapack har varit med sedan 70-talet". Ja, men men fortfarande olika verktyg. Dessutom Lapack är Fortran som original.

Annars...så har jag fått kvadratisk programmering att fungera.

Jag minimerar

\($$\Phi_{min} = \frac{1}{2}X^TQX + c^TX$$\)

Med:
\(X_{min} \leq X \leq X_{max}\)
\(\Gamma X \leq Y_{min}\)
Markering_039.png
Plocka fram en tillståndsmodell, \(A,B,C\) och sedan bestämmer ni ett referensvärde \(r\) och begynnelsetillståndet \(x\) och hur långt ni vill titta i framtiden \(N\) t.ex 30 eller 40 iterationer framåt. \(minU\) är minsta insignal som får tillåtas t.ex. 0 och \(maxU\) är maximala insignal som får tillåtas t.ex. 255 eller 1023. \(maxY\) är maximala utsignal för systemet t.ex. 100 grader.

Kod: Markera allt


function [U] = mpc (A, B, C, x, N, r, minU, maxU, maxY)
  
  ## Find matrix
  PHI = phiMat(A, C, N);
  GAMMA = gammaMat(A, B, C, N);
  W = eye(size(GAMMA,1)); # Weight
  Q = GAMMA'*W*GAMMA;
  c = GAMMA'*W*PHI*x - GAMMA'*W*repmat(r, N, 1);
  LB = repmat(minU, N, 1);
  UB = repmat(maxU, N, 1);
  Ax = GAMMA;
  b = repmat(maxY, N, 1) - PHI*x;

  ## Solve
  U = quadprog(Q, c, Ax, b, [], [], LB, UB);
  
endfunction

function PHI = phiMat(A, C, N)
  
  ## Create the special Observabillity matrix
  PHI = [];
  for i = 1:N
    PHI = vertcat(PHI, C*A^i);
  endfor
  
endfunction

function GAMMA = gammaMat(A, B, C, N)
  
  ## Create the lower triangular toeplitz matrix
  GAMMA = [];
  for i = 1:N
    GAMMA = horzcat(GAMMA, vertcat(zeros((i-1)*size(C*A*B, 1), size(C*A*B, 2)),cabMat(A, B, C, N-i+1)));
  endfor
  
endfunction

function CAB = cabMat(A, B, C, N)
  
  ## Create the column for the GAMMA matrix
  CAB = [];
  for i = 0:N-1
    CAB = vertcat(CAB, C*A^i*B);
  endfor
  
endfunction
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
snigelen
Inlägg: 815
Blev medlem: 8 maj 2009, 11:02:14
Ort: Lund

Re: Matrisberäkningar med för STM32?

Inlägg av snigelen »

Octave använder LAPACK till matrisinvers. Och mycket mer...
Shimonu
Inlägg: 294
Blev medlem: 21 oktober 2015, 22:44:33

Re: Matrisberäkningar med för STM32?

Inlägg av Shimonu »

Al_Bundy skrev:Det är detta som verkligen gör detta forum så unikt. :mrgreen: När det inte passar för "meningsmotståndaren" så är det frågeställaren som är fel på. Grova generaliseringar och små fina "pisk" på fingrarna för att söka lite uppmärksamhet i tråden.
bearing skrev:
Al_Bundy skrev:Du ska inte säga så där. Du vet inte modellreducering är för något och hur det fungerar.
Det har ju inte riktigt med varandra att göra =)
Och jag jobbar inte i något projekt där jag behöver kunna det.

Många kan hjälpa dig. Du behöver bara formulera dom rätta frågorna, så kommer det lösa sig.
Nu till svar.
Grejen är att C kunde inte tolka e-17 tal för Lapack. Redan där sprack det. GNU Octave kunde dessutom räkna ut inversen på stora matriser snabbare än vad C Lapack kunde göra. Jag vet inte hur, men troligvis har det med att GNU Octave har varit i branschen över 30 år så dem har nog lös detta problem för 20 år sedan säkert. Innan någon är snabb för att smälla mig på fingrarna "Men Lapack har varit med sedan 70-talet". Ja, men men fortfarande olika verktyg. Dessutom Lapack är Fortran som original.
Det är precis dessa uttalanden som du bara slänger ur dig utan att veta vad du pratar om och varför du får motstånd. Jag visade dig att det gick att ha 128-bitars flyttal med C om man så vill.

Här till exempel förklaras att med single precision float(32-bitar) så går det att ha tal som är e-45 i storleksordning. Det har inget med C att göra eller som C ska klara av. C stödjer flyttal i alla möjliga storlekar.
https://stackoverflow.com/questions/321 ... rmat-range

Varför du hade problem med e-17 har med din implementation att göra. Sen är inte flyttal perfekta och kan inte representera alla värden men det är något du måste förstå då kring flyttal och kanske gå upp i precision. Har fortfarande inget med C att göra.
Användarvisningsbild
Glenn
Inlägg: 33667
Blev medlem: 24 februari 2006, 12:01:56
Ort: Norr om Sthlm
Kontakt:

Re: Matrisberäkningar med för STM32?

Inlägg av Glenn »

Man undrar ju lite hur albundy klarar sej i arbetslivet om han gör på samma sätt där.
Användarvisningsbild
Al_Bundy
Inlägg: 2889
Blev medlem: 11 september 2012, 23:59:50
Ort: The U.S - Chicago
Kontakt:

Re: Matrisberäkningar med för STM32?

Inlägg av Al_Bundy »

Jobbar inte med såna problem på arbetslivet. Som sagt så jobbar jag inom hydrauliken och smutsar ned mig i pumprummet ibland. Det som kallas för fin-jobb med lite ironi. ;)
Användarvisningsbild
Al_Bundy
Inlägg: 2889
Blev medlem: 11 september 2012, 23:59:50
Ort: The U.S - Chicago
Kontakt:

Re: Matrisberäkningar med för STM32?

Inlägg av Al_Bundy »

Shimonu skrev:
Al_Bundy skrev:Det är detta som verkligen gör detta forum så unikt. :mrgreen: När det inte passar för "meningsmotståndaren" så är det frågeställaren som är fel på. Grova generaliseringar och små fina "pisk" på fingrarna för att söka lite uppmärksamhet i tråden.

Det har ju inte riktigt med varandra att göra =)
Och jag jobbar inte i något projekt där jag behöver kunna det.

Många kan hjälpa dig. Du behöver bara formulera dom rätta frågorna, så kommer det lösa sig.
Nu till svar.
Grejen är att C kunde inte tolka e-17 tal för Lapack. Redan där sprack det. GNU Octave kunde dessutom räkna ut inversen på stora matriser snabbare än vad C Lapack kunde göra. Jag vet inte hur, men troligvis har det med att GNU Octave har varit i branschen över 30 år så dem har nog lös detta problem för 20 år sedan säkert. Innan någon är snabb för att smälla mig på fingrarna "Men Lapack har varit med sedan 70-talet". Ja, men men fortfarande olika verktyg. Dessutom Lapack är Fortran som original.
Det är precis dessa uttalanden som du bara slänger ur dig utan att veta vad du pratar om och varför du får motstånd. Jag visade dig att det gick att ha 128-bitars flyttal med C om man så vill.

Här till exempel förklaras att med single precision float(32-bitar) så går det att ha tal som är e-45 i storleksordning. Det har inget med C att göra eller som C ska klara av. C stödjer flyttal i alla möjliga storlekar.
https://stackoverflow.com/questions/321 ... rmat-range

Varför du hade problem med e-17 har med din implementation att göra. Sen är inte flyttal perfekta och kan inte representera alla värden men det är något du måste förstå då kring flyttal och kanske gå upp i precision. Har fortfarande inget med C att göra.[/quote]

Då skyller jag allt på Lapack för dem kunde inte lösa SVD med mycket data, vilket Octave kunde. Det är ju inte jag som har skrivit kod till Lapack i mitt bibliotek. Jag skrev bara ett användarsnitt.
snigelen
Inlägg: 815
Blev medlem: 8 maj 2009, 11:02:14
Ort: Lund

Re: Matrisberäkningar med för STM32?

Inlägg av snigelen »

Al_Bundy skrev:Då skyller jag allt på Lapack för dem kunde inte lösa SVD med mycket data, vilket Octave kunde. Det är ju inte jag som har skrivit kod till Lapack i mitt bibliotek. Jag skrev bara ett användarsnitt.
Det är exakt vad Octave-programmerarna gjorde också. Skrev ett användargränssnitt kring LAPACK alltså. Men de kanske vet vad de håller på med...

Citera bättre om du måste citera, Shimonu skrev det mesta av det du "påstod" att du skrev. Inte bra.
Senast redigerad av snigelen 27 mars 2019, 22:28:37, redigerad totalt 1 gång.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45173
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: Matrisberäkningar med för STM32?

Inlägg av TomasL »

Men det är du som implementerar det, och eftersom det inte fungerade, så är det fel i din implementation.
Dvs fel i din kod, och lösning.
Skriv svar