Svenska ElektronikForumet

Al_Bundy skrev:Du ska inte säga så där. Du vet inte modellreducering är för något och hur det fungerar.

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.

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

Al_Bundy skrev:Det är detta som verkligen gör detta forum så unikt. 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.

Shimonu skrev:

Al_Bundy skrev:Det är detta som verkligen gör detta forum så unikt. 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.

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.