C++ 32-bit vs 64-bit floating-limit

Gegeben das code-segment wie folgt, ich möchte nur wissen,

  • warum der maximale Wert von long double ist kleiner in der 64bit als in 32bit?
  • warum 64-bit-version erweitern können, wie viel stellen, wie in 32-bit-version zu füllen, die "40" Präzisions-Ausgabe?
  • es scheint, dass die Werte der LDBL_MIN und LDBL_MAX gleich sind, ist das ein bug?

Ich habe mir in den Schwimmer.h-Dateien in meinem Rechner aber nicht finden können, die explizite definition dieser makro-Konstanten.

Testen von Code (Platform = Win7-64bit)

#include <cfloat>
#include <iomanip>
cout<<"FLT_MAX   ="<< setprecision(40) << FLT_MAX  << endl;
cout<<"DBL_MAX   ="<< setprecision(40) << DBL_MAX  << endl;
cout<<"LDBL_MAX  ="<< setprecision(40) << LDBL_MAX << endl;
cout<<"FLT_MIN   ="<< setprecision(40) << FLT_MIN  << endl;
cout<<"DBL_MIN   ="<< setprecision(40) << DBL_MIN  << endl;
cout<<"LDBL_MIN  ="<< setprecision(40) << LDBL_MIN << endl;

32-bit-Ergebnis (MinGW-20120426)

FLT_MAX  =340282346638528859811704183484516925440
DBL_MAX  =1.797693134862315708145274237317043567981e+308
LDBL_MAX =1.189731495357231765021263853030970205169e+4932
FLT_MIN  =1.175494350822287507968736537222245677819e-038
DBL_MIN  =2.225073858507201383090232717332404064219e-308
LDBL_MIN =3.362103143112093506262677817321752602598e-4932

64-bit-Ergebnis (MinGW64-TDM 4.6)

FLT_MAX  =340282346638528860000000000000000000000
DBL_MAX  =1.7976931348623157e+308
LDBL_MAX =1.132619801677474e-317
FLT_MIN  =1.1754943508222875e-038
DBL_MIN  =2.2250738585072014e-308
LDBL_MIN =1.132619801677474e-317

Dank.

[Edit]: Mit der neuesten MinGW64-TGM 4.7.1, die "bugs" von LDBL_MAX, LDBL_MIN scheint entfernt.

  • Während .cpp wird Häufig verwendet für C++ - Dateien, CPP wird oft verwendet, um sich auf der C Pre-Prozessor. Behoben, dass der Titel entsprechend.
InformationsquelleAutor YamHon.CHAN | 2012-10-03
  1. 3

    LDBL_MAX =1.132619801677474e-317 klingt wie ein bug irgendwo. Es ist eine Anforderung des standard, dass jeder Wert darstellbar als double können auch dargestellt werden als long double, so ist es nicht zulässig, für LDBL_MAX < DBL_MAX. Gegeben, dass Sie haben nicht gezeigt, Ihre real-Prüfung-code, ich persönlich würde schauen, dass, bevor die Schuld der compiler.

    Wenn es wirklich eine (nicht-Fehler) Unterschied in long double zwischen den beiden, dann die basis, der Unterschied wird sein, dass die 32-bit-compiler verwendet die ältere x87-floating-point-Operationen, die 80 bit Genauigkeit, und damit für eine 80-bit -long double.

    Ihre 64-bit-compiler verwendet die neuere 64-bit-floating-point-Operationen in 64 bit. Keine 80-bit-Genauigkeit, und es stört das Umschalten auf x87-Instruktionen zum implementieren eines größeren long double.

    Es ist wohl eher Komplikation als das. Zum Beispiel nicht alle x86-Compiler unbedingt ein 80-bit -long double. Wie Sie diese Entscheidung hängt von verschiedenen Dingen ab, möglicherweise auch die Tatsache, dass SSE2 64-bit-Gleitkomma-ops. Aber die Möglichkeiten sind, dass long double ist die gleiche Größe wie double oder dass er größer.

    warum 64-bit-version erweitern können, wie viel stellen, wie in 32-bit-version
    füllen Sie die "40" Präzisions-Ausgabe?

    Doppel hat nur etwa 15 Dezimalstellen. Ziffern darüber hinaus sind manchmal informativ, aber in der Regel irreführend.

    Ich kann mich nicht erinnern, was der standard sagt über setprecision, aber vorausgesetzt, die Umsetzung ist erlaubt, um eine Linie zu zeichnen, wo es Stoppt die Generierung von Ziffern, die Präzision einer double ist ein angemessener Ort, um es zu zeichnen. Wie, warum eine Umsetzung entschieden, um tatsächlich tun es und die anderen nicht -- ich weiß nicht. Da Sie verschiedene Distributionen, werden Sie möglicherweise mit völlig anderen standard-Bibliotheken.

    Den gleichen "unechte Präzision" warum sehen Sie 340282346638528859811704183484516925440 für FLT_MAX in einem Fall, aber 340282346638528860000000000000000000000 in der anderen. Ein compiler (oder besser gesagt, eine Bibliothek, Umsetzung) hat sich die Mühe gemacht zu berechnen, die Menge von Ziffern. Der andere hat aufgegeben, früh-und abgerundet.

    InformationsquelleAutor Steve Jessop
  2. 0

    Diese Frage zu beantworten, ich mache nur ein paar Annahmen:
    1), dass Sie diese getestet nur auf der 64 bit Maschine
    2), dass die Compiler sind unterschiedliche bit-Versionen des gleichen sub-version (das heißt, Sie sind praktisch Schwester-Compiler).

    Dass gesagt worden ist:

    Aus "ISO/IEC 14882 INTERNATIONAL STANDARD First edition 1998-09-01"

    3.9.1 Grundlegende Arten

    1. Es gibt drei Fließkomma-Typen: float, double und long double. Der Typ double enthält mindestens so viel Genauigkeit wie float, und der Typ long double mindestens so viel Genauigkeit wie double. Die Menge der Werte vom Typ float ist eine Teilmenge der Menge der Werte vom Typ double; die Menge der Werte vom Typ double ist eine Teilmenge der Menge der Werte des Typs long double. Der Wert Darstellung von floating-point-Typen ist durch die Implementierung festgelegt. Integral und schwimmende Arten werden zusammenfassend als arithmetische Typen. Spezialisierungen der standard template numeric_limits (18.2) ist die Angabe der maximalen und minimalen Werten der arithmetische Typ für eine Implementierung.

    Zusätzlich verschiedene CPU ' s haben unterschiedliche Auswirkungen auf das Ergebnis so weit wie Präzision, mit der höheren Stufe zahlen. Gleiches gilt für die Compiler. VC++'s compiler nicht benehmen gleiche wie borland, noch GCC/G++, und so weiter.

    • Sicher, dass ich das test-Programm in einer 64-bit-box, und sowohl gcc (32/64) sind 4.6.x und ich weiß, dass diese Grenzen sind irgendwie von der Implementierung abhängig, aber es scheint, dass aus dem Ergebnis, LDBL_MAX ist eine sehr kleine Zahl, die viel, viel weniger, dass DBL_MAX (der Ordnung von 317+308=625) auf 64-bit
    • Meine Theorie, warum das so ist, ist entweder, weil der, wie der compiler gewählt, Sie zu vertreten (entweder über ein makro oder eine system-request), oder, ja, ein bug.
    InformationsquelleAutor M4rc
Schreibe einen Kommentar