Erwartete Renditen / Expected returns #1231
Conversation
…of expected returns to asset classes and securities; overall portfolio return (weighted average) is calculated and displayed
|
Hallo @doncristobal, erst mal vielen Dank für den Pull Request und die Mühe die da eingeflossen ist. Ich melde mich erst jetzt, weil ich einiges um die Ohren hatte und weil die Änderung tiefer in den Code eingreift und ich dann nicht "mal eben" drüber schauen kann. Zum Beispiel ändert sich durch den PR die XML Persistenz und das ist eine Änderungen die ich nie zurücknehmen kann. Zunächst inhaltlich zu dem Feature: Ich persönlich halte mich mit Prognosen in PP komplett zurück. PP versucht so gut wie möglich ein Bild von der Vergangenheit zu machen. Das was ist. In das Geschäft mit Aussagen über die Zukunft will ich eigentlich nicht. Natürlich bekomme ich immer wieder Feature Anfragen wie "erwartete Dividenden im nächsten Jahr", aber wie belastbar kann man die treffen? Nun kann man argumentieren, dass hier ja nicht PP eine Prognose abgibt, sondern "nur" ein verbessertes Excel Sheet ist mit vor-implementierten Formeln um in einer hierarchischen Struktur Werte zu aggregieren. Fair point. Ich kann nicht beurteilen wie und wie häufig man ein solches Feature nutzen würde. Hast Du da irgendwelche Blogs, Artikel, Postings im Forum die zeigen wie sowas genutzt wird? Insbesondere wie man das auf sein eigenen Depot anwendet? Und: bräuchte man nicht zumindest ein Risikomaß? Nehmen wir die Kategorie "Emerging Markets": Was sagt mir dass denn mit einer erwarteten Rendite on 6,9%? Da ist doch viel Risiko dabei? Wohin gegen -1% für eine Bundesanleihe relativ gesehen weniger Risiko haben. Ich frage mich, ob eine berechnete Zahl mit Zweinachkommastellen eine Präzision suggeriert die nie und nimmer in der Rechnung steckt? Dann noch ein paar Anmerkungen zu der technischen Implementierung: Wenn ich das richtig sehe, ist das Feld Aktuell werden Classification und Assignment um Felder erweitert. Die sind dann da für immer drin. Und da ich an einigen Stellen schon deprecated Felder habe, überlege ich ob es nicht besser ist, an den
Das scheint über die Klasse
Ich finde die aktuelle Lösung nicht schlecht: wenn man für einen Use Case negative Werte unterstützen muss, nimmt man diesen Constructor. Ansonsten den Default Constructor, der keine negativen Werte unterstützt. PP arbeitet meist nur mit positiven Eingaben.
Ist einem solchen Fall nicht
Zumindest unter macOS beobachte ich da keinen Unterschied. Auf welchem Betriebssystem bist Du denn unterwegs? Aber wenn das jetzt nicht total "hängt", dann sehe ich das nicht als ein Problem an.
Sowas hilft auf jeden Fall. Und nicht als Issue hier, sondern direkt im Forum. Da sind ja die Benutzer die inhaltlich was zu den Features sagen können. Lass uns in diesem PR erst mal die inhaltlichen Fragen diskutieren (siehe oben). Mir würde diese oder ähnliche Rechnungen für konkrete Depots schon helfen um sicherstellen dass ich keine Nischenrechnung in PP einbaue. |
Danke für das gute Feedback, auch ich komme erst jetzt dazu.
Ich sehe das Feature weniger als Prognose, mehr als Portfolio-Modellierung (womit kann ich in Zukunft ungefähr rechnen?) oder auch Risikoabschätzung (wie groß ist das Risiko, dass mein Portfolio die z.B. 4% Rendite nicht erreicht, die ich zur Erreichung meiner langfristigen Ziele brauche?). Ich verstehe aber, dass das ein bisschen vom eigentlichen Performance-Erfassungs-Thema weggeht, und wenn solche Themen eher nicht in den strategischen Fokus von PP passen, verstehe ich das vollkommen, da ich auch kein Fan von ausufernder Software bin. Andererseits ist PP für mich halt der logische Ort, wo ich die notwendigen Daten (Asset Allocation) alle vorliegen habe, und wo ich eben über mein gesamtes Portfolio nachdenke, nicht nur über die vergangenheitsbezogene Performance. Wie Du sagst, gibt PP hier ja keine Prognose ab, sondern der User denkt eben über die Ausrichtung seines Portfolios nach. (Wenn der User mit historischen Renditen rechnet, ist es in gewissem Sinne vielleicht nicht einmal eine besonders auf die Zukunft bezogene Aussage - die erwartete Rendite wäre für die Vergangenheit vergleichbar.)
Hm, da gibt es nicht "den" einen Blogeintrag:
Sicherlich sollte man grundsätzlich über jede Renditeerwartung im Zusammenhang mit einem erwarteten Risiko nachdenken. Allerdings halte ich es hier (zumindest im ersten Schritt) für besser, dieses Risiko eher „mitzudenken“ und nicht konkret auch noch in die Applikation einzugeben, denn:
Das die zwei Nachkommastellen im Endergebnis eine Präzision suggerieren, die es nicht gibt, da stimme ich zu. Das könnte man auf eine NKS verringern. Andererseits ist das nicht unbedingt so bei der Eingabe der Werte - wenn ich ein Tagesgeldkonto mit 0,55% Rendite oder eine Anleihe mit 3,95% Rendite habe, warum soll ich das nicht so eingeben können? Ich stelle die technischen Fragen mal zurück, um die grundsätzlichen Fragen zuerst zu besprechen, nur kurz hierzu:
Das Feld 'ERinUse' ändert sich (wird quasi aktiviert), wenn man einen echten Wert einträgt. Es wird deaktiviert, wenn man z.B. einer Assetklasse eine erwartete Rendite zuweist, denn dann werden in dieser Assetklasse evtl. enthaltene Einzeltitel für die Berechnung nicht mehr berücksichtigt (d.h. quasi deaktiviert). Diese Tatsache (ob aktiviert oder nicht) muss aber schon irgendwo dauerhaft abgespeichert werden.
Darin sehe ich kein Problem. Ich habe die properties kurz gesehen, ohne sie näher angeschaut zu haben - könntest Du nochmal kurz erklären, inwiefern deren Persistenz anders gehandhabt wird als die des eigentlichen Portfolios im XML-File? Falls wir uns alternativ entscheiden sollten, das Feature jetzt nicht aufzunehmen, wäre für mich auch interessant zu wissen, wie ich dieses Feature bei mir lokal (mit Datenhaltung) am besten nutzen könnte. Ich würde dann jedes Mal nach dem pullen einer neuen Version meine feature-branch da rein mergen, müsste aber irgendwie eine separate Datenhaltung haben. Könntest Du mir dazu evtl. eine Empfehlung geben?
Ok, alles klar.
Ich bin auch kein Fan davon, Software mit Features zu überfrachten, die zu speziell sind. |
Idea: additional calculation code and new columns can be put together into one class instead of adding code here and there to the existing (already complex) classes Issue: #1231
|
Hi @doncristobal, Ich habe zwei Änderungen gemacht mit denen Dein Feature - leicht anders implementiert - reinnehmen kann:
Ich habe Deinen Code jetzt noch nicht angepasst. Ich denke es sollte aber - trotz einiger Änderungen - relativ einfach sein. Dann ein neues AttachedModel im TaxonomyModel hinzufügen: this.attachedModels.add(new ExpectedReturnsAttachedModel());Dann den Code in einer separaten Klasse. Irgendwas wie das hier: public class ExpectedReturnsAttachedModel implements TaxonomyModel.AttachedModel
{
public static final String KEY_EXPECTED_RETURN = "expected-return"; //$NON-NLS-1$
private Map<TaxonomyNode, Boolean> isERinUse = new HashMap<>();
@Override
public void setup(TaxonomyModel model)
{
}
@Override
public void addColumns(ShowHideColumnHelper columns)
{
}
@Override
public void recalculate(TaxonomyModel model)
{
// Recalculate full expected returns tree
calcFullERTree(model.getVirtualRootNode());
}
private int getExpectedReturnFor(TaxonomyNode node)
{
Integer expectedReturn = (Integer) node.getData(KEY_EXPECTED_RETURN);
return expectedReturn == null ? 0 : expectedReturn.intValue();
}
private void setExpectedReturnFor(TaxonomyNode node, int expectedReturn)
{
node.setData(KEY_EXPECTED_RETURN, Integer.valueOf(expectedReturn));
}
private void calcFullERTree(TaxonomyNode virtualRootNode)
{
// ...
}
} |
|
@doncristobal Wie kommst Du voran Deinen Code auf die Änderungen anzupassen? Ich kann das ebenfalls mal probieren - ich denke es sollte relativ einfach sein die Berechnungslogik und die Spalten in die neue Klasse zu übernehmen. |
|
Bin wegen Zeitmangels praktisch kaum vorangekommen. Ich hatte die Hoffnung, mich morgen nachmittag mit der Umsetzung zu beschäftigen. Wenn Du vorher Zeit hast, sehr gerne :-) Den vorgeschlagenen Weg zur Integration finde ich sehr gut, vielen Dank! |
|
Ok, bin mit der Umstellung an sich gut vorangekommen, allerdings geht der ValueEditingSupport bisher (bisher: |
Ja. Anfangs dachte ich es ist doch cool per Reflection viele Properties abdecken zu können. Das tut aber natürlich nur wenn nur wenn das wirklich Java Properties sind. Im Prinzip musst Du jetzt von ColumnEditingSupport. Und die #setValue setzt den Wert in die Map. In AttributeEditingSupport mache ich das ähnlich. Die Klassen kannst Du auch als inner static class in Deiner Erweiterung definieren wenn Du möchtest. Wichtig ist aber die gleicher Konvertierungslogik wie beim ValueEditingSupport zu haben damit sich das für den Benutzer gleich verhält - Du kannst dafür die StringToCurrencyConverter und CurrencyToStringConverter verwenden. Du kannst auch Deinen aktuellen Change per force push noch mal in diesen Branch pushen (oder einen neuen PR aufmachen) und kann mir die Änderung anschauen und ggf. den Code anpassen. |
|
Ok, das sieht soweit gut aus. Allerdings scheint es mir so zu sein, dass im vorgeschlagenen Modell das Boolean ERinUse nicht persistiert wird. Spricht etwas dagegen, dass ich in der HashMap in der TaxonomyNode statt des expected returns eine Liste mit sowohl expected return als auch des Booleans speichere (oder ggfs. auch unter separaten Keys)? EDIT: ich implementiere das jetzt mal so, kommt heute oder morgen. |
…previously merging with master)
|
@buchen Sorry, der commit lief nicht wie geplant und hat jede Menge veraltete Changes mitgeschickt. Ich hätte wohl doch besser den Weg über einen neuen pull request gehen sollen, will aber jetzt lieber nicht versuchen, den commit wieder zu löschen. Der relevante Code ist jedenfalls in ExpectedReturnsAttachedModel.java, alle restlichen Änderungen sind irrelevant und können gelöscht werden. |
Beides ist sicherlich möglich: als separate Keys als auch als ein kombinierter Key. Ich würde eher zwei Keys verwenden. Dann hat man eine "flache" HashMap. Ich hatte gedacht, dass
Ich schaue das ich mir den da per cherry-pick raushole. Dauert aber ein paar Tage. |
Feature: in asset allocation view, assign estimates of expected returns to asset classes and securities; overall portfolio return (weighted average) is calculated and displayed Issue: #1231
|
Ist drin: c5bf9f1 Schaue mal ob das Deinen Erwartungen entspricht. Ich habe hier da ein paar Änderungen vorgenommen, aber an dem Algorithmus eigentlich nichts verändert. |
|
Sieht gut aus, vielen Dank! Das folgende ist mir noch aufgefallen:
ERinUse ist in dem Sinne keine berechnete Property, der Zustand kann nicht abgeleitet werden aus den anderen Werten. Es ist letztlich davon abhängig, welche Werte der User editiert hat und auf welcher Ebene er seine erwarteten Renditen eingeben möchte. Daher muss es abgespeichert werden. |
Das habe ich dann beim Durchgehen auch gemerkt.
Nehme ich raus. Bei weiteren Änderungen: einfach einen neuen Branch auf den Master aufmachen, die Änderungen vornehmen und einen PR stellen.
Ja, habe ich rausgenommen. Wenn, dann muss man den Bold font noch Cachen. Da kein #dispose aufgerufen wurde, wäre der Speicher voll gelaufen. Und ich dachte wenn eines von den Feldern fett ist, dann sieht das so komisch aus. Aber ich merge auch gerne einen PR dazu. |
Idea: additional calculation code and new columns can be put together into one class instead of adding code here and there to the existing (already complex) classes Issue: portfolio-performance#1231
Feature: in asset allocation view, assign estimates of expected returns to asset classes and securities; overall portfolio return (weighted average) is calculated and displayed Issue: portfolio-performance#1231
Hi, anbei ein (Vorschlag für ein) neues Feature zur Schätzung der erwarteten Rendite des Gesamtportfolios.
Man kann dazu auf der Seite 'Asset Allocation' für einzelne Assetklassen und/oder Wertpapiere Schätzungen einer Rendite eingeben. Daraus wird dann als gewichteter Durchschnitt die erwartete Rendite des Gesamtportfolios errechnet und in der Zeile "Asset Allocation" angezeigt.
Motivation/Zweck: Ermöglicht eine Einschätzung, welche Rendite das Portfolio langfristig erwirtschaften könnte, und welche Assetklassen welchen Beitrag dazu leisten.
Bedienung:
Als mögliche Datenquellen für die Schätzung von Renditen bieten sich an:
Nur zur Klarstellung: es wird einfach ein gewichteter Durchschnitt der erwarteten Renditen berechnet. Weitere Effekte durch Diversifikation oder Rebalancing werden dabei erstmal nicht berücksichtigt.
Ein paar technische Fragen, die ich noch habe:
Ich hoffe, das passt einigermassen (mein Java könnte stellenweise etwas rostig sein - letztes Projekt ist 10 Jahre her ;-). Ich würde eine neues Feature-Idee vielleicht nächstes Mal besser in einem früheren Stadium vorstellen (vielleicht dann als Issue?).
Und zum Abschluss bei der Gelegenheit auch nochmal vielen Dank an Andreas und die anderen contributors für das tolle Programm :-)