Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Erwartete Renditen / Expected returns #1231

Closed
wants to merge 3 commits into from

Conversation

@doncristobal
Copy link

doncristobal commented Sep 18, 2019

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.

image

Motivation/Zweck: Ermöglicht eine Einschätzung, welche Rendite das Portfolio langfristig erwirtschaften könnte, und welche Assetklassen welchen Beitrag dazu leisten.

Bedienung:

  • Auf Seite 'Asset Allocation' gehen, oben rechts mit dem Zahnrad die Spalte 'Erwartete Rendite' hinzufügen.
  • Nun kann man (mittels Doppelklick) für eine gewünschte Assetklasse oder ein Wertpapier eine Renditeschätzung eingeben (die Zahl muss ohne Prozentzeichen eingegeben werden, also z.B. 1,5 für 1,5%).
  • In der obersten Zeile 'Asset Allocation' wird dann die errechnete Gesamtrendite ausgegeben, je nach Aufteilung der aktuellen Asset Allocation.
  • Die ausgegrauten Zeilen fließen nicht in die Berechnung ein. Die Idee dahinter ist, wenn man z.B. für eine gesamte Assetklasse wie 'Aktien Westeuropa' eine Renditeschätzung vergibt, macht es keinen Sinn mehr, die in der Assetklasse befindlichen Wertpapiere einzeln zu schätzen, deswegen werden diese in diesem Moment ausgegraut. Möchte man aber doch Renditen auf Ebene der einzelnen Wertpapiere schätzen, klickt man einfach in das entsprechende Feld hinter dem Wertpapier und modifiziert die Renditeschätzung dort, dieses wird dann nach dem Modifizieren dann automatisch aktiviert und fließt (gemeinsam mit den anderen Wertpapieren dieser Assetklasse) in die Gesamtschätzung ein. So kann man entscheiden, mit welcher Granulierung man die Schätzungen vergeben möchte.

Als mögliche Datenquellen für die Schätzung von Renditen bieten sich an:

  • Historische Renditen der Anlageklassen, wie man sie in Büchern über Asset Allocation (z.B. Kommer, Ferri, ...) findet. Ein Beispiel für den US-Markt: siehe unten.
  • Bei Anleihen-ETFs: die Endfälligkeitsrendite minus Kosten, bei Einzelanleihen: die Endfälligkeitsrendite
  • Große Investmenthäuser veröffentlichen Schätzungen für das jeweils aktuelle Jahr, berechnet aufgrund aktueller Marktparameter wie Dividendenrendite, KGVs usw. Für ein Beispiel von AQR s.u. (Achtung, es handelt sich um reale Werte (nach Abzug der Inflation), daher sollte man 1,5-2,0% dazurechnen, wenn man mit nominalen Werten (vor Abzug der Inflation) rechnen will.)
  • Festgeld/Tagesgeld: natürlich einfach die Rendite des Fest-/Tagesgeldes
  • Eigene Schätzungen

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.

image
image

Ein paar technische Fragen, die ich noch habe:

  • Tooltip: ich habe Tooltips vergeben, um die UI einfacher verständlich zu machen. Allerdings stört mich an den Tooltips, dass sie (z.B. beim Editieren, aber auch sonst) oft das Feld überdecken und es dadurch schlecht lesbar machen. Gibt es eine Möglichkeit, die Position der Tooltips so zu kontrollieren, dass sie woanders angezeigt werden? Falls nicht, würde ich sie fast eher rausnehmen wollen.
  • Man kann auch negative erwartete Renditen eingeben, so haben z.B. die Anleihen-ETFs im Kommer-Beispiel-Depot alle negative erwartete Renditen (wenn man die Endfälligkeitsrenditen als Maßstab nimmt). Das Feature (Eingabe negativer Werte) ist noch etwas 'experimentell' gecoded, da ich etwas tiefer in andere Codeteile eingreifen hätte müssen, was ich jetzt nicht ohne Rücksprache machen wollte. Siehe z.B. den alternativen Constructor (Zeile 30) in StringToCurrency.java. Soll ich das in dieser Richtung ändern? (ist in einem separaten Commit)
  • Kann man den onModified()-event eines Feldes auch mitbekommen, wenn das Feld zwar editiert wurde, der eigentliche Wert aber nicht geändert wurde? Das ist in einer bestimmten Situation relevant.
  • Das Aufklappen der Tree-Elemente scheint mir etwas langsamer als vorher vonstatten zu gehen (kann man sehen, indem man die Zeile 'Erwartete Rendite' ein- oder ausblendet und es dann probiert). Ich nehme an, das liegt an der Verwendung des StyledCellLabelProvider in AbstractNodeTreeViewer. Ist die Performance unproblematisch?

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 :-)

Chris Reimold added 2 commits Sep 15, 2019
…of expected returns to asset classes and securities; overall portfolio return (weighted average) is calculated and displayed
@buchen buchen added the enhancement label Sep 19, 2019
@buchen

This comment has been minimized.

Copy link
Owner

buchen commented Sep 28, 2019

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 ERinUse ein berechnetes Boolean Feld, oder? Es ändert sich je nachdem ob und wo echte Werte eingetragen werden. Darum gehört es für mich nicht in die Persistenz (Classification und Assignment werden in die XML Datei geschrieben).

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 Client für jede Taxonomy eine Map mit node --> {expectedReturn, ERinUse} zu hängen. Das gibt es momentan schon eine Map<String, String> properties die ich aber aufbohren könnte.

Tooltip [...] Gibt es eine Möglichkeit, die Position der Tooltips so zu kontrollieren, dass sie woanders angezeigt werden?

Das scheint über die Klasse ColumnViewerToolTipSupport von Eclipse gesteuert zu werden. Anscheinend kann man am LabelProvider die Methode getToolTipShift überschreiben um die Platzierung zu ändern.

Das Feature (Eingabe negativer Werte) [...] alternativen Constructor (Zeile 30) in StringToCurrency.java.

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.

Kann man den onModified()-event eines Feldes auch mitbekommen, wenn das Feld zwar editiert wurde, der eigentliche Wert aber nicht geändert wurde?

Ist einem solchen Fall nicht newValue identisch zu oldValue?

Das Aufklappen der Tree-Elemente scheint mir etwas langsamer als vorher vonstatten zu gehen

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.

Ich würde eine neues Feature-Idee vielleicht nächstes Mal besser in einem früheren Stadium vorstellen (vielleicht dann als Issue?).

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.

@doncristobal

This comment has been minimized.

Copy link
Author

doncristobal commented Oct 9, 2019

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.

Danke für das gute Feedback, auch ich komme erst jetzt dazu.

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 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.)

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?

Hm, da gibt es nicht "den" einen Blogeintrag:

  • Ich habe eine solche langfristige erwartbare Rendite (auf Assetklassen-Ebene) zuerst bei einem professionellen Verwalter gesehen und fand es relativ hilfreich. (Dass das nach einiger Zeit nicht mehr gezeigt wurde - wegen Unterperformance - ist ein anderes Thema. :) Also in der Praxis genutzt wird das insofern sehr wohl. (Die hier vorgestellte Variante hat den Vorteil, dass man frei ist, Assetklassen oder Einzeltiteln erwartete Renditen zuzuweisen.)
  • Hier z.B. ein Zitat aus Kommer, 5. Aufl., S. 29, wo er das zugrundeliegende Konzept im Rahmen der modernen Portfolio-Theorie bespricht:
    image
    image
  • In der Praxis denken User glaube ich z.B. in Foren regelmäßig darüber nach, was ihr Portfolio erwirtschaften könnte - als aktuelles Beispiel gerade gesehen z.B. hier
  • Wie gewünscht noch ein paar Artikel über verschiedene Aspekte: hier, hier, hier, hier
  • Letztlich kann man dies schlicht als die Berechnung der erwarteten Portfolio-Rendite im Rahmen der Portfoliooptimierung à la Markowitz ansehen, s. z.B. https://en.wikipedia.org/wiki/Modern_portfolio_theory und dort unter „Expected Return“. In diesem Sinne wird dieses Konzept in Studien etc. natürlich 1.000-fach genutzt und in jedem Asset-Allocation-Buch implizit benutzt - jeder Punkt auf der efficient frontier ist eine erwarte Rendite / Risiko-Kombination, wobei die Rendite üblicherweise geschätzt sein wird auf Basis historischer Renditen.

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?

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:

  1. Ich glaube, es würde das ganze erstmal zu komplex machen. Klar, man könnte zu jeder erwarteten Rendite noch eine historische annualisierte Volatilität oder (vielleicht einfacher:) einen maximum drawdown angeben. Aber die Daten muss man sich erstmal zusammensuchen, speziell wenn man auch Einzeltitel betrachtet.
  2. Man kommt dann in andere, komplexere Themenbereiche rein - wenn man alle Assetklassen mit erwarteter Rendite und Volatilität modelliert, kommt man praktisch in den Bereich der Markowitzschen Portfoliooptimierung, und braucht vermutlich auch noch Korrelationen/Kovarianzen. Das ginge an der Stelle jetzt glaube ich wirklich etwas zu weit (abgesehen davon, dass die praktische Einsetzbarkeit davon mindestens umstritten ist).
  3. Vereinfachend könnte man wohl auch sagen, dass das erwartete Risiko in irgendeiner Form (außer in Sondersituationen) grob proportional zur erwarteten Rendite sein wird, und der tatsächliche Erkenntniszuwachs daher begrenzt sein wird. (Zumindest wenn man nicht auch noch die Korrelation zwischen den Assetklassen modelliert.)

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:

Wenn ich das richtig sehe, ist das Feld ERinUse ein berechnetes Boolean Feld, oder? Es ändert sich je nachdem ob und wo echte Werte eingetragen werden. Darum gehört es für mich nicht in die Persistenz (Classification und Assignment werden in die XML Datei geschrieben).

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.

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 Client für jede Taxonomy eine Map mit node --> {expectedReturn, ERinUse} zu hängen. Das gibt es momentan schon eine Map<String, String> properties die ich aber aufbohren könnte.

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?

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.

Ok, alles klar.

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.

Ich bin auch kein Fan davon, Software mit Features zu überfrachten, die zu speziell sind.
Falls gewünscht, kann ich auch im Forum fragen, ob es noch andere User gibt, die dieses Feature einsetzen würden.

buchen added a commit that referenced this pull request Oct 20, 2019
Issue: #1231
buchen added a commit that referenced this pull request Oct 20, 2019
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
@buchen

This comment has been minimized.

Copy link
Owner

buchen commented Oct 20, 2019

Hi @doncristobal,

Ich habe zwei Änderungen gemacht mit denen Dein Feature - leicht anders implementiert - reinnehmen kann:

  • Erstens habe ich eine Map<String,Object> an Classification und Assignment rangehängt: c109aaf Damit kann man dann beliebige weitere Attribute speichern - also auch den expected Return.
  • Zweitens habe ich "AttachedModel" geschaffen mit dem man - hoffentlich - relativ einfach die ganze neue Funktionalität an einer Stelle implementieren können sollte: 01b24b4 Das gilt sowohl für die Berechnung, als auch für die Spalten.

public interface AttachedModel
{
default void setup(TaxonomyModel model)
{
}
void recalculate(TaxonomyModel model);
default void addColumns(ShowHideColumnHelper columns)
{
}
}

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)
    {
        // ...
    }

}
@buchen buchen added this to Under Consideration in Backlog Oct 20, 2019
@buchen

This comment has been minimized.

Copy link
Owner

buchen commented Nov 2, 2019

@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.

@doncristobal

This comment has been minimized.

Copy link
Author

doncristobal commented Nov 2, 2019

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!

@doncristobal

This comment has been minimized.

Copy link
Author

doncristobal commented Nov 3, 2019

Ok, bin mit der Umstellung an sich gut vorangekommen, allerdings geht der ValueEditingSupport bisher (bisher: ValueEditingSupport vesER = new ValueEditingSupport(TaxonomyNode.class, "expectedReturn", Values.Percent_ER)) davon aus, dass er eine property einer Klasse anzeigen soll, während er nun im neuen Modell auf einen bestimmten Key in der HashMap data zugreifen müsste. (Ich bin jetzt gerade auch nicht sicher, ob es immer die gleiche Klasse ist.). Ich habe mir die entsprechenden Konstruktoren kurz angeschaut, ob man die nicht entsprechend anpassen könnte, bin aber nicht sicher, was da der beste Weg ist.

@buchen

This comment has been minimized.

Copy link
Owner

buchen commented Nov 9, 2019

allerdings geht der ValueEditingSupport bisher [...] davon aus, dass er eine property einer Klasse anzeigen soll, während er nun im neuen Modell auf einen bestimmten Key in der HashMap data zugreifen müsste.

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.

@buchen buchen moved this from Under Consideration to Ready for Review in Backlog Nov 9, 2019
@doncristobal

This comment has been minimized.

Copy link
Author

doncristobal commented Nov 10, 2019

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.

@doncristobal

This comment has been minimized.

Copy link
Author

doncristobal commented Nov 12, 2019

@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.

@buchen

This comment has been minimized.

Copy link
Owner

buchen commented Nov 12, 2019

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)?

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 ERinUse ein berechnetes Property ist, d.h. es kann vom vom Benutzer nicht editiert werden und der Zustand kann immer wieder korrekt berechnet werden. Darum hatte ich es nicht zu den persistierten Properties genommen. Denn je kleiner das XML, desto schneller kann man es laden. Und vielleicht ändert sich mal der Algorithmus, dann hat man nur Benutzereingaben

Der relevante Code ist jedenfalls in ExpectedReturnsAttachedModel.java, alle restlichen Änderungen sind irrelevant und können gelöscht werden.

Ich schaue das ich mir den da per cherry-pick raushole. Dauert aber ein paar Tage.

buchen added a commit that referenced this pull request Nov 14, 2019
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
@buchen

This comment has been minimized.

Copy link
Owner

buchen commented Nov 14, 2019

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.

@buchen buchen closed this Nov 14, 2019
@doncristobal

This comment has been minimized.

Copy link
Author

doncristobal commented Nov 15, 2019

Sieht gut aus, vielen Dank! Das folgende ist mir noch aufgefallen:

  • recalculate() in Zeile 71 von ExpectedReturnsAttachedModel kann gelöscht werden, da es das gleiche macht wie Zeile 69 (war ein Fehler in meinem ursprünglichen Code)
  • Ich nehme an, dass das Endergebnis in der Root-Zeile bold dargestellt wird, hast Du bewusst rausgenommen, oder? Ist ok für mich, wollte nur sichergehen, dass das so geplant war.

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.

buchen added a commit that referenced this pull request Nov 15, 2019
Issue: #1231
@buchen

This comment has been minimized.

Copy link
Owner

buchen commented Nov 15, 2019

ERinUse ist in dem Sinne keine berechnete Property, der Zustand kann nicht abgeleitet werden aus den anderen Werten.

Das habe ich dann beim Durchgehen auch gemerkt.

recalculate() in Zeile 71 von ExpectedReturnsAttachedModel kann gelöscht werden

Nehme ich raus. Bei weiteren Änderungen: einfach einen neuen Branch auf den Master aufmachen, die Änderungen vornehmen und einen PR stellen.

Ich nehme an, dass das Endergebnis in der Root-Zeile bold dargestellt wird, hast Du bewusst rausgenommen, oder?

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.

@buchen buchen moved this from Ready for Review to Done in Backlog Nov 23, 2019
@buchen buchen removed this from Done in Backlog Nov 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.