C# Große Zahlen ganz anzeigen lassen

the_nobs schrieb:
double hat einen Wertebereich von ±4.9E-324

Da sind also noch ein paar stellen übrig (so ~310 das Komma nach links und ~330 das Komma nach recht zu verrücken)

:)

Das kommt mir sehr willkürlich vor, weil es ja nicht um Nachkommastellen sondern um Intervalle geht, die komplex aufgebaut werden.

https://stackoverflow.com/a/9999508
 
Okay, da ich leider ein recht amateurhafter Programmierer bin (was jetzt nicht heißen soll, das ich nicht interessiert bin), kann mir vielleicht jemand helfen? Ich soll also die ToString()-Überladung nutzen, nur wie?
 
Ne wenn du halbwegs aussagekräftige Ergebnisse willst solltest du meinen beiden Links folgen.
Auch 64bit CPUs können natürlich viel mehr bits verwenden, um eine einzige Rechnung durchzuführen ohne Genauigkeit zu verlieren. Es dauert dann halt ein paar Nanosekunden länger.
Da Computer da aber vor allem mit beliebig großen Integern gut rechnen können ist die naheliegende Umsetzung für Komma-Zahlen, dass man Brüche verwendet. Dies erlaubt auch beliebige Genauigkeiten, weil die rationalen in den reelen 'dicht' liegen dh dass man zu jeder reelen Zahl aus R eine Zahl in Q finden kann die beliebig nah dran ist.
Daher auch BigRational: Der Computer verwendet dann für Zähler und Nenner des Bruchs halt wieder BigInteger die in den meisten Sprachen zur Verfügung stehen und so weit wachsen können, wie Speicher zur Verfügung steht.
Durch BigInterger statt Integer kann man halt auf einer beliebigen CPU (egal ob 8, 16, 32 oder 64 bit) so große Berechnungen exakt durchführen, wie der Speicher es zulässt. bei float/double wird meist maximal das doppelte oder evtl. noch vierfache der Wortbreite der CPU verwendet.
 
Zuletzt bearbeitet:
@kuddlmuddl: Inwiefern hat das mit dem Thema zu tun?

​@MarshallMathers:
Ich hab doch eigentlich einen Link angegeben (https://docs.microsoft.com/de-de/dotnet/standard/base-types/standard-numeric-format-strings), welcher das genau noch einmal alles erklärt.

Code:
dblValue.ToString("N15", CultureInfo.CreateSpecificCulture("de-DE"))
dblValue.ToString("F15", CultureInfo.CreateSpecificCulture("de-DE"))
​N -> Mit 1000er- Trennzeichen, F-> ohne 1000er- Trennzeichen
​CultureInfo kannst du auch weglassen.
​15, weil Genauigkeit von double
 
Zuletzt bearbeitet:
Okay, ich werde den mir mal anschauen.
Puh, also ich weiß ja, dass zwischen "Es funktioniert" und "Es ist gut" ein großer Unterschied besteht, aber da prasselt gerade viel auf mich ein, ich bin halt noch ein Programmieranfänger. Mit deinem Code kann ich leider nichts anfangen. Wenn ich die Berechnung in einem Double speichere, wie kann ich dann die ToString()-Überladung nutzen, um die Nachkommastellen-Genauigkeit zu erreichen, die hier von manchen bemängelt wird? Wie "integriere" ich das in deinen Code?
 
Bemängelt wird das eigentlich nicht - brauchst du denn für deinen Zweck eine Genauigkeit, welche über 15 Stellen hinausgeht? Hört sich für mich nicht wirklich so an.

Anwendung:
Code:
​var dblValue = 3333333333333.044432;
Console.WriteLine(dblValue.ToString("N15", CultureInfo.CreateSpecificCulture("de-DE")));
​​​
 
@kuddlmuddl: Inwiefern hat das mit dem Thema zu tun?
Das löst die Genauigkeits-Probleme? Oder wie war die Frage gemeint? Hier wird doch ewig darüber diskutiert, dass ein float/double nix taugt für die Anforderung.
Durch BigFraction oder ähnliches kann man in beliebigen Wertebereichen genau rechnen und auch Zahlen mit enormen Größenunterschieden verrechnen.

Bemängelt wird das eigentlich nicht - brauchst du denn für deinen Zweck eine Genauigkeit, welche über 15 Stellen hinausgeht? Hört sich für mich nicht wirklich so an.
Das Problem meiner Meinung nach ist, dass man natürlich mit einem Endergebnis leben kann, welches 15-stellige Genauigkeit bietet - diese aber evtl bei weitem nicht erreicht.
Spätestens wenn Brüche oder Multiplikationen in der Berechnung auftauchen ist immer die Gefahr, dass float/double zu 0 werden und dadurch extrem große Fehler entstehen - wo dann nichtmal grob die anzahl der Ziffern VOR dem Komma (bzw der Exponent bei e... Darstellung) stimmen. Eine andere Ursache wäre, dass bei einem Zwischenergebnis der Wertebereich von float/double nicht ausreicht und daher am Ende auch nur Mist rauskommt, obwohl es da wieder gepasst hätte.
 
Hier wird doch ewig darüber diskutiert, dass ein float/double nix taugt für die Anforderung.
​Wo? Das erste Mal, wo Genauigkeit ins Spiel kam ist zu dem Zeitpunkt, als zu decimal gecastet wurde (was eine höhere Genauigkeit ermöglicht).

Extrem hohe Genauigkeitsanforderungen sehe ich mit dem folgenden Einsatzzweck nicht unbedingt gegeben:
ein Programm in C# geschrieben, mit dem ich mir bestimmte Einheiten in bestimmte anderen Einheiten umrechen lassen.



 
The Ripper schrieb:
Extrem hohe Genauigkeitsanforderungen sehe ich mit dem folgenden Einsatzzweck nicht unbedingt gegeben:

A-aber, das ist für Weltraumzeugs!
Aber okay, dann benutz du doch so einen ungenauen Rechner. Wenn ich mich teleportieren soll, da sind mir die paar Kilometer oder Zentimeter Unterschied im All sehr wichtig!
 
Leute

Sorry, da ist sehr viel halbwissen unterwegs..

Die Genauigkeit von Double ist schon viel vorher beschränkt als die 15 nachkommastellen
mach zwei schleifen, 1x addierst du 1 million mal 0.0001 und 1x multiplizierst du 1000000 mit 0.0001
und du wirst zwei verschiedene Ergebenisse erhalten...

Nichtdestotrotz kannst von ~15 stellen Genauigkeit nach dem Komma (oder auch vorher) ausgehen
da es aber eine Fließkommazahl ist, kannst das auch verschieben.
d.h. 0.123456789 * 10^0 kannst genau darstellen, aber auch 0.123456789 * 10^-210 !!

-> die Genauigkeit von Double ist relativ :-)
und für die Astronomie reicht das meistens locker (vor allem für die Hobby astronomie)

Beispiel Entfernung Mars Erde ist max 401000000 km oder 4,01 ~10^9 m!!!
bei ~15 nachkommastellen hast noch immer 6 nachkommastellen übrig, d.h. du kannst die Entfernung von Mars und Erde mit double auf fast micrometer genauigkeit darstellen!
nur Damit ihr eine Abschätzung der Genauigkeit habt
 
Na gut, dann lasse ich das jetzt so... und ich werde demnächst mal versuchen, das leidige Thema mit der Präzision mal selber zu verstehen.
 
Zurück
Oben