implementierung von mandelbrot zeigt abstufungen
-
hallo
bei meiner implementierung der mandelbrot-menge zeigen sich ab einem gewissen zoomfaktor abstufungen. normalerweise wird jedes pixel auf dem bildschirm einzeln berechnet, daher weiss ich nicht wieso das so kommt. ich habe mal den projektweiten fliesskommatyp auf long double gesetzt und es hat erstaunlicherweise in der exakt selben situation gar nichts verändert (nicht ein bildpunkt der ausgabe ist anders). hier ist ein bild davon damit man sich das besser vorstellen kann:
http://img4host.net/upload/090319025254af06e0ba6.png
was mir ebenfalls höchst suspekt ist ist die nicht-quadratische anordnung dieser "segmente".muss ich für einen besseren zoom also einen neuen fliesskomma-typen mit z.b. 256bits implementieren?
gruss
-
Wenn eine Änderung zu double nichts gebracht hat sollte auch eine Änderung zu einem 256bit fließkommatyp nichts bringen.
Ich hätte jetzt aber schon drauf getippt dass das an der Genauigkeit liegt, sicher dass du in keiner berechnung mehr float verwendet hast ?Aber irgendwann wirst du sowas nicht vermeiden können, genau solche Ungenauigkeiten tauchen irgendwann bei jedem Fractalberechner den ich kenne auf.
-
igno schrieb:
bei meiner implementierung der mandelbrot-menge zeigen sich ab einem gewissen zoomfaktor abstufungen.
Muss ja. Die Zahlen im Rechner haben nur eine endliche Genauigkeit.
igno schrieb:
ich habe mal den projektweiten fliesskommatyp auf long double gesetzt und es hat erstaunlicherweise in der exakt selben situation gar nichts verändert (nicht ein bildpunkt der ausgabe ist anders).
Das riecht mir dann danach, daß VOR Deiner Rechnung bereits Rundungsfehler entstehen, da wo aus den Bildschirmkoordinaten zum ersten mal floats gebaut werden. Im GUI-Code. Hier würde ich rumsuchen, ob irgendwo ein kleinerer Typ verwendet wird.
igno schrieb:
hier ist ein bild davon damit man sich das besser vorstellen kann:
http://img4host.net/upload/090319025254af06e0ba6.png
was mir ebenfalls höchst suspekt ist ist die nicht-quadratische anordnung dieser "segmente".Rechteckig nicht-Quadratisch ist eher logisch als quadratisch. Achtmal so breit wie hoch, weil Du in der Gegend von -1|0.125 rumschwirrst, der Fehler relativ zum Betrag der Zahl ist gleich.
igno schrieb:
muss ich für einen besseren zoom also einen neuen fliesskomma-typen mit z.b. 256bits implementieren?
Bis da unten haste ja schon 10 Bildschirmverdoppelungen geschafft oder so. Noch mehr? Ja, wäre nett. Aber dann explodiert Dir auch die Rechenzeit. Und soo viel mehr bringt's nicht, 256 statt 64 wäre gerade mal eine viermal längere fahrt.
-
DarkShadow44 schrieb:
Ich hätte jetzt aber schon drauf getippt dass das an der Genauigkeit liegt, sicher dass du in keiner berechnung mehr float verwendet hast ?
volkard schrieb:
igno schrieb:
ich habe mal den projektweiten fliesskommatyp auf long double gesetzt und es hat erstaunlicherweise in der exakt selben situation gar nichts verändert (nicht ein bildpunkt der ausgabe ist anders).
Das riecht mir dann danach, daß VOR Deiner Rechnung bereits Rundungsfehler entstehen, da wo aus den Bildschirmkoordinaten zum ersten mal floats gebaut werden. Im GUI-Code. Hier würde ich rumsuchen, ob irgendwo ein kleinerer Typ verwendet wird.
guter tipp, danke dafür. das projekt ist jedoch noch nicht so gross und daher nutze ich wirklich überall mein typedef. ich hab aber den verursacher dieses verhaltens eben gefunden. bei mir ist sizeof(double)==sizeof(long double) (vc++ express 2010)...
volkard schrieb:
igno schrieb:
hier ist ein bild davon damit man sich das besser vorstellen kann:
http://img4host.net/upload/090319025254af06e0ba6.png
was mir ebenfalls höchst suspekt ist ist die nicht-quadratische anordnung dieser "segmente".Rechteckig nicht-Quadratisch ist eher logisch als quadratisch. Achtmal so breit wie hoch, weil Du in der Gegend von -1|0.125 rumschwirrst, der Fehler relativ zum Betrag der Zahl ist gleich.
lol, wusste ich nicht, danke.
volkard schrieb:
igno schrieb:
muss ich für einen besseren zoom also einen neuen fliesskomma-typen mit z.b. 256bits implementieren?
Bis da unten haste ja schon 10 Bildschirmverdoppelungen geschafft oder so. Noch mehr? Ja, wäre nett. Aber dann explodiert Dir auch die Rechenzeit. Und soo viel mehr bringt's nicht, 256 statt 64 wäre gerade mal eine viermal längere fahrt.
also ich bilde die komplette mandelbrotmenge ab mit einem viewport von 2.5 seitenlänge. das gepostete bild wurde mit einem viewport mit seitenlänge 0.000000000000009 gerendert (ist immer jeweils die höhe gemeint, die breite wird anhand des formats (1920x1080 z.b.) berechnet). weisst du zufällig wie die anderen programme die so 2^900-fachen zoom schaffen arbeiten? wenn ich mit einem 256bit-typen (der wahrscheinlich todeslangsam sein wird) eine nur viermal tiefere fahrt bekomme...
danke für die antworten und gruss
