Icecap skrev:Som jag fattar det ger dessa matrix-beräkningar en bild av systemets reaktion på input vilket då blir en typ matematisk beskrivning av regleringen.
Alltså inget mashine-learning eller liknande, bara gammal hederlig matematik - som förvisso kan vara mycket effektiv.
Jag antar att man kan ha "kvar" en matrix som summerar under tiden och som är "bilden" av systemet, att dynamisk bild som anpassas eftersom.
Men det är bara vilda gissningar.
Finns inget häftigt med machine learning. Det är bara automatiserad statistik och regression. Jag håller på med ämnet systemidentifiering, vilket ger samma resultat som machine learning.
Rick81 skrev:Gissar att du får sämre noggrannhet i beräkningen, kanske det du ser när du jämför.
Jag är fortfarande nyfiken på hur du tar fram systemets ekvation. Du skrev nåt om machine learning, kan du förklara hur denna process går till?
Jag kommer lägga upp min kod här lite senare. Då kan ni få se på hur jag har tänkt det som.
Någon som känner sig manad med att hjälpa mig att hitta buggar efter jag har släppt lös denna C-kod? Ni måste ha GNU Octave installerat. Det kommer mest bara vara grundläggande matrisalgebra som ska testas.
Desto fler vi är, desto lättare kan vi hitta buggar.
Varför lägger du inte bara ut det på lämplig git sida så kan ju alla som får en stund över provköra och komma med förbättring förslag på ett hanterbart sätt?
Vi är väl några stycken som skulle kunna testa tänker jag.
Lägga det på github hade varit toppen, men har man aldrig gjort det
så är det en hel del att ta in.
Dem kommer inte äta upp något. Jag har koll på dimensionerna. Det jag menar är om jag t.ex "misshandlar" minnet om jag använder olika dimensioner på vanliga arrayer?
Om en array är deklarerat som t.ex. 100x100 float kommer den att uppta 10000 float-platser i minnet. Hur du sedan adresserar den har inte med saken att göra, minnet finns där ändå.
Du kan komma åt det minne vid att deklarera antingen en 'union' eller ett antal typedef's som sedan pekas på samma minne.
Men om du kör med fasta storlekar - men att storleken kan ändras med projektet - är det ju bara att deklarera storleken i en deklaration och sedan låta hela programmet ta del av den deklaration.
Typ:
#define SQUARE_SIZE 36
float My_Array[SQUARE_SIZE][SQUARE_SIZE];
Alla for() använder sedan SQUARE_SIZE som basvärde osv. Lite mer jobb att skriva in men sedan brukar det vara skottsäkert.
Icecap skrev:Men om du kör med fasta storlekar - men att storleken kan ändras med projektet - är det ju bara att deklarera storleken i en deklaration och sedan låta hela programmet ta del av den deklaration.
Jo det här är ju det smidigaste och stabilaste. Men jag får intrycket att han vill ha ett generiskt bibliotek där storleken anges vid körning. (Med reservation för att jag kan ha misstolkat syftet)
I mina projekt som använder samma kretskort har jag i varenda projekt en fil: Project_Settings.h
Där skriver jag in alla dessa saker som har med projektet att göra och alla funktions-filer refererar till den fil.
Den kan innehålla t.ex.:
#define USE_HOCO50MHZ // Ställer intern oscillator till 50MHz i HARDWARE_100.h
#define USE_RS232_A // Aktiverar Ser1 i Standard_RS232_A_100.h samt enabler de interrupts som behövs
osv osv.
På det vis har jag "standard" filer som slår på kommunikation med RTC, EEPROM, 1-Wire®, RS232 A & B, RS485, korthållsradio, WLAN, LAN, PWM för displayintensitet och vad jag annars kan behöva.
Ett projekt kan för mig innehålla kanske 7-8 filer i själva källfilsbiblioteket och resten (20 st?) ligger i mitt arbetsbibliotek\Functions.
På det vis har jag välfungerande debuggade funktioner som kan ganska mycket och har vissa inställningar som kan ändras via data i Project_Settings.h.
Och Project_Settings.h är unik för varje projekt.
Jag påstår inte att detta är den bästa metod - men den är sjukt smidig, jag startar ett projekt på 3 minuter, då är stommen uppe att köra, alla portar ställd rätt, alla interfaces och interrupt i rätt läge och jag kan börja med "det riktiga program" direkt.
Ska Al skapa en stomme för sitt program anser jag att det borde vara den rätta vägen att gå: en "universell" fil(-set) som kan återanvändas, är testat och välfungerande. Då släpper man uppfinna hjulet gång efter gång.
