Vergleichoperator verhält sich bei float und glm::vec3 bei Vorzeichen unterschiedlich

titan99_

Hallo,

// #include <glm/vec3.hpp>
// typedef glm::vec3 vec3;

auto testvec0 = vec3(0.f);  // Füllt alle Vektorkomponenten mit  0.f
auto testvec1 = vec3(-0.f); // Füllt alle Vektorkomponenten mit -0.f
		
auto testequal0 = (vec3(0.f) == vec3(-0.f)); // weist false zu
auto testequal1 = (vec3(0.f) == vec3(0.f));  // weist true zu
auto testequal2 = (vec3(1.f) == vec3(1.f));  // weist true zu
auto testequal3 = (vec3(0.f) == vec3(1.f));  // weist false zu

auto floattest0 = (0.f == -0.f); // weist true zu
auto floattest1 = (0.f == 0.f);  // weist true zu

Wenn zwei float Variablen 0 zugewiesen wird und sie mit dem Vergleichsoperator == verglichen werden, ergibt sich unabhängig vom Vorzeichen wahr, siehe floattest0 und floattest1.

Anders bei vec3 von glm, siehe testequal0 und testequal1. Weiss jemand gerade woran das liegt und wie es sich am einfachsten beheben lässt?

Swordfish

Guckst Du: operator== now behaves unexpectedly #723

titan99_

Danke für die schnelle Antwort und den Link.

Was ist wohl besser um es zu beheben:

Komponentenweises vergleichen?
~~glm::abs?~~

Mit glm::absgeht es scheinbar nicht.

auto abstest = glm::abs(vec3(-0.f));

Bei der Variable abstest bleiben die Vorzeichen bestehen.

Swordfish

@titan99_ sagte in Vergleichoperator verhält sich bei float und glm::vec3 bei Vorzeichen unterschiedlich:

Komponentenweises vergleichen?

entweder das, oder, ich glaube ich wäre ganz phöse und würde die memcmp-Version von compute_equal::call() einfach wegwerfen, bis das in einer nächsten Version wieder gefixt ist.

titan99_

@swordfish sagte in Vergleichoperator verhält sich bei float und glm::vec3 bei Vorzeichen unterschiedlich:

compute_equal::call()

In glm\detail\compute_vector_relational.hpp ist ja noch die Version mit dem "ersichtlicheren" Vergleichsoperator enthalten. Verstehe im Moment nicht, wie in type_vec3.inl die Version mit memcmp aufgerufen wird.

Aber was solls, dafür weiss ich jetzt dass 0.f und -0.f unterschiedlich im Speicher ist.

Swordfish

@titan99_ sagte in Vergleichoperator verhält sich bei float und glm::vec3 bei Vorzeichen unterschiedlich:

Verstehe im Moment nicht, wie in type_vec3.inl die Version mit memcmp aufgerufen wird.

Naja, compute_equal mit call() in der memcmp()-Version ist für <T, true> spezialisiert und passt auf alle T, für die std::numeric_limits<T>::is_iec559 wahr ist. Also in der Regel float, double und long double.

wob

@titan99_ sagte in [Vergleichoperator verhält sich bei float und glm::vec3 bei Vorzeichen

Aber was solls, dafür weiss ich jetzt dass 0.f und -0.f unterschiedlich im Speicher ist.

Naja, wie sollte man die sonst unterscheiden können?

Aber floats bieten ja noch viel mehr Spaß. Wenn man nun plötzlich mit memcmp vergleicht, ist auch einmal nicht mehr klar, was bei NANs passiert. Bei == vergleichen die false, weil alles mit NAN vergleichen false ist. Da es aber verschiedene Repräsentationen von NAN gibt, kann mit memcmp nun entweder false oder true (bzw. nicht-0 oder 0) herauskommen. Toll, oder?