CK_CK hat folgendes geschrieben:

(...) ohne Runden sieht's so aus, wie du es willst

"Wie ich es will" Naja, für mich ist der Unterschied von a nach b etwa so gross wie von ohne Antialiasing zu mit Antialiasing. Vielleicht sieht man das nur auf einem LCD-Bildschirm so richtig?

Beim Zeichnen von Buchstaben macht Windows mit Cleartype ja sogar noch eine Subpixeloptimierung - berücksichtigt also, dass die drei Grundfarben (Subpixel) rot/grün/blau des Bildschirmes nebeneinander angeordnet sind. Das macht nochmals eine Verbesserung von ca. 20% aus. Soweit würde ich bei den Plots dann aber doch auch nicht gehen (Beim Mandelbrotbild im Anhang habe ich das spasseshalber mal gemacht )

Keine Ahnung, ich habe auch nur TFT-Bildschirme hier
Da sieht man wirklich einen deutlichen Unterschied!

Die neue Version ist fertig...

Version 1.0 beta2
+ Render-Einstellungen - Dialog hinzugefügt (z.B. Auswahl, ob AntiAlias aktiv sein soll)
+ Render-Einstellungen werden beim Beenden gespeichert
* Graph-Rendering verbessert (genauer)

Der neue Render-Einstellungen - Dialog


Viele Grüße,
Chris

Ich glaube die Zip-Datei für beta2 ist die gleiche wie die von beta1.

Ups, gut dass mir das mal jemand sagt

Hab' die Datei aktualisiert... *peinlich*

Chris

Hier noch ein Hinweis. Macht aber kein mir bekannter Plotter, wäre aber eigentlich wichtig. Anti-Aliasing der Linien sieht schön aus, aber garantiert noch lange nicht, dass der Plot korrekt ist. Der Graph/Plot einer Funktion ist nämlich definiert als die Punktmenge (x,f(x)) mit x reell. Wenn man für x nur einige wenige Werte rauspickt, muss man aufpassen.

1. Wenn die Abtastweite dem Nyquist-Shannon-Theorem nicht genügt, gibt es Aliasing-Artefakte. Du machst implizit die Annahme, dass die lokale Abtastfrequenz mindestens doppelt so hoch ist wie die lokale Frequenz der zu zeichnenden Funktion. Ist dies nicht der Fall, zeichnet dein Plotter eine falsche Funktion Der Effekt ist der gleiche wie bei einem Film, wo sich die Autoräder plötzlich rückwärts drehen. Die Darstellung kann also von der Realität fast beliebig weit abweichen.

Verdeutlichung im Anhang:
Wenn die Frequenz einer Funktion stetig zunimmt und nicht mehr genügend hoch abgetastet wird, dann gibt es einen Phasensprung: Die Frequenz der gezeichneten Funktion springt plötzlich ins Negative (bei gleichbleibendem Betrag). Nimmt die Frequenz der zu zeichnenden Funktion weiter zu, nimmt der Betrag der Frequenz der gezeichneten Funktion ab, bis sie Null wird (dieses Spiel wiederholt sich dann immer wieder). So ein Phasensprung führt zu einer Spiegelung und Wiederholung (siehe Bild Anhang, oben): Die geplottete Funktion weicht extrem von der Realität ab. Korrekter wäre die Darstellung im zweiten Bild unten (wobei auch hier gesagt werden muss, dass der Raum an den Enden keineswegs vollständig ausgefüllt wird, sondern eigentlich viel mehr Punkte weiss als schwarz sein müssten aber das ist eine Darstellungsfrage).

Durch eine adaptive Schrittweitensteuerung könnte man sowas automatisch umgehen. Das ist aber vermutlich nicht ganz so einfach zu implementieren. In einem "Final Rendering" sollte man aber vielleicht zu mindest die Schrittweite verfeinern können (auch wenn sie nicht dynamisch ist).

2. Ich habe gesehen, dass bei Polen (z.B. 1/(x-1)) kein Strich die Unstetigkeit verbindet. Das ist auch richtig so. Bei Sprungfunktionen jedoch (z.B. abs(x-1)/(x-1)) wird die Unstetigkeit verbunden. Laut Definition eines Graphen ist dies eigentlich falsch.

Sind nur Hinweise

Respekt, du scheinst dich gut mit sowas auszukennen...

Also, zu 1: Der Plotter berechnet für jeden Breitenpixel einen Höhenpixel (bei 800x600 werden also 800 Werte dargestellt). Deswegen fällt mir im Moment keine Möglichkeit ein, wie ich das genauer machen kann...
Ich werde aber mal gucken, ob/wie ich eine "adaptive Schrittweitensteuerung" einbauen kann

Zu 2: Das ist auf jeden Fall nicht gewollt. Ich werde versuchen, den Fehler zu finden...

Chris

Einfache Lösung zu 1 wäre, wenn du noch eine Option einbaust, damit der User selbst eingeben kann, wie gross die Schrittweite sein soll. z.B. bei "10x Oversampling" würde man bei 800x600 entsprechend 8000 Striche zeichnen statt 800. Dann ist der User dafür "verantwortlich" einen genügend kleinen Abstand zu wählen, um ein schönes Bild zu erhalten Mit der GDI+ kann man ja ohne Probleme mit halben Pixeln arbeiten. Entsprechend langsam wird der Bildaufbau natürlich...

Wie gesagt macht das ja eigentlich kein mir bekannter Plotter. War nur so ne Idee.

GeoGebra scheint die Funktion (fast) richtig zu zeichnen, ist aber auch sichtlich überfordert damit


mfg

So, vielen Dank für die Idee. Oversampling ist eingebaut:

Version 1.0 RC1
+ Oversampling-Funktion eingebaut. Noch genauere Plots möglich
* Oversampling-Einstellungen im Render-Optionen - Dialog eingebaut
* Oversampling-Einstellungen im Bild formatiert speichern - Dialog eingebaut

In Anhang sind Vergleichsbilder...

Sonnige Grüße,
Chris

Noch ein Vorschlag zur Geschwindigkeitsoptimierung. Im Moment wird beim Verschieben der Achsen via Drag&Drop bei jeder Mausbewegung alles neugezeichnet. Besser wäre, wenn der Plot nur dann neugezeichnet wird, wenn auch wirklich etwas verschoben wurde. Gib z.B. mal rand(1) ein und versuche die Achsen wenig zu verschieben.

Ja, da war ein Invalidate an der falschen Stelle...

Ich habe viele neue Funktionen eingebaut und würde mich über weitere Tests freuen:
Version 1.0 RC2
+ Die Plots lassen sich jetzt in beliebigen Größen drucken
+ Kurvendiskussion (alpha-Version) hinzugefügt
+ Wertetabelle hinzugefügt (Ausgabe als .csv möglich)
+ Versionscheck über das Internet möglich
+ About-Dialog hinzugefügt
+ X/Y - Werte unter der Maus werden unter dem Plot angezeigt
+ Mit der Mittleren Maustaste lässt sich ein Punkt markieren (mit Beschriftung)
+ Vollbildanzeige mit Doppelklick oder rechter Maustaste
* Der Plot wird bei Mausbewegungen nur noch bei Bedarf aktualisiert

Liebe Grüße,
Chris

Vielleicht diese zwei Sachen:
- Doppelte Nullstellen (x^2) werden nicht erkannt.
- Schliessen von Dialogfenster (z.B. About-Box) via Escape

"Doppelte Nullstellen (x^2) werden nicht erkannt."
> x^2 hat auch nur eine Nullstelle Aber die wird auch nicht erkannt. Ich muss den Algorithmus da noch anpassen.

Ich hab' mir das so gedacht: Man lässt eine Funktion plotten (z.B. x^2-5) und doppelklickt dann in der Funktionsliste auf diese Funktion. Dies öffnet die Kurvendiskussion.
Man sieht jetzt in dem Plot, dass irgendwo zwischen 2 und 3 eine Nullstelle liegt, also kann man diese Werte als Intervall wählen. Und schon bekommt man das Ergebnis (2,23606797750108)...

"Schliessen von Dialogfenster (z.B. About-Box) via Escape"
> Hört sich gut an. Wird mit eingebaut...

Chris

x^2 hat zwei Nullstellen:


auch wenn sie an der gleichen Stelle sind, sind es zwei (Quadratische Gleichung -> Zwei Lösungen)

mfg

x^2 hat nur eine Nullstelle, die ist aber doppelt (nennt sich so, per Definition). "Gerade Nullstellen" (dazu gehören doppelte) überqueren die x-Achse nicht, ungerade jedoch schon. Siehe "Vielfachheit einer Nullstelle".

Aber ich denke, es ist umgangssprachlich okay wenn man statt "eine doppelte Nullstelle" auch mal "zwei Nullstellen" sagt. Aber genau genommen ist nur eine Stelle Null, also nur eine Nullstelle. Aber da man die Nullstellen irgendwie unterscheiden können will, sagt man eben, dass sie doppelt ist.

Ja, Nullstellen können einen schon zum Grübeln bringen *g*

Naja, ich hab' eine neue Version fertiggestellt:
Version 1.0 RC3
+ Für sämtliche Funktionen existieren jetzt Hotkeys
* Im Vollbildmodus ist nun auch die Leiste mit Zusatzinfos zu sehen
* Fehler in der Druckfunktion behoben
* Die Berechnung des Plots beim Speichern geht schneller

Tretet ruhig mal so richtig dagegen

Chris

Hi, wie alle sehen könnt ist das mein erster Beitrag
Den Plotter finde ich toll, auch wenn ich das schlecht vergleichen kann, da ich noch keinen anderen gesehen habe

Ich habe das zoomen einfach mal ausprobiert und finde, dass größere Zahlen nichtmehr durchgehend skaliert werden sollten.
Da es aber weiterhin möglich sein soll, auch einen kleinen Bereich heranzuzoomen(bei dem dann ja, sofern er ungünstig getroffen wäre, keine Skalierung mehr vorhanden wäre) schlage ich vor, dass eine konstante Anzahl an Zahlen angezeigt werden sollte.

Hi! Erstmal ein herzliches im Delphi-Forum!

Ja, du hast Recht. Die Zoomen-Funktion sollte ich noch einmal überarbeiten. Zur Zeit wird nämlich beim Zoom der X-, bzw. Y-Bereich vergrößert/verkleinert und die Schrittweite bleibt konstant.

Vielen Dank auch, dass du das Programm getestet hast

Chris

PS: Wenn du über die nächste Version benachrichtigt werden willst, kannst du unter "Hilfe"->"Update" "Automatisch prüfen" aktivieren...

Habe ich schon gemacht, ist echt praktisch, das entsprechende Fenster geht ja beim Start automatisch auf

Ich denke außerdem, dass der durch das Zoomen veränderte Bereich(und die veränderte Schrittweite, wenn das implementiert ist) auch im manuellen Einstellungsblock verändert werden sollten.
Da das nicht ganz offensichtlich ist: Das Bild im Anhang oben ist einfach mal extrem gezoomt, um das Problem zu verdeutlichen; die vielen grauen Striche sind die vielen angezeigten Zahlen in sehr geringem Abstand(Skalierung).
Die neu einsetzenden Striche sind jeweils die Punkte, an denen die Zahl um eine Stelle länger wird, also die Dezimalübergänge.