Organisatorisches zur Übungsabgabe

• Bitte Übungen nur 1x links oben klammern (einfacher und wirkungsvoller als Klarsichtfolie, Büroklammer oder gar Mappe)
• Programmcode und Testläufe unbedingt ausdrucken (z.B. in Raum KG 519 via Diskette)
• Testläufe mit Dateiumleitung machen statt Screenshots (brauchen meist viel Toner)
• Es gibt (gestaffelte) Abzüge falls Testläufe
  • manipuliert wurden (d.h. nicht zum Programm passen),
  • fehlen,
  • unvollständig sind.

Tutorium

Im Tutorium gibt es

• Nachbesprechung der alten Übungen
• Besprechung und Hilfestellung zur neuen Übung
• Hilfestellung bei Compiler (Fehlermeldungen etc.), Linux usw.

Typische Fehler zur 1. Übung

Konstanten

Konstanten wie pi oder Zinsfüße sollen als solche gekennzeichnet sein.

Falsch:
float zinsfuss = 5.3;

Richtig (aber nicht optimal):
#define zinsfuss 5.3;

Optimal:
const float zinsfuss = 5.3;

Datentypen geeignet wählen

Falsch:
float tage;

Richtig:
int tage;
oder
unsigned int tage;

Bemerkung: Man kann zwar auch nicht -2 Tage verzinsen, dank kürzerer Schreibweise wird aber auf unsigned gern verzichtet.

Testläufe...

... sind nicht nur Schikane des Praktikums. Sie dienen u.a. dazu, die Funktionsweise des Programms zu überprüfen, und damit Fehlern auf die Spur zu kommen. Dabei ist es wichtig, Testergebnisse zu interpretieren. Oft macht es Sinn, für sich selbst mehr Tests als vorgegeben durchzuführen und Kopf- bzw. Überschlagsrechnungen zu machen.

Beispiel (zu 1.):
Zinsfuß 5.3%, Kapital 100 Euro, 360 Tage, Ergebnis (Zins): 0.053 Euro
Das entsprechende Programm muß einen (Skalierungs-)Fehler in der Berechnung des Zins haben, 5.30 Euro herauskommen muß (Kopfrechnung).

Beispiel (zu 2.):
Radius 1.732, Kleinste Höhe 3, Größte Höhe 5, Winkel 30°, Ergebnis für Schwerpunkthöhe: 5.84617
Das Programm muß einen Fehler in der Berechnung der Schwerpunkthöhe haben, da der Schwerpunkt nicht außerhalb des Zylinders liegen kann (Interpretation).

Vorsicht bei Berechnungen mit ganzen Zahlen, insbesondere bei Divisionen

Ganze Zahlenkonstanten wie 1, 4, -14 werden vom Compiler als int interpretiert. Folglich ergibt 1/4 den Wert 0, weil eine Integerdivision durchgeführt wird.

Richtig:
1./4,
1./4.,
1.0/4.0
etc.

Tip:
Sobald in einer Formel Gleitkommazahlen oder -variablen vorkommen, alle ganzen Zahlen mit Komma versehen (1. statt 1); reduziert die Fehleranfälligkeit.

Bei Divisionen generell aufpassen (was ist gewollt):

int a, b;
[...]
cout << a/b << endl;

Richtig, falls wirklich die ganzzahlige Division gewollt ist,
falsch, falls ein Bruch gewollt war (dann type-casting verwenden: z.B. (double)a/(double)b.

Winkelfunktionen...

Rechenregeln

Die Auswertung von mathematischen Ausdrücken funktioniert wie beim Taschenrechner mit Punkt-vor-Strichrechnung von links nach rechts.

Beispiel: Bestimmung von

	a
c =	----
	2 b

Falsch:
c = a/2*b

Richtig:
c = a/(2*b)
oder
c = a/2/b

Redundante Berechnungen

In den Formeln für Volumen, Oberfläche und Schwerpunkthöhe in Beispiel 2 kommt die Berechnung von

• s1 + s2   viermal,
• r*r   dreimal

Unterschied zwischen pow(x, 2) und x*x

• pow(x, 2)
  Potenzbildung (etwa über exp(2 log(x)))
  Rückgabewert Compiler-abhängig: oft double, manchmal gleicher Typ wie x, manchmal bei int nicht compilier-fähig
• x*x
  einfache Multiplikation
  Rückgabewert abhängig vom Typ von x

Fallbeispiel:

int n;
long long int n2;
[...]
n2 = pow(n, 2);

pow(n, 2) liefert einen Wert vom Typ double oder float zurück. Dieser wird dann in einen int konvertiert (Vorsicht: evtl. werden Stellen abgeschnitten).

Richtig:
n2 = n*n;

Dieser Fehler kam gehäuft in Beispiel 3 vor. Siehe dazu das Programm pow-test.cc und die entsprechenden Ausgaben dort.

Globale Variablen/Konstantenvereinbarungen...

... sind nicht erwünscht und in den Beispielen auch nicht notwendig.

Falsch:

const float zinsfuss = 5.3;
int tage;
float kapital, zins;

void main ()
{
[...]

Richtig:

void main ()
{
const float zinsfuss = 5.3;
int tage;
float kapital, zins;

[...]