lösung mit lagrange...

[1unitedpower]

(eine selbst implementierung von splins würde ich nicht vornehmen, da baut man zuviele schlecht debugbare fehler rein):

Naja, ob dein Programmcode schlecht oder gut zu debuggen ist, ist keine Frage, die sich ausschließlich aus der Problemstellung ergibt. Man kann mit methodischen Vorgehen dafür sorgen, dass Programmcode immer eine Codequalität erfüllt, auf deren Basis das Debuggen leicht fällt. Testdriven-Development und continious Refacotoring sind zwei sehr bekannte und weit verbreitete Methoden.

Und mal ehrlich, mathematische Funktionen sind wirklich gutmütig und extrem einfach zu testen. Sie sind von Natur aus idempotent, haben also keine Nebenwirkungen, sie sind von Natur aus referenziell transparent, ergeben also für die selben Eingangsdaten immer die selben Ausgangsdaten. Das ist der Traum eines jeden Unittest-Designers, man muss keine komplizierten Umgebugnen mocken und kann sehr einfache Testfälle konstruieren.

Ich möchte dir gar nicht widersprechen und sagen, man solle auf seine eigene Implementation bauen, es gibt viele gute Gründe dafür, bestehende und erporbte Softwaremodule wiederzuverwenden, aber das Argument, das du hier in die Diskussion einbringst, ist so nicht haltbar.