Überlauf in den Funktionen Index2.LengthSquared() und Index3.LengthSquared()

[ASSOLI]

Hallo Tom, habe begonnen fehlende Tests im Projekt zu ergänzen so das man später auch sagen kann das Octoawesome auch Qualität hat.

Dabei ist mir in den der Index2.LengthSquared() und Index3.LengthSquared() Funktionen ein Fehler aufgefallen. Diese verursachen eine Überlauf wenn die Koordinaten zu groß werden. Dies beginnt rechnerisch bei der Index2 Funktion ab 32767 und bei der Index3 Funktion ab 26754. Da du die Index3.LengthSquared() bei der Berechnung der Render-Reihenfolge benutzt, kann es hier zu Fehler in der Reihenfolge kommen.

Mein Vorschlag währe in dieser Funktion mit double zu Rechnen um keinen Überlauf zu erzeugen.

//public int LengthSquared() public double LengthSquared() { //return (X * X) + (Y * Y) + (Z * Z); return (double)X * X + (double)Y * Y + (double)Z * Z; }

Bei der Index2 Funktion würde long reichen.

Oliver

[jvbsl]

da diese Funktion relativ oft verwendet wird, würde ich auf int bleiben und die Fehlerverhinderung auf einer höheren Ebene zu übernehmen, Idee hab ich aber entsprechend atm. keine spezifische(mW wird die Längenberechnung auch immer nur im lokalen Bereich verwendet)

[tomwendel]

Oh. Das ist interessant. Vielen Dank Oliver.

Ich muss mir die Verwendung der Methoden mal ansehen. Ich stelle mir nämlich aktuell die Frage warum bei einer Entfernungsberechnung überhaupt int zurück kommt. Ich gebe Julian grundsätzlich recht - die Performance für double ist langsamer, aber ein Fehlerbehandlung vom typ try/catch ist noch viel, viel schlimmer.

Ich finde Olivers Vorschlag solide. long für Index2 und double für Index3. Da müssten wir mal schauen ob wir die Präzession überhaupt brauchen.

Ein Schritt weiter: Wir könnten die Compare-Methoden überschreiben und da was passendes implementieren. Die Abfragen die wir machen sind nämlich immer vom Typ (index1.Length().CompareTo(index2.Length())