3. Benennung von distance/squared_distance und weiteren Hilfsfunktionen

Benennung von distance/squared_distance und weiteren Hilfsfunktionen

  • ?

    Gibt es irgendeine Standardbenamsung von folgenden Hilfsfunktionen, die immer wieder auftreten?

    double squared(double i) { return i*i; }
double squared_norm(point a) { return squared(a.x) + squared(a.y); }
double squared_distance(point a, point b) { return squared_norm(a-b); }
double real_norm(point a) { return std::sqrt(squared_norm(a)); }
double real_distance(point a, point b) { std::sqrt(squared_distance(a, b)); }

double cross_product(point a, point b) { return a.x*b.y-a.y*b.x; }
double relative_cross_product(point a, point b, point c) { return cross_product(b-a, c-a); }

    Verwendet jemand sogar Einheiten (Länge vs. quadrierte Länge) um Fehler ganz auszuschliessen?

    0
  • O

    Sowas nennt man eigentlich Methoden eines (mathematischen) Vektors. Üblicherweise wird dann auch eine Vektor-Klasse benutzt anstelle händisch mit Points rumzuhantieren.

    Einheiten sind was für Physiker 😛
    Mathematiker (dazu zähle ich auch Informatiker) brauchen das nicht. Natürlich sollte man immer die richtigen Datentypen nehmen - aber eine Fließkommazahl ist quadriert immernoch eine Fließkommazahl.

    0
  • B

    oenone schrieb:

    Einheiten sind was für Physiker 😛
    Mathematiker (dazu zähle ich auch Informatiker) brauchen das nicht.

    Es gibt auch Physiker die programmieren. 🙂
    Einheitenumrechnungen braucht man normalerweise maximal in der Oberfläche und bei der Ausgabe. So das der Nutzer beliebige Einheiten angeben kann.
    Intern, bei den Berechnungen, sollte man, um Fehler zu vermeiden, immer mit SI-Einheiten arbeiten.

    0
  • V

    wurzelhochzwei schrieb:

    Gibt es irgendeine Standardbenamsung von folgenden Hilfsfunktionen, die immer wieder auftreten?

    Hab gerade ein paar Bibliotheken angeschaut, die Vector3D oder so anbieten und einheitlich war's nicht gerade.

    Ich würde überlegen, weniger Funktionen anbieten und dem Aufrufer noch was lassen. (Vielleicht übertrieben jetzt, aber ungefär diese Richtung)

    double squared(double i) { return i*i; }//jo
double squared_norm(point a) { return squared(a.x) + squared(a.y); }//squared(point)
double squared_distance(point a, point b) { return squared_norm(a-b); }//squared(a-b)
double real_norm(point a) { return std::sqrt(squared_norm(a)); }//abs(point)
double real_distance(point a, point b) { std::sqrt(squared_distance(a, b)); }//abs(a-b)

double cross_product(point a, point b) { return a.x*b.y-a.y*b.x; }//jo
double relative_cross_product(point a, point b, point c) { return cross_product(b-a, c-a); }//nö

    wurzelhochzwei schrieb:

    Verwendet jemand sogar Einheiten (Länge vs. quadrierte Länge) um Fehler ganz auszuschliessen?

    Nö.

    0

  • oenone schrieb:

    Sowas nennt man eigentlich Methoden eines (mathematischen) Vektors.

    Nö. Das als freie Funktionen zu machen ist schon besser.

    oenone schrieb:

    Üblicherweise wird dann auch eine Vektor-Klasse benutzt anstelle händisch mit Points rumzuhantieren.

    Wie, händisch?
    Was ausser dem Namen ändert sich denn durch die Verwendung einer "Vektor" Klasse?

    0
  • Mod

    Braunstein schrieb:

    Intern, bei den Berechnungen, sollte man, um Fehler zu vermeiden, immer mit SI-Einheiten arbeiten.

    Programmier unabhängig von den Einheiten. Einheiten sind was für den Anwender.

    Was man machen kann, ist die Beachtung der Dimension von Werten, wie der Threadersteller vorschlägt. Das ist eine bekannte Methode, aber ich habe es weder selber je benutzt, noch irgendwo gesehen. Gründe:
    1. Bei fremder Software bin ich mir oft recht sicher, dass die Programmierer die Methode gar nicht kennen.
    2. Bei mir selber bin ich zu faul. Es ist Zusatzaufwand und die Art von Fehler, die dadurch vermieden wird, ist mir noch nie untergekommen. Ich benenne meine Variablen aussagekräftig.

    0

  • 3. Es ist schwer abzuschätzen wie oft man auf Anwenderseite dann blöd rumcasten müsste, weil man doch korrekterweise eine "verbotene" Konvertierung braucht.

    0
  • N

    Warum "real_norm" und nicht einfach "norm" oder, falls es nicht so mathe-lastig sein muss, "length"? Das "real" klingt irgendwie lächerlich.

    Dinge wie "relative_cross_product" sind höchstens nützlich, wenn sie exzessiv häufig und mit komplizierten Argumenten aufgerufen werden. Dadurch, dass man zuerst die Dokumentation lesen und herausfinden muss, welcher Parameter nun wie verwendet wird, ruft man als Benutzer lieber gleich "cross_product" auf, sodass auch jeder auf Anhieb den Code versteht.

    Generell sollte man APIs möglichst schlank designen und nicht einfach anbieten, was mal nützlich sein könnte, sondern auf konkrete Featurewünsche reagieren.

    Ich habe einen Teil der genannten Funktionen auch mal implementiert (in der Liste nicht auftretende hielt ich nicht für nötig, dafür hatte ich andere nützliche wie Skalarprodukt, Projektionen, Rotationen): square, length, squaredLength, crossProduct.

    0
  • T

    Nexus schrieb:

    Warum "real_norm" und nicht einfach "norm" oder, falls es nicht so mathe-lastig sein muss, "length"?

    Es gibt ja verschiedene Normen, das sollte auch beachtet werden. Deswegen würde ich es nicht einfach "norm" nennen.

    0
  • N

    Wenn es so mathematisch sein muss, dann nimmt man aber "euclidean_norm" oder "l2_norm". "real" ist in jedem Fall der falsche Ausdruck.

    Ich habe allerdings so meine Zweifel, dass hier Manhattan- oder p-Norm benötigt werden. Daher würde ich eher nicht "norm" verwenden (und wenn, dann ohne spezifische Bezeichnung).

    0
Anmelden zum Antworten