Historische Performance und Volatilität

Eine Bubblegrösse abhängig vom Anteil im Portfolio wäre natürlich super :blush:

Leider unterstützt die Grafikbibliothek das nicht…

Um die Varianz zu berechnen, müsste man doch nicht nur die Einzelabweichungen vom Mittelwert quadriert aufaddieren sondern auch hinterher durch die Anzahl an Werte teilen. Das finde ich im Quellcode aber nicht. Was habe ich hier nicht verstanden?

Standardabweichung ist dann die Quadratwurzel der Varianz und der Korrekturfaktor count/(count-1) kompensiert, dass man den Mittelwert auch nur schätzt, das ist alles klar.

1 Like

Ich glaube fast, du hast da einen Fehler gefunden, und in Zeile 146 und 147 muß jeweils das * count weg.

Ja, das ist falsch. (Das erklärt auch, warum der Wert so stark von der Länge des betrachteten Zeitraums abhängt …)

Ich werde das demnächst beheben; ich wollte ohnehin richtig annualisierte Werte einbauen.

Ich habe mir eine Übersicht über die historischen Volatilitäten und Renditen meiner Einzelwerte im Portfolio gemacht. Aktuell hat jede Position aber einen Kreis mit der gleichen Grösse. Wäre es möglich die Grösse der Kreise an die Grösse der Portfolioposition anzupassen?

2 Likes

Zu dem source code der Volatilitätsberechnung:

  1. Nur zu meinem Verständnis: Ich vermute, dass in dem array returns die täglichen Veränderungen drinstehen? Anders formuliert, pro Tag der Wert (Schlusskurs / Schlusskurs_Vortag - 1)?
  2. Ist die Formel inzwischen korrigiert? Ich sehe in Zeile 146/147 immer noch die Multiplikation mit count.
  3. Ich habe gelernt, dass man die Berechnung der Standardabweichung mit der Division durch (count - 1) durchführt, wenn es sich um eine Stichprobe aus einer zu schätzenden Grundgesamtheit handelt. Das ist aber meiner Ansicht nach hier nicht der Fall - ich will die Standardabweichung der gewählten Aktie in genau dem Zeitraum berechnen, der mich interessiert. Das ist keine Stichprobe und es gibt auch keine unbekannte Grundgesamtheit - alle Kurse sind bekannt. Daher müsste die Formel nicht durch (count - 1) teilen, sondern durch count. Spielt natürlich in der Realität, wo ich mit vielen Einzelwerten arbeite, so gut wie keine Rolle, aber manchmal geht’s halt ums Prinzip :wink:
  4. Wenn meine Annahme unter 1) richtig ist, warum wird der Wert dann noch einmal logarithmiert (logReturn)? Je mehr ich mir den Code anschaue desto weniger verstehe ich ihn.
1 Like

Inzwischen habe ich ein Excel Sheet mit den DAX Schlusskursen der letzten 12 Monate. Ich kann die von PP angezeigten Volatilitätswerte für die Zeiträume letzte 3 / 6 / 12 Monate exakt nachvollziehen, allerdings nicht mit den im Wiki verlinkten Source Code (sondern ohne Logarithmus, und unter Verwendung eines Korrekturfaktors, den ich dem Bereich ‘Wissen’ auf der Consors-Webseite entnommen habe).

  1. Wird inzwischen ein anderer Algorithmus verwendet und der verlinkte Source Code ist möglicherweise veraltet?
  2. Warum decken sich die von PP angezeigten (und von mir auf einem anderen Weg identisch berechneten) Volatilitätswerte nicht mit dem, was finanzen.net (unter DAX 30 / Vola/Rendite) anzeigt? Der 12 Monatswert passt noch so ungefähr, aber die 3 und 6 Monatswerte sind deutlich höher. Später: Ok, die Frage ziehe ich zurück - die DAX Volatilität auf boerse.de passt zu den PP Werten für alle drei Zeiträume (3 / 6 / 12 Monate). Logisch dass die 3-Monats-Volatilität deutlich unter den 12-Monats-Werten liegen muss - in dem 12-Monats-Zeitraum liegt ja noch der erste Covid-Crash.

Dann würde nach dem Fix ungefähr sowas rauskommen?


Momentan steigt die Vola ja mit zunehmendem Betrachtungszeitraum.
Das wäre eine schöne Erweiterung.
Vielleicht könnte man im Rendite/Vola-Diagramm mit TTWROR die Vola nicht annualisiert anzeigen, bei IZF-Einstellung jedoch annualisiert?

So, kleines Update.

  • Inzwischen hab ich auch die Berechnung über log(returns[ii]+1) begriffen, denke ich. Ein bisschen Verwunderung, dass das nirgendwo zurück de-logarithmiert wird, verbleibt, aber ich bin kein Finanzmathematiker.
  • Sobald man sich im Internet bei den üblichen Verdächtigen Volatilitätsdaten (z. B. zum DAX) anschaut, sieht man, dass sich die Zahlen für unterjährige Zeiträume unterscheiden (z. B. für eine 3- bzw. 6-Monats-Volatilität. Da haben boerse.de, boerse-online.de, onvista.de, finanzen.net durchaus substantiell unterschiedliche Zahlen, benutzen also unterschiedliche Formeln bzw. Algorithmen.
  • Intuitiv würde ich eine Berechnung vorziehen, die - bei gleicher Streuung - die gleichen Volatilitätswerte liefert, egal ob ich 1, 3, 6 oder 12 Monatsdaten anschaue. Eine solche Berechnung habe ich in Excel erstellt und mit Hilfe von synthetischen Kursdaten (mit einstellbarer durchschnittlicher Rendite und Streuung) validiert. Ich stehe da gerne zu einem weiteren Austausch zur Verfügung.

Mein Plan wäre, es wählbar zu machen; d.h. man kann dann sowohl IZF als auch TTWROR wahlweise annualisiert bekommen oder auch nicht, und die Volatilität ebenfalls. Beim Diagramm gäbe es dann nur eine Auswahlmöglichkeit für beide Achsen.

Die entsprechende Mathematik habe ich schon vor ein paar Wochen implementiert – schwieriger ist die Oberfläche, da bin ich auch wegen Zeitmangel noch nicht sehr weit gekommen.

1 Like

Gut Ding will Weile haben, bloß kein Stress :slight_smile:

Hallo,

ich habe leider noch einige Verständnisschwierigkeiten bezüglich der Kennzahlen/Risikokennzahlen.

Ich habe ein Musterdepot, welches ich zu Übungszwecken in PP abbilde. Nun habe ich die Möglichkeit entdeckt, dass man statt Buchungen über ein Verrechnungskonto, auch Einlieferungen nutzen kann.
Zum Vergleich und Kontrolle habe ich dann alle Kaufbuchungen in Einlieferungen umgewandelt.

Kann mir jemand erklären, warum die Kennzahlen in der Ansicht Berichte → Performance abweichen, obwohl sämtliche Werte der Performance-Berechnung identisch sind?

Danke und Gruß Relaxo

EDIT: Noch ein Foto über den Kontostand hinzugefügt

Einlagen nicht am selben Tag wie die Käufe (wie es bei Einlieferungen zwangsläufig ist).

Danke.

Was meinst du mit Einlagen nicht am selben Tag wie Käufe? Bei Einlieferungen habe ich ja keine Käufe.

Was ist der Unterschied zwischen Kauf und Einlieferung und kann man dies nachträglich ändern?
Möchte man zum Beispiel das zugehörige Konto gar nicht in Portfolio Performance führen, benötigt man die Gegenbuchung nicht. In diesem Fall ist es sinnvoll, statt einem Kauf eine Einlieferung zu verwenden. Bei einer Einlieferung erhöht sich nur der Bestand des Wertpapiers im Depot, ohne dass ein Konto entsprechend im Wert reduziert wird.

Ich verstehe es so Einlage = Buchung Bargeld auf Verrechnungskonto, Einlieferung ist “Gutschrift” auf Depot ohne Kontobuchung.

In der Datei mit Kauf/Verkauf und Buchungen von Einlagen auf das Verrechnungskonto erfolgte die 1. Einlage am 8.6. 20 (Berichtszeitraum beginnt am 7.6.20) und bis 2021 wurden verschiedenste Papiere gekauft. Das Einlagedatum ist also ein anderes, als das Kaufdatum.

Oder meinst du, ich soll in der Datei ohne Verrechnungskonto das Einlieferungsdatum verändern? Der Effekt wäre dann, dass die Performance übereinstimmt? Den Zusammenhang mit dem Datum verstehe ich leider nicht.

Ich denke, ich habe jetzt einen passenderes Thema gefunden.
Beiträge bitte gegebenenfalls verschieben? tut mir leid, dass ich das zu spät entdeckte.

Hier wird genau mein Problem geschildert.

Es ist also das Bargeld auf dem Verrechnungskonto, das die unterschiedliche Performance erzeugt. Im Nachhinein auch logisch.
Um das zu umgehen, muss man sich eine eigene Auswertung/Dashboard anlegen.
Mit dem Standard-Dashboard geht das leider nicht.

Aufpassen muss man in der Auswertung dann noch bezüglich Dividenden und Verkäufe.

Genau das: …

Das ist in obigem Fall gegeben, ändert also nichts an der unterschiedlichen Performance.
Es ging mir um den Unterschied der beiden Optionen Einlage vs. Einlieferung und deren Auswirkung auf die Performance.
Das ist ja nun im Prinzip geklärt.

Der Sinn der Änderung der Daten zur Lösung des Problems erschließt sich mir leider nicht.

Nach meinem Verständnis würde man die Performance beeinflussen, wenn man am Einlagedatum, oder Kaufdatum rumschraubt.
Will man einen Kontoverlauf real abbilden, dann müssen die Einlagen auch mit den realen Daten der Transaktionen erfolgen.
Will man den realen Zuwachs/Abgang der Wertpapiere im Depot abbilden, sollten auch die Einlieferungen das tatsächliche (Kauf)Datum haben. Die Einlieferung ist im Prinzip ja nichts anderes als ein Kauf. Halt nur ohne ein Verrechnungskonto.

Aber womöglich habe ich da etwas falsch verstanden?

Es ist wohl besser für alle, wenn jemand von denen antwortet, die mit einer Engelsgeduld ausgestattet sind. :roll_eyes:

1 Like

Außer 2 Kurzzeiler lese ich nichts von dir, das mir hätte helfen können das Problem zu beschreiben oder zu erklären.

Die Erklärung, warum eine Änderung des Einlagedatums dazu führen sollte, dass beide Performance gleich sind, hast du nicht gegeben. Ist das nicht der Sinn beim Antworten?
Dein Vorschlag war anscheinend, die Einlage vor das Kaufdatum zu setzen. Klar ausgedrückt hast du das leider nicht.

Der Kern des Problems (unterschiedliche Performance Einlage vs. Einlieferung) liegt daran, dass das Barvermögen auf dem Konto in die Performance einfließt.

Liest man den verlinkten Thread, ist dein Lösungsvorschlag nunmal nicht die Lösung. Und wenn, dann fehlen konkrete Hinweise, bzw. Fragen.
Du wusstest ja gar nicht welches Datum die Einlagen haben.

Das jetzt so hin zu drehen, dass ich zu doof bin ist nicht sehr nett. Schade, dass deine Geduld nach 2 Kurzzeilern schon erschöpft ist.

Außerdem wäre es logischer, gerade das Datum der Einlage auf den Tag des Kaufes zu setzen. Dann nämlich sammelt sich auf dem Konto kein performancebeeinflussendes Barvermögen an.
Legt man - wie von dir vorgeschlagen - das Einlagedatum vor das Kaufdatum wird ja eher das Gegenteil erreicht. Nämlich dass die Performance zw. Kontobuchung und Einlieferung noch stärker voneinander abweichen.

Bleibt die Frage, wer etwas falsch verstanden hat?

EDIT: Alternativ, ob du deine Antworten etwas konkreter und verständlicher mit ein paar mehr Sätzen formulieren könntest.

Du wolltest wissen,

Ich nenne dir den Grund:

Logische Fortsetzung: Wenn du gleiche Ergebnisse für a) Einlieferung wie für b) Einlage+Kauf haben willst, müssen die Daten übereinstimmen, wie das im Fall a)

Denn sonst liegt, wie du ja schon festgestellt hast, zwischen dem Datum der Einlage und dem Datum des Kaufs Geld auf dem Konto, was ein Unterschied ist.

Es ist ja nicht so, daß es keine Vorgeschichte mit dir gäbe. :roll_eyes: