Verbesserung und Tipps zu Vektor Klasse

[this-*gt*that]

volkard schrieb:

Skalierung eines Vektors durch einen Vektor?

Habe ich nirgends geschrieben. Ich schrieb Skalarprodukt gefolgt von einer Skalierung. Denn wenn operator* das Skalarprodukt darstellt, dann ist v2*v2 ein skalar s und folglich die 2. Auswertung von operator*(float,Vector) eine Skalierung.[/quote]

Die Klasse bildet ein matehmatisches Objekt ab dessen Operationen eindeutig definiert sind.

So eindeutig ist das nicht. In manchen Skripts ist das * die Komponentenweise Multiplikation, manchmal das Skalarprodukt. Meistens werden 2 verschiedene Zeichen benutzt (* und .)

Das Produkt zweier Vektoren als Skalarprodukt anzunehmen halte ich fuer durchaus intuitiv aber das ist wohl Geschmackssache.

Ja, das ist Geschmackssache. Aber ich finde die Fausregel, dass die Semantik unmittelbar klar sein sollte, sinnvoll. Man könnte auch den Operator += eines Buttons überladen, um einen EventHandler zu registrieren. Finde ich aber unschön und ich würde eine registerEventHandler() Methode schreiben.

[otze]

hellihjb schrieb:

Die Klasse bildet ein matehmatisches Objekt ab dessen Operationen eindeutig definiert sind.
Das Produkt zweier Vektoren als Skalarprodukt anzunehmen halte ich fuer durchaus intuitiv.

Durchaus nicht.

Siehe: x^T*y vs x*y^T. Beides Vektormultiplikationen, aber beides unterschiedliche Ergebnisse. dann gibts natürlich noch x kreuz y. Auch das wird gerne als Multiplikation bezeichnet. Lustig wirds ja, wnen man dann fragt, was x*=y ist. Skalar kanns nicht sein. Matrix auch nicht...

Die komponentenweise multiplikation ist zwar auch nicht toll, aber im Bereich Farbe wird das gerne verwendet. Und macht zumindest mit der Operatorsemantik Sinn.

[volkard]

ich bin ziemlich sicher, daß der op[] von dir richtig ist. je nach compiler und geschmack kann man über sowas nachdenken

float& Vector3d::operator[](unsigned index) 
{ 
   assert(0<=index && index<=2);
   switch(index)
   {
      case 0: return x;
      case 1: return y;
      case 2: return z;
      default: __assume(false);   
   }
}

oder

float& Vector3d::operator[](unsigned index) 
{ 
   assert(0<=index && index<=2);
   assert(sizeof(*this)==3*sizeof(float));
   return index[&x];
}

Nett ist auch zusätzlich ein

float const& Vector3d::operator[](unsigned index) const;

[this-*gt*that]

@Melan: Jetzt find ichs auch ne schöne Vektor Klasse. Durch das Auslagern der "Algorithmen" schön schlank und übersichtlich.

Die Funktion Length() könntest du im Vektor lassen, denn die Länge ist eher eine Eigenschaft des Vektors, als eine Operation. Zusätzlich könntest du dann noch eine freie Funktion anbieten, die die Methode aufruft. Aus meiner Vektor Klasse:

template <class T>
inline float Vec3Length(const Vector3<T>& v) {
   return v.getLength();
}

Dein operator[] ist richtig. Ich würde aber noch ein assert(index < 3) einbauen.
Und die Parameter deiner freien Funktionen würde ich nicht by-value sondern als konstante Referenzen übergeben.

[otze]

this->that schrieb:

Die Funktion Length() könntest du im Vektor lassen, denn die Länge ist eher eine Eigenschaft des Vektors, als eine Operation.

Nö. Es gibt ziemlich viele verschiedene Längendefinitionen. Die bekanntesten sind norm1 (City-Block Metric), norm2( Euklidische Distanz) und normInf(maximum). Es gibt nicht "die" Länge. Deswegen kann sie keine Eigenschaft des Vektors sein.

[volkard]

otze schrieb:

this->that schrieb:

Die Funktion Length() könntest du im Vektor lassen, denn die Länge ist eher eine Eigenschaft des Vektors, als eine Operation.

Nö. Es gibt ziemlich viele verschiedene Längendefinitionen. Die bekanntesten sind norm1 (City-Block Metric), norm2( Euklidische Distanz) und normInf(maximum). Es gibt nicht "die" Länge. Deswegen kann sie keine Eigenschaft des Vektors sein.

Oder man sagt: Es gibt nur den euklidischen Raum. Angle und InterpolateCoords riechen mir auch danach.

[this-*gt*that]

otze schrieb:

this->that schrieb:

Die Funktion Length() könntest du im Vektor lassen, denn die Länge ist eher eine Eigenschaft des Vektors, als eine Operation.

Nö. Es gibt ziemlich viele verschiedene Längendefinitionen. Die bekanntesten sind norm1 (City-Block Metric), norm2( Euklidische Distanz) und normInf(maximum). Es gibt nicht "die" Länge. Deswegen kann sie keine Eigenschaft des Vektors sein.

Definition:

a vector (sometimes called a geometric[1] or spatial vector[2]) is a geometric object that has both a magnitude (or length) and direction

In der 3D-Grafik wird die benötigte Länge immer die Euklidsche Distanz sein. Für den Fall das man irgend eine freakigere Länge braucht (was nie der Fall sein wird), kann man sich dafür ja ne Extra Funktion schreiben.

[phalanx-fanboy]

- Die Konstruktoren, die nur 1 Parameter erwarten (außer Kopierkonstruktor), würde ich explicit machen. Das hilft Fehlern vorzubeugen!
- Angle und Dot sollten konstante Referenzen als Parameter erwarten!

[otze]

this->that schrieb:

In der 3D-Grafik wird die benötigte Länge immer die Euklidsche Distanz sein. Für den Fall das man irgend eine freakigere Länge braucht (was nie der Fall sein wird), kann man sich dafür ja ne Extra Funktion schreiben.

Aber wieso sollte man v.length() schreiben können, aber nicht v.norm1()? Wieso nicht nur length(v) dann passt auch norm1(v) intuitiv. (nebenbei frage ich mich, was die Definition soll. Ich bezweifle doch gar nicht, dass es eine Länge gibt, sondern sag nur, dass diese frei wählbar ist, solange sie bestimmte Eigenschaften erfüllt)

@Volkard den Winkel kriegt man auch in anderen Räumen hin, wenn zwischen Länge eines Vektors und Skalarprodukt die Beziehung sqrt(<v,v>) besteht.

[hellihjb]

otze schrieb:

Aber wieso [...]

Weil man es einfach nicht tut.
Kontext beachten:

#include <D3dx9math.h>

[this-*gt*that]

otze schrieb:

(nebenbei frage ich mich, was die Definition soll. Ich bezweifle doch gar nicht, dass es eine Länge gibt, sondern sag nur, dass diese frei wählbar ist, solange sie bestimmte Eigenschaften erfüllt)

In der Definition ist der Begriff Length direkt verlinkt mit der euklidschen Distanz.

hellihjb schrieb:

Weil man es einfach nicht tut.

Eben. Jeder weiß, dass das euklidsche Vektoren sind und niemand wird erwarten, dass ein length ein City-Block Metric (was auch immer das sein soll) liefert.

[volkard]

this->that schrieb:

Eben. Jeder weiß, dass das euklidsche Vektoren sind und niemand wird erwarten, dass ein length ein City-Block Metric (was auch immer das sein soll) liefert.

Fall Interesse besteht, was das ist: Ich kann mir nichst anderes denken, als daß http://en.wikipedia.org/wiki/Taxicab_geometry gemeint ist.

[this-*gt*that]

@volkard: Gibt es eigentlich einen Grund, wieso du im assert() 0<=index prüfst, obwohl index unsigned ist?

[otze]

this->that schrieb:

In der Definition ist der Begriff Length direkt verlinkt mit der euklidschen Distanz.

Nein. In der Definition steht nur Länge. Dass aber die Länge innerhalb eines Vektorraums frei wählbar ist, hatte ich bereits gesagt. Um mal einen Prof zu zitieren: "Ein Vektor ist ein Ding, das bestimmte Operationen hat und für das eine Länge definiert ist". Danach hat er mehrere Funktionen an die Tafel geschrieben, ein Integral als Längendefinition gebracht und gesagt: das sind Vektoren. Kurz danach hat er übrigens den Winkel zwischen verschobenen Sinus-Funktionen anhand dieser Definition bestimmt.

hellihjb schrieb:

Weil man es einfach nicht tut.

Eben. Jeder weiß, dass das euklidsche Vektoren sind

Auch wenn DirectX den Projektionsraum verwendet und durchaus alle Matrizen im Projektionsraum angegeben werden müssen? Auch dieser Raum hat eine eigene Längendefinition. Und je nachdem was man machen will, ist das auch eine wichtige Sache.

@volkard Jo. Das Ding hat verschiedene Namen. Manhatten Distanz ist auch gebräuchlich.

[this-*gt*that]

otze schrieb:

this->that schrieb:

In der Definition ist der Begriff Length direkt verlinkt mit der euklidschen Distanz.

Nein. In der Definition steht nur Länge. Dass aber die Länge innerhalb eines Vektorraums frei wählbar ist, hatte ich bereits gesagt. Um mal einen Prof zu zitieren: "Ein Vektor ist ein Ding, das bestimmte Operationen hat und für das eine Länge definiert ist". Danach hat er mehrere Funktionen an die Tafel geschrieben, ein Integral als Längendefinition gebracht und gesagt: das sind Vektoren. Kurz danach hat er übrigens den Winkel zwischen verschobenen Sinus-Funktionen anhand dieser Definition bestimmt.

Und inwiefern bringt uns (vor allem den OP) das hier irgendwie weiter? Ich kann einen Vektor auch maximal abstrakt als Element eines Vektorraums über einem Körper K betrachten, für den eine Multiplikation mit bestimmten Eigenschaften definiert ist. Ich kann ihn auch als einen Tensor 1. Stufe betrachten. Was bringt mir das für die PRAKTISCHE Umsetzung? Absolut nichts. In einer 3D Anwendung habe ich euklidsche Vektoren und jeder weiß, was die Länge eines Vektors bedeutet. Bei etwas so trivialem wie der Länge eines Vektors Begriffe wie "City-Block Metric" aufwerfen riecht stark nach Theoretiker, der alles abdecken will aber letztlich zu nichts kommt;)

[hellihjb]

Um mal einen Prof zu zitieren: "Ein Vektor ist ein Ding, das bestimmte Operationen hat und für das eine Länge definiert ist". Danach hat er mehrere Funktionen an die Tafel geschrieben, ein Integral als Längendefinition gebracht und gesagt: das sind Vektoren. Kurz danach hat er übrigens den Winkel zwischen verschobenen Sinus-Funktionen anhand dieser Definition bestimmt.

Du hast ja prinzipiell recht, das hat aber einfach etwas mit der Handhabung in der Praxis zu tun.
Mein Code sieht immer etwas "huffmanartig" aus, dh was man am haeufigsten benoetigt hat die kuerzeste Bezeichnung.
Durch die Existenz einer weiteren Laengenfunktion muesste man konsequenter Weise anstatt length() immer euclidianLength() schreiben - halte ich aber fuer Bloedsinn.

[rapso]

was ich als punkt sehe ist die ueberladung vom operator*, an sich hat die klasse auch alles was man braucht um mit farben zu rechnen. bis auf ein paar operator unstimmigkeiten, ich hab deswegen bei mir das meiste in einer basisklasse abgespalten und ein paar dinge dann spezialisiert.

das ist durchaus nuetzlich es zu mischen, z.b. kann ich auf einfache weise, zum debuggen, mir die normalen als farbe abspeichern, indem ich *vec0.5,0.5,0.5,1.f)+vec(0.5f,0.5f,0.5f,0.f); rechne und dann auf unsigned int caste und als tga ablege.

an sich denke ich auch, dass bei richtungs/positions vectoren fuer spiele es sehr eindeutig ist was gemeint ist.
ich hab jedoch auch implementierungen gesehen, bei denen man das inner produkt mit operator^ (weil es eben einen winkel darstellt, mit ein wenig abstraktion) realisierte und operator* wirklich mul war.
fand ich nach kurzer eingewoehnung aber recht angenehm.

[otze]

@this->that Was es dem OP bringt? Nichts. Es sollte dir nur zeigen, dass mit Länge nicht unbedingt die Euklidische Länge gemeint ist. Und das musste ich zeigen, um meine Ansicht zu Untermauern, dass length(v) besser ist als v.length(). Ich kann das auch nochmal genauer Ausführen: Wir haben unterschiedliche Längenmaße. Je nachdem wofür man den Vektor verwendet. Meistens hat man wirklich den Euklidischen Raum, da stimme ich dir zu. Aber schon zum Beispiel bei einem Spielfeld wie bei rundenbasierten Strategiespielen gilt das nicht mehr so ohne weiteres. Da ist für die KI nicht die euklidische Distanz relevant, weil sie nicht bestimmt, wie weit sich die KI bewegen kann, sondern zum Beispiel die City-Block-Metrik(und bei hexagonalen Spielfeldern wieder andere Normen...).

Es gibt also durchaus Fälle, in denen verschiedene Längenmaße zur selben Zeit auftreten. Warum also sollte ich dann nicht beide Längenmaße auf die selbe Weise verwenden können? Selbe Semantik = Selbe Nutzung. Alles andere ist nicht intuitiv. Um deinen Vorschlag aufzugreifen, beides zu verwenden: Warum? Verdoppelung von Funktionalität wie bei string::size() und string::length() wurde auch schon als Müll erkannt.

Ich bin ja auch nicht der Einzige, der das so sieht. boost::uBLAS macht das genau so. Da gibts norm1(v), norm2(v) und normInf(v). Hat da auch den unglaublichen Vorteil, dass man bei beliebig dimensionalen Vektoren nicht mit v.size() und v.length() durcheinander kommen kann, eben weil es nur size() gibt. Und wer seine eigene Norm braucht, kann die einfach definieren, und es fühlt sich exakt so an, wie eine normale uBLAS Norm.

@hellihjb
Das Problem hast du aber immer, wenn du unterschiedliche Normen im Zusammenspiel hast. Nenne die Euklidische Distanz length(v), und sag, dass das die Euklidische Distanz ist. Für die Leute, die nur sie verwenden, fühlt sich das nicht weiter komisch an. Und die Leute, die mehr brauchen, kennen den Unterschied.

[Gast]

this->that schrieb:

@Melan: Jetzt find ichs auch ne schöne Vektor Klasse. Durch das Auslagern der "Algorithmen" schön schlank und übersichtlich.

Die Funktion Length() könntest du im Vektor lassen, denn die Länge ist eher eine Eigenschaft des Vektors, als eine Operation. Zusätzlich könntest du dann noch eine freie Funktion anbieten, die die Methode aufruft. Aus meiner Vektor Klasse:

template <class T>
inline float Vec3Length(const Vector3<T>& v) {
   return v.getLength();
}

Dein operator[] ist richtig. Ich würde aber noch ein assert(index < 3) einbauen.
Und die Parameter deiner freien Funktionen würde ich nicht by-value sondern als konstante Referenzen übergeben.

danke this->that. Das ist die fertige Klasse:
http://codepad.org/saDvL1lP
Aber warum hast du eine Templateklasse daraus gemacht?
Benutzt du statt float manchmal double?

[Kóyaánasqatsi]

Melan schrieb:

Aber warum hast du eine Templateklasse daraus gemacht?
Benutzt du statt float manchmal double?

Es kann doch sein das er beispielsweise vertex-indices ablagern möchte. Ich persönlich mache es ebenfalls mit einem Template, ist wirklich besser...