3. Probleme der Parameterbehandlung in umfangreicheren Programmen

1. Aufgabenspezifische Parameter
   Dies sind die üblichen Ein-/Ausgabeparameter einer Function. Sie werden in jedem Funktionsaufruf mit einem aktuellen Wert belegt, der die Daten der jeweiligen Aufgabe darstellt. Beispiele dazu wären:
   n,k = natürliche Zahlen, für die der Binimialkoeffizient berechnet werden soll; biko = Ergebnis der Berechnung.
   
   
2. Algorithmustypische Parameter
   Diese sind unabhängig von der konkreten Aufgabe und erhalten im Normalfall eine Standardbelegung für den Ablauf eines Algorithmus. Grundsätzliche  Änderungsmöglichkeiten für diese Klasse von Parametern sollen dennoch bereit stehen. Beispiele dazu wären:
   Lambda=ein Verfahrenskoeffizient; Epsi=Abbruchkriterium; Stepsize=Schrittweite.

Die einfache Möglichkeit, diese zweite Art von Parametern im aufrufenden  Programm  zu besetzen und die Werte per Funktionsaufruf zu übergeben, ist bei größeren Programmstrukturen aus folgenden Gründen unhandlich:

• zu lange Parameterlisten
  Da diese Parameter nicht in jedem Funktionsaufruf verändert werden sollen, sondern typisch für die gesamten Algorithmus sind, ist es unpraktisch, bei jedem Aufruf eine feste, lange Parameterliste zu übergeben. 
  Aber auch die Implementierung variabler Listen mittels varargin erschwert die Übersicht bei einer starken Verschachtelungstiefe.

• keine benutzerfreundliche Änderung der Parameter

Zum Testen verschiedener Parameterbelegungen müssten dazu jedes Mal im Quelltext des aufrufenden Programms Änderungen vorgenommen werden (z.B. stepsize=0.01 statt vorher 0.02). Diese Arbeitsweise ist fehleranfällig für versehentliche Änderungen in der Quelle eines sonst gut getesteten Programms, und man verliert leicht den Überblick über den Stand der durchgeführten Änderungen.

• zurück zur Startseite