Rechnen in C

Besucher Gast #5480718
Lesenswert?
• ▲
▼ 
Hallo ins Forum

Ich hab ein Problem mit der Matrix multiplikation in C: bei der eingabe 
der ersten Matrix wird der Wert 3. Zeile 3. Spalte nicht abgefragt, bei 
der zweiten passt alles. Woran liegt der Fehler ?

Vielen Dank für die Hilfe

1
#include <stdio.h>

2
#include <conio.h>

3
 

4
 

5
int main(void)

6
{

7
float a[3][3],b[3][3],c[3][3], matrix;

8
int i,j,k;

9
 

10
printf("\n erste Matrix:");

11
for(i=1;i<=3;i++)

12
{

13
    for(j=1;j<=3;j++)

14
    {

15
        printf("\n %d. Zeile und %d. Spalte : ", i,j);

16
        scanf("%f",&matrix);

17
        a[i][j]=matrix;

18
    }

19
}

20
printf("\n zweite Matrix:");

21
 

22
for(i=1;i<=3;i++)

23
{

24
    for(j=1;j<=3;j++)

25
    {

26
        printf("\n %d. Zeile und %d. Spalte : ", i,j);

27
        scanf("%f",&matrix);

28
        b[i][j]=matrix;

29
    }

30
}

31
  for(i=1;i<=3;i++)

32
  {

33
    for(j=1;j<=3;j++)

34
    {

35
     

36
      c[i][j] = 0;  

37
      for(k=1;k<=3;k++)

38
      {

39
      c[i][j]+=a[i][k]*b[k][j];

40
      }

41
    printf("\nc[%d][%d]=%f", i,j,c[i][j]);

42
    }

43
  }

44


45
return 0;

46
}
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Yalu X. Moderator #5480789
Lesenswert?
• ▲
▼ 
Einige Compiler weisen auf den Fehler hin. So z.B GCC bei einer
Optimierungsstufe >0:


1
...

2
test.c:17:16: warning: iteration 2 invokes undefined behavior [-Waggressive-loop-optimizations]

3
         a[i][j]=matrix;

4
         ~~~~~~~^~~~~~~

5
test.c:13:5: note: within this loop

6
     for(j=1;j<=3;j++)

7
     ^~~
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Walter T. #5481627
Lesenswert?
• ▲
▼ 
Rolf M. schrieb:
> Empfohlen wird, generell immer double zu nehmen, wenn man keinen
> besonderen Grund hat, das nicht zu tun.

Auf einer 64-Bit-Plattform mit 64-Bit-FPU stimme ich Dir uneingeschränkt 
zu.

Auf einer 32-Bit-Plattform würde ich das nach dem Einzelfall abwägen. 
Bei numerisch stabilen Systemen (z.B. einem eindimensionalen Regler) 
spricht viel dafür, die native Bitbreite zu nutzen.

Bei Systemen, bei denen Matrizenrechnung erforderlich ist, neigt man 
allerdings dazu, erst einmal jede Menge "Library"-Funktionen zu 
schreiben, wenn man nicht schon auf eine fertige Library (z.B. LAPACK 
oder BLAST) zurückgreifen kann. Und fast zwangsläufig stößt man dann 
irgendwann auf eine Bedingung (schlechte Konditionierung), bei der 
normale Genauigkeit einen Rangabfall erzeugt, wo mit doppelter 
Genauigkeit noch genügend Sicherheitsmarge vorhanden gewesen wäre. Viel 
Spaß beim Suchen. BDDT.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Rolf M. #5485099
Lesenswert?
• ▲
▼ 
Walter T. schrieb:
> Rolf M. schrieb:
>> Empfohlen wird, generell immer double zu nehmen, wenn man keinen
>> besonderen Grund hat, das nicht zu tun.
>
> Auf einer 64-Bit-Plattform mit 64-Bit-FPU stimme ich Dir uneingeschränkt
> zu.
>
> Auf einer 32-Bit-Plattform würde ich das nach dem Einzelfall abwägen.
> Bei numerisch stabilen Systemen (z.B. einem eindimensionalen Regler)
> spricht viel dafür, die native Bitbreite zu nutzen.

Ok, bei einem µC muss man natürlich die Möglichkeiten der spezifischen 
Hardware mit in Betracht ziehen. Ich hatte jetzt irgendwie nur an den PC 
gedacht.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter D. #5485161
Lesenswert?
• ▲
▼ 
Barrex schrieb:
> Auf einen Mikrocontroller ohne Gleitkomma-Unit würde ich nur mit integer
> also mit Festkommazahlen arbeiten. :-P

Das kann man nicht generell sagen. Es kommt darauf an, wie schnell und 
genau die Regelung sein muß. Ich habe gemerkt, daß eine Regelung ohne 
float sehr leicht ungenau wird (Rundungsfehler) oder übersteuert.
Float muß auch nicht viel langsamer als int sein. Man spart sich ja die 
ständigen Skalierungen ein, die bei int für hohe Genauigkeit nötig sind.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
PittyJ Gast #5485955
Lesenswert?
• ▲
▼ 
Barrex schrieb:
> Auf einen Mikrocontroller ohne Gleitkomma-Unit würde ich nur mit integer
> also mit Festkommazahlen arbeiten. :-P

Ich muss einmal pro Sekunde einen Winkel auf einem Arm-M0 ohne FPU 
berechnen. Dafür nehme ich die Emulation, das ist immer noch schnell 
genug.
Sowas hat früher selbst ein C64 locker gemacht.

Es kommt immer auf den Anwendungsfall an.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
c-hater Gast #5501656
Lesenswert?
• ▲
▼ 
Peter D. schrieb:

> Das kann man nicht generell sagen. Es kommt darauf an, wie schnell und
> genau die Regelung sein muß. Ich habe gemerkt, daß eine Regelung ohne
> float sehr leicht ungenau wird (Rundungsfehler) oder übersteuert.

Dann war sie beschissen umgesetzt.

> Float muß auch nicht viel langsamer als int sein. Man spart sich ja die
> ständigen Skalierungen ein, die bei int für hohe Genauigkeit nötig sind.

So ein grenzdebiler Blödsinn. Der Funktionsmechanismus von 
Gleitkommatypen beruht doch gerade darauf, ständig Skalierungen 
anzuwenden. Was natürlich zu ganz genau denselben Problem führt, nur 
weniger kontrollierbar, als wenn man das selber abhandelt (und dabei 
natürlich so viele Bits verwendet, wie sie auch das float-Format 
bietet).

Dann kann man nämlich exakt steuern, wann man die Größenordnung (in 
float also: den Exponenten) wechselt und ist nicht auf die überhaupt 
nicht an das konkrete Problem angepaßten Entscheidungen der float-lib 
angewiesen.

Float ist was für Leute, die zu faul sind, selber zu denken und die zu 
faul sind, selber Mathematik zu implementieren.

Der Vorteil von Float ist: es ist für viele Anwendungsfälle gut und 
schnell genug. Der Nachteil von Float ist: es ist praktisch immer 
suboptimal bezüglich der Laufzeit.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
S. R. #5502162
Lesenswert?
• ▲
▼ 
c-hater schrieb:
> Der Vorteil von Float ist: es ist für viele Anwendungsfälle gut und
> schnell genug. Der Nachteil von Float ist: es ist praktisch immer
> suboptimal bezüglich der Laufzeit.

Das hängt von der Hardware ab. Auf aktuellen ARM-Prozessoren (und damit 
meine ich jetzt die dicke Ausführung für Android) ist Float-Arithmetik 
meistens schneller als Integer-Arithmetik.

Java- oder Javascript-Programmierer machen nämlich nur 
Double-Arithmetik, und deren Code stellt die Mehrheit dessen, was auf 
diesen CPUs läuft. Folgerichtig wird dort massiv Silizium investiert.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
user Gast #5502164
Lesenswert?
• ▲
▼ 
S. R. schrieb:
> c-hater schrieb:
>> Der Vorteil von Float ist: es ist für viele Anwendungsfälle gut und
>> schnell genug. Der Nachteil von Float ist: es ist praktisch immer
>> suboptimal bezüglich der Laufzeit.
>
> Das hängt von der Hardware ab. Auf aktuellen ARM-Prozessoren (und damit
> meine ich jetzt die dicke Ausführung für Android) ist Float-Arithmetik
> meistens schneller als Integer-Arithmetik.
>
> Java- oder Javascript-Programmierer machen nämlich nur
> Double-Arithmetik, und deren Code stellt die Mehrheit dessen, was auf
> diesen CPUs läuft. Folgerichtig wird dort massiv Silizium investiert

Git es dafür Beweise?
Warum sollte man in Java Double verwenden?
Bei Finanz-Berechnungen will man keine Fließkommazahlen verwenden!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren