Hallo,
ich möchte gern eine eingegebene Zahl auf Ganzzahligkeit testen, wie kriege ich das hin?
Hab so gar keine Idee gerade.
Danke
Katja
Hallo,
Servus
ich möchte gern eine eingegebene Zahl auf Ganzzahligkeit
testen, wie kriege ich das hin?
Hab so gar keine Idee gerade.
Also mir ist gerade ein Weg eingefallen:
double a = 12345.678;
int b = a;
double c = b;
if(a == c) {
printf(„Ganzzahl“);
}
else {
printf(„nicht Ganzzahl“);
}
Sodala, das müsste funktionieren.
Grüsse Chris
Danke erstmal und kurz wegen meiner thmenspezifisch irgendwie sehr langen Leitung:
b ist die eingegebene Zahl?
a wird als double der Wert 123456.789 zugewiesen
wenn ich jetzt aber b den wert a zuordne geht doch der eingabewert verloren oder?
und c wird dann doch der neue b wert zugeordnet und damit wird doch dann eigentlich bei Vergleich c==a das gleiche verglichen oder nicht ?
grummel ich bin grad echt blockiert, hmmmmmmmmm
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
double a = 12345.678;
int b = a;
double c = b;if(a == c) {
printf(„Ganzzahl“);
}
else {
printf(„nicht Ganzzahl“);
}
Ok, ich hätte was dazu schreiben sollen 
Also, eine eingegebene Zahl ist in dem obigen Beispiel a (hab mal angenommen du benutzt double um die zahl zu speichern). Indem ich diese eingegebene Zahl int b zuweise ändert sich der Datentyp der Zahl (von double auf int). int ist eine Ganzzahl-Datentyp, d.h. der double Zahl wird der Nachkommateil abgeschnitten (oder gerundet; weiß ich im Moment nicht so genau). Jedenfalls würde dann in b z.B. 12345 stehen. Wenn ich das wieder in double zurückcaste entsteht daraus c.
Wenn ich nun die ursprüngliche Zahl a mit der neuen Zahl c vergleiche ergibt das nur TRUE wenn a eine Ganzzahl war (weil ja kein Nachkommateil vorhanden war, der bei int b = a verlorengehen konnte).
Ich hoffe, es ist nun einigermaßen verständlich
Gruss, Chris
allerbesten Dank
Hallo,
danke. Ja jetzt klingelts lol.
logisch eigentlich, ich probiers gleich aus
Tschau
Catche
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
double a = 12345.678;
int b = a;
double c = b;if(a == c) {
printf(„Ganzzahl“);
}
else {
printf(„nicht Ganzzahl“);
}
Ganz schön umständlich ich würds so machen:
double a = 1234.56; // eingegebene Zahl
if(a == (int)a)
printf(„Ganzzahl“);
else
printf(„Kommazahl“);
Hallo,
ich möchte gern eine eingegebene Zahl auf Ganzzahligkeit
testen, wie kriege ich das hin?
Hab so gar keine Idee gerade.
Noch mal ergänzend zu dem bisher gesagten.
Sinvoll wäre imho folgende Herangehensweise:
#include
...
double wert;
wert = "3.1415"; //
Grüße
CMБ
Hallo,
ich möchte gern eine eingegebene Zahl auf Ganzzahligkeit
testen, wie kriege ich das hin?
Hab so gar keine Idee gerade.Danke
Katja
Alle genannten Lösungen laufen daraus hinauf, dass eine auf double konvertierte Integer-Variable mit einer anderen double-Variable verglichen wird. Derartige Vergleiche können zwar problemlos funktionieren, tun es aber in vielen Fällen nicht! Man hat nämlich keine Garantie, dass der auf double zurückgewandelte Wert nicht an der 5. oder 6. Nachkommastelle vom Original abweicht. Nicht vergebens quittieren ordentliche Compiler derartige Konstrukte mit einer Warnmeldung (etwa Intel C+±Compiler mit Warnung 1563: „floating-point equality and inequality comparisons are unreliable“).
Exakterweise sollte man den Vergleich auf eine genau definierte Anzahl von Nachkommastellen begrenzen, um die Abfrage stabil zu machen.
Folgende Lösung würde funktionieren und ist bei mir produktiv im Einsatz:
#define LT 0 // Ersatz für "kleiner als"
#define E 1 // Ersatz für "gleich"
#define GT 2 // Ersatz für "größer als"
#define LTE 3 // Ersatz für "kleiner als oder gleich"
#define GTE 4 // Ersatz für "größer als oder gleich"
/\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
Überprüft die übergebenen double-Werte mit dem übergebenen Operator-Typ
auf eine übergebenene Anzahl von Nachkommastellen.
Übergabe
dVal1 Erster Prüfwert.
dVal2 Zweiter Prüfwert.
nOp Durchzuführende Operation:
LT:
LTE: =
nDigits Anzahl der zu prüfenden Nachkommastellen (Default: 3).
Rückgabe
Ergebnis der Operation als BOOL-Wert.
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*/
BOOL DCheck( double dVal1, double dVal2, int nOp, int nDigits )
{
int nVal1, nVal2;
BOOL bResult;
// Werte auf int konvertieren
nVal1=IdRound( dVal1\*pow( 10.0, ( double )nDigits ));
nVal2=IdRound( dVal2\*pow( 10.0, ( double )nDigits ));
switch( nOp ){ // Operator auswerten
case LT: // "Kleiner als"
bResult=( nVal1nVal2 );
break;
case LTE: // "Kleiner als oder gleich"
bResult=( nVal1=nVal2 );
break;
}
return bResult;
}
Damit sollte obige Abfrage folgendermaßen aussehen:
double a = 1234.56; // eingegebene Zahl
if( DCheck( a, floor( a ), E ))
printf("Ganzzahl");
else
printf("Kommazahl");
Grüße Safog
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Safog,
Alle genannten Lösungen laufen daraus hinauf, dass eine auf
double konvertierte Integer-Variable mit einer anderen
double-Variable verglichen wird.
stimmt nicht!
Derartige Vergleiche können zwar problemlos funktionieren,
tun es aber in vielen Fällen nicht!
Der Witz ist, sie sehen nicht schön aus, aber
sie funktionieren tatsächlich (richtig angewendet).
Comparison to zero ist für float oder double
immer korrekt.
Man hat nämlich keine Garantie, dass der auf double
zurückgewandelte Wert nicht an der 5. oder 6. Nachkommastelle
vom Original abweicht. Nicht vergebens quittieren ordentliche
Compiler derartige Konstrukte mit einer Warnmeldung (etwa
Intel C+±Compiler mit Warnung 1563: „floating-point equality
and inequality comparisons are unreliable“).
Das ist etwas anderes! Das ist nicht der Punkt hier.
Exakterweise sollte man den Vergleich auf eine genau
definierte Anzahl von Nachkommastellen begrenzen, um die
Abfrage stabil zu machen.
IMHO nein. Du kannst nur sinnvoll gegen 0.0 vergleichen,
da Null in IEEE eine definierte Repräsentation hat.
Folgende Lösung würde funktionieren und ist bei mir produktiv
im Einsatz:
…
Damit sollte obige Abfrage folgendermaßen aussehen:double a = 1234.56; // eingegebene Zahl
if( DCheck( a, floor( a ), E ))
printf(„Ganzzahl“);
else
printf(„Kommazahl“);
Das kann imho nicht funktionieren. Aus zwei Gründen.
Der dritte Grund ist ‚floor‘. Ich hoffe, Deine
Arbeit ist nicht nur von diesen Funktionen
abhängig
Grüße
CMБ
Hallo Safog,
Alle genannten Lösungen laufen daraus hinauf, dass eine auf
double konvertierte Integer-Variable mit einer anderen
double-Variable verglichen wird.stimmt nicht!
Sorry Semjon, habe Deine Lösung gar nicht gesehen!
Ich spreche hier von den Vergleichen in den anderen vorgeschlageen Lösungen.
Derartige Vergleiche können zwar problemlos funktionieren,
tun es aber in vielen Fällen nicht!Der Witz ist, sie sehen nicht schön aus, aber
sie funktionieren tatsächlich (richtig angewendet).
Comparison to zero ist für float oder double
immer korrekt.
Stimmt!
Man hat nämlich keine Garantie, dass der auf double
zurückgewandelte Wert nicht an der 5. oder 6. Nachkommastelle
vom Original abweicht. Nicht vergebens quittieren ordentliche
Compiler derartige Konstrukte mit einer Warnmeldung (etwa
Intel C+±Compiler mit Warnung 1563: „floating-point equality
and inequality comparisons are unreliable“).Das ist etwas anderes! Das ist nicht der Punkt hier.
Das ist nicht der Punkt bei Deiner eigenen NAN-Lösung, für alle anderen aber sehr wohl.
Exakterweise sollte man den Vergleich auf eine genau
definierte Anzahl von Nachkommastellen begrenzen, um die
Abfrage stabil zu machen.IMHO nein. Du kannst nur sinnvoll gegen 0.0 vergleichen,
da Null in IEEE eine definierte Repräsentation hat.
Ich bleibe dabei, wenn ich die Anzahl der Nachkommastellen begrenze, ist ein Vergleich sehr wohl sinnvoll.
Folgende Lösung würde funktionieren und ist bei mir produktiv
im Einsatz:
…
Damit sollte obige Abfrage folgendermaßen aussehen:double a = 1234.56; // eingegebene Zahl
if( DCheck( a, floor( a ), E ))
printf(„Ganzzahl“);
else
printf(„Kommazahl“);Das kann imho nicht funktionieren. Aus zwei Gründen.
Der dritte Grund ist ‚floor‘. Ich hoffe, Deine
Arbeit ist nicht nur von diesen Funktionen
abhängig
Ich habe die Funktion IdRound nicht angegeben, Du hast recht. Außerdem sollte man nDigits auf einen Wert setzen (hier nicht getan, weil defaultmäßig auf 3), dann funktioniert das Ganze aber sehr wohl und das seit über 10 Jahren. Wenn Du mir Deine 2 Gründe nennst, bin ich bereit, die floor-Lösung auf positive Werte zu begrenzen.
Es ist mir schon öfters aufgefallen, dass (selbsternannte?) Gurus immer Hautausschlag kriegen, wenn sie über ungarisch notierte Codefragmente stolpern. Simony ist nicht mehr bei Microsoft, keine Angst.
Außerdem wundert es mich, weshalb Du in Deinem eigenen Posting die anderen Antworten zwar als Bastel-Lösungen abtust, aber nicht auf die damit verbundene Problematik hinweist. Dann hatten wir uns das unsägliche hin und her sparen können.
Grüße Safog
Hallo Safog
Ich bleibe dabei, wenn ich die Anzahl der Nachkommastellen
begrenze, ist ein Vergleich sehr wohl sinnvoll.
OK, ich kann das letztlich nicht beurteilen, da ich Deine
Vergleichsfunktion nicht kenne. Ich bezweifle es aber
erstmal, dass das funktionieren kann.
Das kann imho nicht funktionieren. Aus zwei Gründen.
Der dritte Grund ist ‚floor‘. Ich hoffe, Deine
Arbeit ist nicht nur von diesen Funktionen
abhängigIch habe die Funktion IdRound nicht angegeben, Du hast recht.
Außerdem sollte man nDigits auf einen Wert setzen (hier nicht
getan, weil defaultmäßig auf 3), dann funktioniert das Ganze
aber sehr wohl und das seit über 10 Jahren. Wenn Du mir Deine
2 Gründe nennst, bin ich bereit, die floor-Lösung auf positive
Werte zu begrenzen.
OK ok ok! Ich hab ein bisschen Wind gemacht, wie ich
es gerne mache, wenn ich meine, dass der Adressat es
verkraften kann
Aber ein prinzipielles Problem ist natürlich, dass
ein int (Maschinenwortgröße üblicherweise 32bit)
nicht besonders viele double-Eingabewerte abdecken
kann, vor allem nicht, wenn man den double noch mit 10^n
multipliziert. Ein Overflow in nVal1 aus DCheck ist
also mehr die Regel als die Ausnahme. Und ich kann
keinen Signalmechanismus erkennen, der das abfängt.
Es ist mir schon öfters aufgefallen, dass (selbsternannte?)
Gurus immer Hautausschlag kriegen, wenn sie über ungarisch
notierte Codefragmente stolpern. Simony ist nicht mehr bei
Microsoft, keine Angst.
Hehe, ich hab ehrlich gesagt immer noch gerne szDiese szNotation
szDrauf, wenn ich Windowsprogramme schreibe. Seit der
Petzold-Lektüre am Anfang ist das „für Win32“ bei mir
fest verdrahtet
Außerdem wundert es mich, weshalb Du in Deinem eigenen Posting
die anderen Antworten zwar als Bastel-Lösungen abtust, aber
nicht auf die damit verbundene Problematik hinweist. Dann
hatten wir uns das unsägliche hin und her sparen können.
Ach komm. Die simplen (int) casts funktionieren nicht
weniger gut als Deine (mir nicht ganz einleuchtende)
komplizierte Konvertiererei, machen wir uns nichts
vor
Aber Du hast recht. Man sollte, sofern man auf diese Dinge
stößt, wenigstens ein paar warnende Worte verlieren.
Grüße
CMБ