Matrisberäkningar med för STM32?

[mrfrenzy]

Mer troligt är alternativ 5. Det är inget fel på programmeringsspråket men du saknar fortfarande viss programmeringskunskap.
Tyvärr kom jag aldrig i närheten av så långt som dig i matematikkurserna så jag kan inte hjälpa till.

Fortsätt att kämpa med programmeringen så kommer du lösa det med exakt rätt resultat oavsett om du använder C eller C++.
Eller hoppas på att någon dyker upp här i tråden som både kan programmering och matriser.

[Al_Bundy]

Jag tror du har fel.

Jag testade mitt bibliotek med C och det gav ett annat resultat som GNU Octave gav. De två första värderna är exakt som GNU Octave, C och C++ visar. Det är dem två som är viktiga i mitt fall. Men det vore bra om beräkningen av exakt samma resultat. Där efter testade jag med Armadillo C++ och dess inbyggda funktioner. Då visade SVD-funktionen väldigt lik resultat som mitt C bibliotek gav ut. Armadillo's SVD var något mer "korrekt" på små små små värden. Men i övrigt så visade dem det samma.

Så det betyder inte att jag gjorde fel eller programmerade fel. Hur stor sannolikhet är att Armadillo och jag ska göra exakt samma fel vid exakt samma data?

Jag tror nu att det är inget fel, utan det är helt normalt beteende det här från datorvärden.

[mrfrenzy]

Ett av syftena med armadillo är just att kunna portera matlab-grejer. Självklart ska det då bli samma resultat. Enligt deras hemsida tar dom gärna emot buggrapporter:

Please make a small and self-contained program which exposes the bug, and then open an issue at the GitLab repo, or inform the developers via email. The small program should have a main() function and use only functions/classes from Armadillo and the standard C++ library (no other libraries). We appreciate your time to make a bug report.

Prova alltså att skicka dom ditt matlab-program och armadilloprogram som ger olika resultat så lär du få svar på varför det blir fel resultat.

[Al_Bundy]

Japp. Då kanske man får ett svar på varför mitt C program också visar samma resultat som Armadillo

[Al_Bundy]

Om man nu ska skriva om sitt bibliotek så dem verkligen passar inbyggda system. Det krav jag måste ha är att man måste minst initialisera matriser och sedan återanvända dem. Det har med att C kan egentligen inte passera 2D arrayer igenom funktioner om man inte redan deklarerar storleken på argumentet i funktionen, vilket jag tycker är värdelöst.

Men hur blir det med memcpy och memset? Är dem OK inom inbyggda system?
Hur blir det med varningar eller errormeddelanden som leder till exit(1)? Jag tänkte att man simulerar först i PC och ser det bra ut, så klistrar man in C-koden i uC:n och kör.

Hur blir det med arrayer som deklareras olika storlekar, utan malloc? t.ex. denna mat[n][n] matris. Variabeln n kan ju ändra sig under körningen.

Kod: Markera allt

float det(matrix *a) {

	// Get dimensions of a
	int n = a->row;
	float* ptr = a->data;

	if (n == 1) {
		// 1x1 "matrix" - Just return the value
		return *(a->data);
	} else if (n == 2) {
		// 2x2 matrix - Easy
		return *(ptr + 0) * *(ptr + 3) - *(ptr + 1) * *(ptr + 2);
	} else if (n == 3) {

		// Don't change this! It works fine for 3x3 - Took me long time to write this
		return (*(ptr + 0)) * (*(ptr + 4)) * (*(ptr + 8))
				+ (*(ptr + 1)) * (*(ptr + 5)) * (*(ptr + 6))
				+ (*(ptr + 2)) * (*(ptr + 3)) * (*(ptr + 7)) -

		(*(ptr + 6)) * (*(ptr + 4)) * (*(ptr + 2))
				- (*(ptr + 7)) * (*(ptr + 5)) * (*(ptr + 0))
				- (*(ptr + 8)) * (*(ptr + 3)) * (*(ptr + 1));

	} else {

		float mat[n][n];
		float ratio;
		float determinant = 1; // Initial det value

		// We need to create the matrix into an array matrix, like a normal matrix again
		for (int i = 0; i < n; i++) {
			for (int j = 0; j < n; j++) {
				mat[i][j] = *((ptr + i * n) + j);
			}
		}

		// Gauss Elimination Easy and fast algorithm to find the determinant of a nxn matrix
		for (int i = 0; i < n; i++) {
			for (int j = 0; j < n; j++) {
				if (j > i) {
					// We cannot divide with zero
					if (mat[i][i] == 0){
						mat[i][i] = pow(2.2204, -16); // Same as MATLAB command eps
					}
					ratio = mat[j][i] / mat[i][i];
					for (int k = 0; k < n; k++) {
						mat[j][k] -= ratio * mat[i][k];
					}
				}
			}
		}

		// Find det
		for (int i = 0; i < n; i++) {
			determinant *= mat[i][i];
		}

		return determinant;
	}

}

[JimmyAndersson]

Intressant tråd!
Inte för att jag kan de individuella delarna av matten, men jag förstår principen. Därför blir inlägget ganska abstrakt, men det blir lättare för mig att tänka sånt här då.


Jag tillhör de som inte tror att det är språket som är problemet.
(Rent statistiskt så borde fler ha märkt ett fel,
men det händer definitivt att man råkar hitta en bugg i något som hundratusentals personer har använt länge. Jag har varit med om det tre gånger.)
- Men det är kanske inte det första man bör undersöka vid ett fel.

Jag tror inte heller att det är själva programmet/beräkningarna som är fel. Möjligen någon ”avrundning” som görs olika i olika system. (Float/Double t.ex.)
För först går det ju bra, men sedan får du något knasigt som dalar ut mer och mer. Nästan som om du hade resonans eller någon logaritmisk funktion.


Har du gjort betydligt mindre test-case?
Något program som bara gör 1 styck jätte-enkel beräkning av redan små tal, för att se om du får ut det du stoppar in.

Som någon skrev så är det knepigt med så här små tal. Förr eller senare får man inte ut något användbart. Det blir ungefär som brus.


Hoppas det löser sig. Fortsätt kämpa, för jag vill se vad felet berodde på.

[Al_Bundy]

Jag har kollat datan in och den är EXAKT till 1000000% stämmer överens för GNU Octave och mitt C-bibliotek och Armadillo. Men datan ut från SVD stämmer inte med GNU Octave, men den stämmer med mitt C-bibliotek och Armadillo.

Alltså är det SVD som är "felet" på, om det ens är ett fel. Jag tror också det har med avrundningar att göra.

[Shimonu]

Matlab kör också med double precision flyttal och har då samma begränsningar som C och C++. Det som kan skilja är metoderna för att göra operationer som multiplikation eller division av flyttal. Eftersom det inte finns en FPU som klarar den storleken är de beroende av bibliotek för att hantera det. Om vi ska spekulera i språkens begränsningar. Men rimligtvis bör samma resultat vara uppnåbart. GNU Octave kanske har några häftiga ess i rockärmen för att beräkna och lyckas undvika dumma avrundningar och följdfel i beräkningarna. Det är också en del av programmering, att förstå hur fel kommer fortplanta sig och hur man undviker det.

Något värt att testa är som någon nämnde att försöka med ett mindre problem. Gör mindre matriser och ser hur de skiljer sig mot de andra biblioteken. Då kan du lättare analysera vissa delar av koden, du kan debugga och stega igenom varenda beräkning.

[mrfrenzy]

Går det göra ett exempel med en liten matris typ 2x2 som är så enkelt att en vanlig programmerare med endast Matematik C förstår och kan räkna ut det på papper?
Blir det också fel resultat när man beräknar med armadillo?

[Rick81]

Den stora frågan är väl hur nogrannt du behöver reglera? gör ett tal på e-5 någon skillnad mot 0? Har svårt se att du kan styra ett reglersystem med den noggrannheten?

Kan du plotta grafer med de olika lösningar då du ser om du får stigtid, översläng etc.

[hawkan]

Octave använde väl en annan numerisk metod? Då är det naturligt att det blir annat svar.
Flyttalsberäkningar är av naturen ej exakta i meningen exakta, det finns alltid ett pyttelitet fel ute i decimalerna och det måste man hantera.

[Al_Bundy]

Matlab kör också med double precision flyttal och har då samma begränsningar som C och C++. Det som kan skilja är metoderna för att göra operationer som multiplikation eller division av flyttal. Eftersom det inte finns en FPU som klarar den storleken är de beroende av bibliotek för att hantera det. Om vi ska spekulera i språkens begränsningar. Men rimligtvis bör samma resultat vara uppnåbart. GNU Octave kanske har några häftiga ess i rockärmen för att beräkna och lyckas undvika dumma avrundningar och följdfel i beräkningarna. Det är också en del av programmering, att förstå hur fel kommer fortplanta sig och hur man undviker det.

Något värt att testa är som någon nämnde att försöka med ett mindre problem. Gör mindre matriser och ser hur de skiljer sig mot de andra biblioteken. Då kan du lättare analysera vissa delar av koden, du kan debugga och stega igenom varenda beräkning.

Går det göra ett exempel med en liten matris typ 2x2 som är så enkelt att en vanlig programmerare med endast Matematik C förstår och kan räkna ut det på papper?
Blir det också fel resultat när man beräknar med armadillo?

För mindre matriser fungerar det utmärkt. Det har jag testat.

Den stora frågan är väl hur nogrannt du behöver reglera? gör ett tal på e-5 någon skillnad mot 0? Har svårt se att du kan styra ett reglersystem med den noggrannheten?

Kan du plotta grafer med de olika lösningar då du ser om du får stigtid, översläng etc.

Ingen stor noggrannhet. Men orsaken varför jag drar upp detta ämne har med att jag utgår från GNU Octave som en referens.

Octave använde väl en annan numerisk metod? Då är det naturligt att det blir annat svar.
Flyttalsberäkningar är av naturen ej exakta i meningen exakta, det finns alltid ett pyttelitet fel ute i decimalerna och det måste man hantera.

Octave använder andra numeriska metoder ja. Men det ska ändå bli samma.

Ska man ha kvar errormeddelanden i inbyggda system?
Hur blir det med statiska arrayer som har olika dimensioner? Se mat[n][n] ovan.

[Shimonu]

Har du stegat upp i storlek och sett var det börjar skilja sig?

Varför ska det bli samma när man använder andra metoder?

[Al_Bundy]

När jag använder enklare matris med enklare data så blir det rätt svar.

[Shimonu]

Ja men bara för att ett fall fungerar så betyder det inte att alla fall fungerar. Vill du hitta orsaken får du ju utreda varför det blir annorlunda resultat.