3. Was kommt nach double ?

Was kommt nach double ?

  • N

    Auf 32-Bit-Systemen ist long double aber meistens genauso breit wie double .

    0
  • ?

    Nexus schrieb:

    Auf 32-Bit-Systemen ist long double aber meistens genauso breit wie double .

    Nur weil der VC long double so groß lässt wie double heißt das nicht, dass das überall so ist. Im Gegenteil es bietet sich auf x86 Systemen sogar an ihn größer zu machen, da die FPU 80Bit breite Register hat und dementsprechend 80Bit floating points verarbeiten kann.
    Der GCC setzt long double auf die 80Bit, iirc.

    0
  • .
     

    % sizeof.sh 'long double'
sizeof (long double) == 128 Bit == 16 Byte
% sizeof.sh 'double'     
sizeof (double) == 64 Bit == 8 Byte
% uname -m
i386
    0
  • N

    Naja, ich hab ja nicht behauptet, das sei immer so. Besser, man verlässt sich nicht darauf, dass long double immer breiter ist als double . Aber wenn mans genau wissen muss, kann man sowieso die Typen mit fester Breite nutzen (die Diskussion gabs übrigens kürzlich).

    0
  • B

    Hi!

    Wers noch genauer will: Es gibt die GMPLIB http://gmplib.org/.

    Das ist eine Library für große Zahlen. Die Größe der Zahlen ist nur durch den zur verfügung stehenden Stack begrenz.

    mfg bauerb

    0
  • *

    Stimmt nicht schrieb:

    Der GCC setzt long double auf die 80Bit, iirc.

    Nein, das ist Plattform abhängig. Auf vielen nicht x86 ist long double das IEEE Quad Format = 128Bit.

    0
  • *

    thenoname schrieb:

    Was wäre noch genauer?
    Ich dachte an 128 Bit floats, aber anscheinend gibt es auch noch Vorstufen.

    Es gibt nach IEEE 32, 64 und 128Bit Formate. Auf einigen Plattformen gibt es noch andere Formate (x86 80Bit oder 68k 80Bit), diese verhalten sich beim Rechnen aber anders, so daß man sie besser nicht verwendet, weil die Ergebnisse dann nicht mehr ohne weiteres vergleichbar sind.

    0
  • B

    Die interne Genauigkeiten von 'double' und 'long double' sind und bleiben vor allem vom Compiler abhängig. 'long double' kann also mal 32, 48 oder 64 bit aufweisen. Gesichert sollte 32 bit sein.

    0
  • S

    Ich habe einen eigenen Datentyp programmiert, bei der die Genauigkeit bei 2000 Nachkomastellen liegt. Besucht doch mal meine Seite http://www.srbib.de . Ich habe es ursprünglich für Linux programmiert. Aber wenn Ihr wollt, könnte ich meine Webseite ein bisschen umgestallten, damit man sich auch den Quelltext anschauen kann. Auf meine Seite findet Ihr auch viele Screenshots zu meiner Bibliothek.

    Gruß,
    Stefan

    0
  • N

    @ stefan2008:
    Nach deiner Homepage rechnest du mit den Zahlen als Zeichenkette. Ich denke nicht unbedingt, dass diese Lösung optimal, geschweige denn schnell ist 😉

    Trotzdem nett, deine Bibliothek 🙂

    0
  • B

    @ Stefan2008
    Na ja, ganz nett Deine Idee. Byte-weises Rechnen bleibt aber angesagt, wenn man an dieser Stelle etwas verbessern möchte. Sage uns mal, wer für floatingpoint mehr als 8 (oder vielleicht 16) Bytes benötigt.

    0
  • S

    Gute Frage. Ich glaube man könnte diese Bibliothek verwenden, um die Genauigkeit von Maßeinheiten, die unterhalb von Picometer ligen, genauer darzustellen oder den Abstand von zwei Planeten in Metern genau zu ermitteln. Natürlich ist es mit den Vor- und Nachkommastellen übertrieben und kein Mensch achtet genau auf Nachkommastellen. Aber ich will einfach demonstrieren, dass mein Datentyp, im Gegensatz zu den Standarddatentypen einfach sicherer arbeitet, da es einige Regeln beachtet.
    Ich habe aber noch ein paar Probleme. Zum Beispiel weis ich nicht, wie der Algorithmus für die n-te-Wurzel definiert ist. Oder wie ich es den Computer beibringen kann, das manche Rechenoperatoren einen höheren Rang haben als Andere.

    0
  • S

    Mir ist bei den Standarddatentypen float und double etwas aufgefallen. Wenn man mit den Standarddatentypen float von -3 auf 3 hochzählt, erhält man bei Doppeltkernprozessoren in der Mitte keine Null; nur bei einfachen Prozessoren. Verwändet man aber double, so erhält man bei Doppeltkernprozessoren in der Mitte eine Null. Sehr interessant. Dieses Experiment habe ich mal zu meiner Praktikumszeit auf zwei verschiedene Rechner ausprobiert.

    0
  • C
    Mod

    stefan2008 schrieb:

    Mir ist bei den Standarddatentypen float und double etwas aufgefallen. Wenn man mit den Standarddatentypen float von -3 auf 3 hochzählt, erhält man bei Doppeltkernprozessoren in der Mitte keine Null; nur bei einfachen Prozessoren. Verwändet man aber double, so erhält man bei Doppeltkernprozessoren in der Mitte eine Null. Sehr interessant. Dieses Experiment habe ich mal zu meiner Praktikumszeit auf zwei verschiedene Rechner ausprobiert.

    Ich verstehe immer nur Bahnhof.

    0

  • Wie ging das Zitat nochmal genau? Irgendwas vonwegen wenn man schätzen will nimmt man floating-point, wenn man rechnen will Integers.
    War das von Knuth oder von wem?

    Soviel nur zum Thema Null 🙂

    p.S.: falls der Doppelkern ein Core Duo (ohne 2) war... der Core Duo hat AFAIK einige bekannte Bugs, würde mich nicht wundern wenn da auch die FPU betroffen ist.

    0
  • S

    @camper
    Ich meinte folgendes:

    #include <iostream>

using namespace std;

int main(void)
{
	for(float c = -3; c < 4; c++)
	{
		cout << c << '\n';
	}
	return 0;
}

    Ausgabe:

    -3
-2
-1
-0.001 <- != 0
1
2
3

    @hustbaer
    Du hast vielleicht recht. Der PC mit ich in der Firma gearbeitet habe, hat ein Core-Duo-Prozessor gehabt. Bei meinem Laptop ist, wie erwartet, eine 0 heraus gekommen.
    Ich habe in mein Buch das Zitat auch einmal gelesen.

    0
  • S

    also ich habe einen Intel(R) Core(TM)2 Duo CPU und bei mir wird es stets richtig ausgegeben.

    0
Anmelden zum Antworten