Länge eines Tokens
-
hjdt schrieb:
Das ist überhaupt nicht sinnlos!
Doch, vollkommen...
hjdt schrieb:
Die Konstante dient zur Fehlerbestimmung und muss exakt
im Speicher vorhanden sein. Mit anderen Compilern, wie z.B. Gnu, Intel oder Borland, ist das kein Problem.Den gleichen Wert erzielst Du auch durch eingabe von
double b0 = 6369051672525773.0 / 1.0191699398572330817932436647906E+170;
-
Jochen Kalmbach schrieb:
hjdt schrieb:
Das ist überhaupt nicht sinnlos!
Doch, vollkommen...
hjdt schrieb:
Die Konstante dient zur Fehlerbestimmung und muss exakt
im Speicher vorhanden sein. Mit anderen Compilern, wie z.B. Gnu, Intel oder Borland, ist das kein Problem.Den gleichen Wert erzielst Du auch durch eingabe von
double b0 = 6369051672525773.0 / 1.0191699398572330817932436647906E+170;Das ist falsch! Die beiden Zahlen sind ungleich. So einfach geht es nun nicht
-
Es gibt halt zwei Lösungen:
- Du kürzt Deine Konstante auf ein vernünftiges Mass
- Du verwendest keinen MS Compiler
-
hjdt schrieb:
Das ist falsch! Die beiden Zahlen sind ungleich.
Solange du sie in einer double-Variablen ablegst, sind sie gleich. Fließkommatypen haben eine beschränkte Genauigkeit, die kannst du auch nicht dadurch erhöhen, dass du ein riesiges Literal benutzt. Wenn du so eine Genauigkeit brauchst, kannst du dafür eben nicht float oder double benutzen.
-
Der Datentyp real, den ich oben erwähnte, kann bist 256-Stellen exakt darstellen. Diesen Typ gibt es in XSC (eXtended Scientific Computation) Sprachen. Die Konstante geht also schon in Ordnung und kann auch nicht gekürzt werden. Wenn der Compiler das nicht kann, sollte sich Microsoft schämen,
denn 256 Zeichen sind nicht viel.
Ich habe herausgefunden, wenn die Konstante länger als 127 Zeichen ist,
geht das schief.
-
hjdt schrieb:
Diesen Typ gibt es in XSC (eXtended Scientific Computation) Sprachen.
Danke, dass du das gleich gesagt hast. Das spart den Helfern viel Zeit
Die Konstante geht also schon in Ordnung und kann auch nicht gekürzt werden.
Die Konstante ist ein double-Literal und ist damit an die Beschränkungen dieses Datentyps gebunden. Selbst wenn der Compiler ein so langes Literal verarbeiten könnte, hätte es nicht die gewünschte Genauigkeit.
Schau doch einfach mal in die XSC-Doku. Vermutlich kannst du real-Werte mittels Stringstreams aus Strings erzeugen.
-
Ein C/C++ compiler kennt nur float und double (optional noch long double). Der Compiler wird also *immer* den Wert zuerst in seine genauigkeit umrechnen und dann dem "real" zuweisen. Deshalb kann es in C/C++ keine Zahlen-Konstanten mit der von Dir gewünschten Genauigkeit geben.
Die meisten Libs die eine höhere Genauigkeit anbieten, realisieren Konstanten über Strings! also:
real a = "6369051672525773.0";
real b = "10191699398572330817932436647906151127335369763331523427009650401964993299137190816689013801421270140331747000246110759198164677039398341060491474011461568349195162615808.0";
real c = a / b;Siehe apfloat usw...
-
hjdt schrieb:
Wenn der Compiler das nicht kann, sollte sich Microsoft schämen
Warum?
-
hjdt schrieb:
Bei sowas:
real b0 = 6369051672525773.0 / 10191699398572330817932436647906151127335369763331523427009650401964993299137190816689013801421270140331747000246110759198164
677039398341060491474011461568349195162615808.0;VC6 gibt für die Anzahl der Stellen folgendes an:
double 8 none 1.7E +/- 308 (15 digits)
long double 10 none 1.2E +/- 4932 (19 digits)Von deiner Zahl sind also auch bei einem long double nur 19 stellen
signifikant. Die Länge solche Konstanten sind in gewisserweise
Auslegungssache, da sie in C/C++ nicht definiert sind.
Meistens ist das (stark vereinfacht) soetwas hier (BNF):[0-9]+"."[0-9]*
Das "+" nach "[0-9]" bedeuted "eine Zahl oder mehr". Dieses "mehr" muss von
den Compilerherstellern ausgelegt werden und das macht eben jeder anders.
Sinn machen solche Kostanten nicht, weil der Compiler sie einkürzen muss!Die Ansi-C-Gramar findet sich z. b. unter:
-
Mittlerweile habe ich herausbekommen, dass ein Token max 127 Zeichen lang sein darf. Ist nicht wirklich viel. :xmas1:
-
LOL! Geile Reaktion.
