myGully.com

myGully.com (https://mygully.com/index.php)
-   Programmierung (https://mygully.com/forumdisplay.php?f=67)
-   -   [C++] Mehr Nachkommastellen (https://mygully.com/showthread.php?t=2209093)

waldfee0071 18.01.11 14:27

[C++] Mehr Nachkommastellen
 
Im Moment mache ich mir den Spaß und versuche mich an der Mandelbrot-Menge.
[Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...]

An sich alles nicht das Problem, jedoch wird bei starkem Zoom die grenze des double Datentyps ziemlich ausgereizt. long double bietet auch nur auf 2-3 stellen höhere Genauigkeit. Ich möchte aber höhere Genauigkeit erzielen, also Rundungen möglichst vermeiden.

Allerdings fällt mir keine bessere Lösung ein, als eine Klasse dafür zu schreiben, die das übernehmen soll. Im Sinne von:

Code:

Beispiel:

wert = 2.567890
int n = 2567890
int i= 6 // anzahl nachkommastellen

das praktisch direkt bei der Rechnung der wert in 2 int werte aufgespalten wird, und im nachhinein mit 10erpotenzen die Kommastelle "nachträglich" hinzu gefügt wird. Ja, ich bin iwie schlecht im Dinge erklären ^^

Meine Frage: Gibt es eine einfachere möglichkeit dafür ? Man muss das Rad ja net immer neu erfinden, also kennt jmd eine Library, die eben diese Funktion übernimmt ?

Mfg Waldfee

germgerm 18.01.11 15:14

Da googelst du am besten nach "Langzahlen-Arithmetik".
Ich kenne zB die Klassenbibliothek C-XSC.

waldfee0071 18.01.11 15:42

erstmal danke, doch auch mithilfe dieser library wirds nach ca. 20+ nachkommastellen ungenau.

Ich suche eher etwas, dass dann den CPU belastet und die rechenzeit höher wird, als an genau dem Punkt dann aufgrund von zeitersparniss abstriche zu machen

neffinator 18.01.11 16:22

1. es gibt einige bibliotheken dafür
2. schreib es dir selber, jede ziffer ist ein int, die miteinander über pointer verbunden sind...praktisch n int-array

tha_specializt 18.01.11 17:07

Zitat:

Zitat von waldfee0071 (Beitrag 21792750)
long double bietet auch nur auf 2-3 stellen höhere Genauigkeit.

Äh ... nö. Long double hat mit gcc 80 Bit - der Unterschied zwischen 64 und 80 Bit ist enorm, nach all meinen Kenntnissen und meiner Vermutung nach ist alleine der Unterschied sogar größer als die der komplette Zahlenraum mit 64 Bit ... denn pro Bit steigt der Zahlenraum bzw. die Anzahl der möglichen Permutationen nicht linear - das mal so als Geheimtip :unibrow:

Also wenn long double nicht ausreicht bieten manche Compiler sogar long long double (ich weiss, klingt lächerlich) - sofern es nicht nur ein typedef auf long double ist haste da direkt mal 128 Bit. Und ... tut mir leid - wenn 128 Bit für dich nicht ausreichen dann versuchst du gerade die Anzahl aller Teilchen im Universum zu erfassen oder du spielst mit multidimensionaler Mathematik herum und suchst nen Beweis für die M-Theorie :D
Nun, bei Fliesskommazahlen geht eine gewisse Wortbreite verloren weil die Mantisse separat gespeichert werden muss ... in dieser Größenordnung (> 64 Bit) ändert das aber nich mehr spürbar viel

waldfee0071 18.01.11 18:17

long double hin oder her, ab nem gewissen zoom-grad gibt es ungenauigkeiten und kurz danach crash mit verletzung von zugriffsrechten beim speicher, die ich mir wohl gemerkt nicht erklären kann :cry:

ich fürchte ich muss den kram doch selber basteln, trotzdem danke an alle... bis auf neffinator, der nur klugscheißt xD

close plz

tha_specializt 18.01.11 18:21

Zitat:

Zitat von waldfee0071 (Beitrag 21793868)
acrash mit verletzung von zugriffsrechten beim speicher

Das ist in 99,999999999999999999999999999999999999999999% aller Fälle ein Programmierfehler ... wenn ein Datentyp voll is läuft er über aber verursacht keine Crashs

waldfee0071 18.01.11 18:59

ja, merk ich auch gerade .... die variablen für die position der pixel fallen unter 1.0, deswegen wird versucht die gleichen pixel mehrfach zu berechnen/beschreiben .... ich glaub da muss ne routine her, die checkt, ob die schon beschrieben sind ^^ Oder ich belasse es enfach debei und schränke den zoom ein ... mein alter lappie rechnet an den "unteren" ebenen schon bis zu 20 sec :lol:

Das erklärt dann die Fehler im Bild und den daraus resultierenden crash ... trotzdem nochmal danke für den tipp mit dem long double ^^

Your_Conscience 02.02.11 15:16

Tud mir leid, dass ich euch jetzt wiedersprechen muss: long double hat einen weit aus größeren Wertebereich als double das stimmt schon - ist aber kein Stück genauer.


Alle Zeitangaben in WEZ +1. Es ist jetzt 04:08 Uhr.

Powered by vBulletin® (Deutsch)
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.