Also mein Problem ist folgendes:
Wenn ich eine float-Zahl mit 10 multipliziere, dann zeigt mir der Debugger von Microsoft Visual Studio an, dass da eine 1 an letzter Stelle hinzugekommen ist.
Beispiel:

float temp;
Zahl = 1.437;
temp = Zahl * 10;  //Der Debugger zeigt mir hier dann 14.370001 an

Da ist dann also die verflixte 1 an letzter Stelle hinzugekommen. Diese nervt mich ungemein, weil ich diese im späteren Verlauf mit einer anderen Zahl vergleichen will und 14.370001 ist nunmal nicht 14.370000.

Ich bitte dringend um Hilfe!

float temp;
Zahl = 1.437;
temp = (float)Zahl * 10.0F;

Sprenger120 schrieb:

Hi,
wenn du mit Floats rechnest, muss ein F hinter die Zahl, daher:

float temp;
Zahl = 1.437;
temp = (float)Zahl * 10.0F;

genialer einfall. jetzt kommt auf einmal 14.370000 raus - das war der fehler.
hier mein code:

floatf tempf;
floatf Zahlf = 1.437f;
tempf = static_cast<floatf>(Zahlf) * 10.f;

std::coutf << tempf << std::endlf;
/* ausgabe:
1f4f.3f7f0f0f0f0f0
*/

knivil schrieb:

Normalerweise vergleicht man Fliesskommazahlen nicht mit == .

hat nix mit dem thema zu tun

Soley schrieb:

Rechne doch einfach mit doubles, statt mit floats... die haben, wie der Name schon sagt, doppelte Genauigkeit

wenn er sich an 1*10^-6 stört, wird ihm auch die doppelte genauigkeit nicht reichen.

knivil schrieb:

Normalerweise vergleicht man Fliesskommazahlen nicht mit == .

hat nix mit dem thema zu tun

Doch, steht direkt im ersten Post. Er möchte seine Zahl vergleichen, und da stört die Ungenauigkeit. Daher ist ein Vergleich mit Epsilon die Lösung.

Oder man nutzt einfach einen integer und merkt sich, wo das Komma ist. Ist zwar umständlich, aber dann genau und für mancherlei Arbeit vielleicht als Lösung zu überlegen. Meistens aber wahrscheinlich nicht.

Wenn du weißt, wieviel Genauigkeit du brauchst (z.B. Geld), ist das die optimale Lösung. Andernfalls kann es schwierig werden...

Auch nett ist eine Klasse für Bruchzahlen und dafür einfach alle Operatoren überladen. Da kann man eine gewaltige Genauigkeit haben (2 uint64 zb), es ist von der Performance akzeptabel und leicht zu handhaben.

Rationale Zahlen zu implementieren ist nicht einfach. Denn der Trade-off zwischen Genauigkeit und maximal darstellbarem Zahlenbereich bei der Implementation über Zähler/Nenner ist meistens nicht das, was man haben will. Addierst du eine sehr große zahl zu einer Zahl mit großem Nenner, kann es sein, dass du Stellen _vor_ dem Komma durch Überläufe verlierst.

Die einzig wahre Darstellung ist damit Fixpunkt. Also 1 uint64 für die Zahlen vor dem Komma und 1 uint64 für die Nachkommastellen. Hat den Vorteil, dass du ein einfach zu berechnendes epsilon hast, erlöst dich aber nicht davor, dass es nicht darstellbare Zahlen gibt.