mehrere if-anweisungen
-
sofern man den BCB6 hat. Ich hab noch den BCB5 und da gibt es diese Funktion nicht.
-
oder man vergleicht mit gerundeten Werten, in diesem Fall Rundung auf eine Dezimalstelle.
RoundTo(nWert,-1)
-
caspar_louis schrieb:
oder man vergleicht mit gerundeten Werten, in diesem Fall Rundung auf eine Dezimalstelle.
RoundTo(nWert,-1)*autsch*
-
caspar_louis schrieb:
oder man vergleicht mit gerundeten Werten, in diesem Fall Rundung auf eine Dezimalstelle.
RoundTo(nWert,-1)Setzen 6
-
MichelRT schrieb:
caspar_louis schrieb:
oder man vergleicht mit gerundeten Werten, in diesem Fall Rundung auf eine Dezimalstelle.
RoundTo(nWert,-1)Setzen 6
Drück ich mich so verkehrt aus, oder denke ich so schief?
if (erhalt==3,3) || (erhalt==3,6) {...} // könnte schief gehen, weil Float-Wert erhalt so ggf. nicht mit 3,3 oder 3,6 [ob mit Komma oder Punkt] nicht gleich sind if (RoundTo(erhalt,-1)==3,3) || (RoundTo(erhalt,-1)==3,6) // sollte das Problem der Ungenauigkeit beheben, da ein Rundungsfehler weitgehend ausgeschlossen werden kann. erhalt wurde ja vorher eingeben, m.E. mit einer Dezimalstelle {...}
-
Du denkst schief
Du vergleichst wieder Fließkommazahlen. Das funktioniert aber nicht.
0,1 z.B. ist in der internen Fließkommadarstellung (Exponent/Mantisse) eine undendliche Periode und somit nicht darstellbar und somit auch nicht per == vergleichbar.
Fließkommazahlen dürfen grundsätzlich NIE mit == verglichen werden.
-
MichelRT schrieb:
Du vergleichst wieder Fließkommazahlen. Das funktioniert aber nicht.
0,1 z.B. ist in der internen Fließkommadarstellung (Exponent/Mantisse) eine undendliche Periode und somit nicht darstellbar und somit auch nicht per == vergleichbar.Das ist mir klar.
Ich dachte nur, ich sorge dafür daß beide Fließkommazahlen gleich sind. Z.B. 0,1 und 0,1 sollten doch jeweils die identische Fließkommadarstellung nach sich ziehen. Oder ist dort ein Teil zufällig ?Ich erinnere mich dunkel an meinen C++ Dozenten, der sagte, daß die Genauigkeit der beiden Werte übereinstimmen müsse, um einen == Vergleich zu ermöglichen. Stimmt das - oder habe ich mir das was falsches gemerkt ?
-
Die Genauigkeit ist der Knackpunkt, das hast Du Dir Richtig gemerkt.
Z1 und Z2 sind mit der Genauigkeit X als gleich anzusehen wenn
Z1 < Z2 + X UND Z1 > Z2 - X
-
MichelRT schrieb:
Die Genauigkeit ist der Knackpunkt, das hast Du Dir Richtig gemerkt.
Z1 und Z2 sind mit der Genauigkeit X als gleich anzusehen wenn
Z1 < Z2 + X UND Z1 > Z2 - X?!?
Die Genauigkeit eines Dezimalwertes gibt die Stellen nach dem Komma an, die nicht Null sind.z.B. Genauigkeit=3 -> 2/3=0,3330
Da fällt mir zu Z1 < Z2 + X UND Z1 > Z2 - X recht wenig ein. D.h., ich kann den Sinn darin nicht erkennen. Was ist für Dich X?
-
X ist die Genauigkeit die Du haben möchtest. z.B. 0,0001. D.h. dann die beiden Zahlen sind gleich wenn Zahl 1 im Intervall +/-0,0001 um Zahl 2 liegt
-
Stell Dir den Zahlenstrahl vor. Auf dem Zahlenstral befindet sich die Zahl 2 und mit X wird ein Intervall auf dem Zahlenstrahl angegeben in dessen Mitte die Zahl 2 sich befindet. Man sagt nun wenn sich die Zahl 1 in dem durch X angegebenen Intervall um Z2 liegt dann sind Zahl 1 und Zahl 2 gleich
-
OK. Das kommt mir bekannt vor un leuchtet ein
(auch einem SQL-verwöhnten User wie mir, der sich bei Vergleichen seltenst Gedanken um die Genauigkeit machen muß).Frage:
0,333 mit Genauigkeit 3 == 0,333 mit Genauigkeit 3 sollte true ergeben ?also z.B. RoundTo(0.1,-1)==RoundTo(0.1,-1)
-
caspar_louis schrieb:
Frage:
0,333 mit Genauigkeit 3 == 0,333 mit Genauigkeit 3 sollte true ergeben ?also z.B. RoundTo(0.1,-1)==RoundTo(0.1,-1)
RoundTo arbeitet mit multiplikationen mit zehnerpotenzen, welche wieder fließkommazahlen sind
ERGO hast du wieder minimale Abweichungen vom gerundeten Ergebnis, wodurch zwei Zahlen, die gerundet gleich sind, immernoch als != eingestuft werden könnenwenn du RoundTo(0.1,-1) == RoundTo(0.1,-1) vergleichst, wird das true ergeben, da der Algo die gleichen Eingabedaten hat, also die gleiche minimale abweichung ergibt, aber bei RoundTo(0.101,-1) == RoundTo(0.099,-1) kann das schon ganz anders aussehen
btw. Studierst du Informatik in Düsseldorf?
-
Wenn Du Informatik studierst dann gibt es dazu noch eine ganze Vorlesung die erschöpfend auf diese ganze Problematik eingeht. Numerische Verfahren.
Die gab es wenigstens zu meiner Zeit, ist aber schon ein paar Jährchen her.
-
also z.B. RoundTo(0.1,-1)==RoundTo(0.1,-1)[/quote]
Wenn RoundTo als Ergebnis wieder eine Fließkommazahl hat, dann bring Dir das gar nichts. Dann vergleichst Du wieder zwei Fließkommazahlen und das Ergebnis kann wieder unerwarteter Weise false sein, obwohl Du denkst es müßte true sein.
Das gemeine an der Geschichte ist, daß es bei Deinen Testfällen immer "richtig" funktioniert und wenn Dein Programm dann im Einsatz ist 100%ig innerhalb kürzester Zeit nicht mehr richtig funktioniert. Deswegen grundsätzlich NIE Fließkommazahlen auf Gleichheit überprüfen.
-
-
-
evtl sollte man den Thread hier umbenennen oder spalten @ Mods
mfg
BigNeal
-
Nein ich studiere nicht mehr. Mein Studium liegt schon 10 Jahre zurück.
Haupsächlich arbeite ich mit SQL in verschiedenen Dialekten und komme studientechnisch von der Pascal-Seite. Sowohl in SQL als auch in Pascal sind Vergleiche anders gelöst als in C++, so daß solche Abweichungen, die Fließkommas ja immanent sind, keine Rolle spielen.
C++ mache ich nur als Frontend für eine SQL-Server-DB, weil unser ERP mit seiner eigenen Sprache zwar Events aber keine eigenen Masken zuläßt.Zu C++ habe ich mal einen Abendkurs besucht, um mir nicht alles in selbst aneignen zu müssen.
-
Das ist falsch, für SQL mag das vielleicht stimmen. Bei Pascal gilt genau das Gleiche wie für C++. Die Problematik hat nichts mit der Programmiersprache zu tun sondern mit der Implementierung der Fließkommazahlen in Fließkommarecheneinheit des Rechners.
