PeWi
-
Gesamte Inhalte
3.060 -
Benutzer seit
-
Letzter Besuch
Inhaltstyp
Profile
Forum
Blogs
Shop
Kalender
Downloads
Galerie
Alle Inhalte von PeWi
-
Das klappt natürlich nicht - als das zu versteuernde "Einkommen" zählt das Gesamteinkommen, also die Summe aus allen, was du verdient hast - hier also Arbeitseinkommen und Kryptoverkäufe. In deinem Beispiel hast du somit 9.167+100.000 = 109.167€ als Einkommen zu versteuern.
-
Einen vernünftigen Source zu statistischer Arbitrage suche ich noch. Ich habe einen einzigen in R, aber den verstehe ich nicht. 🙄 Meistens findet man unter dem Stichwort "statistische Arbitrage" leider nur Artikel, die sich nach ein paar warmen Worten letztendlich doch nur auf Pair Trading beschränken. Statistische Arbitrage ist doch die Verallgemeinerung von Pair Trading, bei der man statt nur zwei Coins (Aktien, ... whatever) einen Korb aus mehreren Elementen hat. Aber drüber hinaus - wann kauft/verkauft man was in welchem Unfang - habe ich zuwenig Details gefunden, um das richtig nachvollziehen zu können.
-
Da habe ich wohl zu knapp und missverständlich formuliert. Ich wäre durchaus bereit, bei einem Gemeinschaftsprojekt mitzumachen und mit etwas Wissen dazu beizutragen. Ich mag nur den Geheimniskrämer-Ansatz "hinter verschlossenen Türen" nicht; und er ist auch unnötig, denn es wird dabei in überschaubaren Zeiträumen sowieso kein "extrem guter Bot" dabei rauskommen. Das ist die - sorry - naive Hoffnung anfangs, die schminkt man sich im Lauf der Zeit ab und wird realistischer. Ansonsten säßen viel mehr der hiesigen Mitglieder permanent in der Südsee ... 😜 Am Anfang muss man kleinere Brötchen backen, und die kann man durchaus der Gemeinschaft hier zur Verfügung stellen. Auch dabei lernt man.
-
Ich halte nicht so viel davon, sich zu verzetteln. Was im Coinforum seinen Anfang nimmt, darf auch gerne dort seinen weiteren Fortgang nehmen. Ich würde mich freuen, wenn aus diesem Thread irgendwann mal ein kleiner Workshop - ähnlich dem von @Jokins BalanceBot - entspränge. Außerdem - Achtung: subjekte Meinung - gefällt mir Discord nicht, weder vom Handling, noch vom Aussehen. 😜
-
Heißt aber, dass man das alle paar Stunden manuell anpassen müsste? (Vor allem in der Nacht schwierig.)
-
Das Fazit aus deinem verlinkten Artikel ist allerdings: "The trading strategy based on the Zero Lag Moving Average does not perform significantly better than the strategy based on the Hull Moving Average or some other alternatives." Was mir noch nicht richtig klar ist - wenn der Lagless MA schneller reagiert - fällt der dann nicht auch häufiger auf Fake-Ausbrüche rein? Wie sieht es mit adaptiven MAs aus? Von der Idee her erscheinen die mir auch recht einleuchtend. Hat jemand Erfahrungen mit Frama/Kama/... ? (P.S.: Der Frama ist ja auch von Ehlers.)
-
Idealerweise solltest du selber ein bisschen programmieren können, um verstehen zu können, was und warum der Open Source Bot tut. Das würde die Auswahl auf Sprachen, die du zumindest etwas kannst, einschränken. Ist auch deswegen sinnvoll, weil viele Open Source Bots dir das ganze Rahmenwerk bieten, aber du die gewünschte Strategie in Teilen oder ganz selber schreiben musst.
-
Unter den adaptiven Elementen meiner aktuellen Bot-Strategie ist auch die Positionsgröße. Hat also keinen Sinn. Welchen Sinn hat es, den Bot auf zwei Hälften aufzuteilen, nur damit die Long- bzw Short-Seite auch in ungeeigneten Zeiten traden darf, damit ich im Anschluss das ganze durch Equity Trading wieder einfange? Von hinten durch die Brust ins Auge? Im Endeffekt habe ich in der Strategie bereits den Filter, wann Long und wann Short sinnvoll ist. Da bringt es wenig, sowas ähnliches nochmal oben drüber machen zu wollen.
-
So hätte ich das auch beschrieben. Da liegt also der von dir bei mir vermutete Fehler nicht. Ich vermute eher, dass unsere Differenzen da liegen - am Unterschied zwischen Theorie und Praxis. 😉 Damit das ganze so schön funktioniert wie beschrieben, muss eine Statistik möglich sein, sprich, es müssen genügend Trades pro Marktsituation stattfinden. Andernfalls bekomme ich keine saubere Aussage, weil die Einzelereignisse zu viel Einfluss haben. Außerdem laggt die Aussage "profitabel oder nicht" zwangsweise etwas. Wenn die Phasen "profitabel" bzw "nicht profitabel" lange genug sind, dann stört das nicht weiter. Wechselt das aber relativ schnell (im Vergleich zu den Tradelängen), dann wird die Positionsgröße zu immer größeren Teilen verkehrt gesetzt sein. Und genau das vermute ich bei meinem Go-Bot. Seine Strategie hat zusätzlich zum Shorten von Haus aus einige adaptive Elemente, weswegen die Phasen schneller wechseln.
-
Das erklärt, warum sich bei mir durch Tharp nicht viel geändert hat - ich war schon immer eher etwas risikoscheu. 😉 Ich hab' ein paar seiner Position Sizing-Möglichkeiten in Backtests ausprobiert, und es kam - leider - kaum was anderes dabei raus. Das Equity Modelling, das ich in vereinfachter Form nachträglich in meinen Python-Bot für Binance eingebaut habe, hat tatsächlich merkliche Verbesserungen gebracht, weil der nur long-only kann und dadurch in längeren Bärenphasen jetzt weniger verliert. Mein Go-Bot, der auf Kraken long und short geht, profitiert laut Backtests leider nicht merklich davon.
-
Neugierdehalber: Hattest du vorher zu große Trades riskiert? Oder warum andernfalls?
-
Nachtrag zu dem oben erwähnten "Jesse": Wie so oft erlebt ist der Backtest sehr simpel gestrickt - ein einmaliger Durchlauf der aktuellen Strategie über einen fixen Zeitraum. Und leider erschreckend langsam: Ca. 6000 Candles auf ein einziges Paar dauern laut einem Beispiel in der Doku 108 Sekunden! (Trotz ausführlicher Hinweise, alles über Numpy Arrays und möglichst Vektormethoden abzuwickeln.) Das ist der Preis für ein mächtiges Konzept auf Eventbasis in Python ... in Go wäre mindestens ein Faktor 10 drin. https://docs.jesse.trade/docs/backtest.html Jesse bringt ein nettes Optimierungsmodul mit, das über evolutionäre Algorithmen gute Parameter sucht. Leider steht in der Doku zu wenig, als dass ich die Qualität dieser Optimierung halbwegs einschätzen könnte (*). (Nachtrag: Erscheint sinnvoll.) Kritikwürdig ist jedenfalls, dass Jesse lediglich über einen einzigen Zeitraum arbeitet. Erwartungsgemäß explodiert die Laufzeit: Ca. 40h. (*: Im Source kann man finden, dass die Fitnessfunktion im wesentlichen das ... Ratio (wählbar: Sharpe/Sortino/Calmar/Omega) ist mit einem kleinen Korrekturfaktor, was die Zahl der Trades betrifft. ) Aber das ist jetzt Meckern auf hohem Niveau - Backtest ist halt eines meiner Steckenpferde - ansonsten gefällt mir Jesse sehr gut. Kleiner Wermutstropfen: Das Live-Trading-Modul ist noch nicht ganz fertig, soll aber schon weitgehend fertig sein und bald kommen. Momentan ist man also noch auf Backtests begrenzt.
-
Sehr cool! Größten Respekt! 👍 Edit: War da nicht vor ein paar Monaten was, das jemand auf diese Art in einer raffinierten Transaktion fast 30 Millionen Dollar verdient hat? Gefunden: https://bitcoinblog.de/2020/04/20/zwei-smart-contracts-wirken-zusammen-und-produzieren-eine-schwaeche-durch-die-ein-angreifer-rund-26-millionen-dollar-erbeutet/
-
Gerade als Ein-Mann-Betrieb ist das extrem aufwendig und frisst wahnsinnig Zeit. Das kann ich nur unterschreiben. Ich verwende bei meinem jetzigen Go-Bot u.a. eine Library, die noch nie funktioniert haben kann (Go-Bindings für die Tulip-Indikator-Library). Davon gibt es auch etliche Forks, aber in keiner war dieser - wirklich auffällige - Fehler (*) behoben. Eine andere Lib, gegen die ich mich dann entschieden habe, hat für Tages-, Stunden- und Minutencandles jeweils eigene Funktionen gehabt, obwohl unter der Haube alles gleich ist bis auf die gegen die Börse aufzurufende URL. Warum tut er das? Das ist doch völlig unpraktisch zu nutzen?? Da kommt man wirklich zu dem Schluss, dass der jeweilige Entwickler die Lib nur zur Aufhübschung seines Werdegangs geschrieben und auf Github publiziert hat, aber nie ernsthaft verwendet hat. Insofern kann ich dich gut verstehen, wenn du selber bereits etwas hast, was läuft, was wirklich getestet ist und sich bewährt hat, dass du dann lieber dabei bleibst, selbst wenn es "Gefrickel" ist, als dich dem Risiko auszusetzen, wieder alles durchgehen zu müssen und einen neuen Source durchzugehen, zu verstehen und an zig Stellen aufgrund deiner Erfahrungen zu härten. (*: Bei jedem Indikator, der <n> Eingangswerte braucht, bis er den ersten Ausgangswert produziert, waren die aktuellsten <n-1> Werte Null, also bei jedem SMA, EMA, ... das muss doch auffallen. Okay, der Fehler war wirklich ätzend zu finden, weil der im Pointer-Rumgefrickel der Bridge zwischen C und Go war - aber zumindest der Original-Autor der Bindings ...?)
-
Bezüglich Verletzungen von Best Practises hättest du bei mir viel zu meckern. 🤔 Zu meiner professionellen Zeit "gab" es viele heutzutage üblichen Best Practises noch nicht bzw bei meiner Firma nicht. Seitdem bin ich nur noch Hobby-Entwickler in meinem stillen Kämmerchen und habe von den Weiterentwicklungen in der Welt da draussen auch wenig mitbekommen. Heutzutage und bei Go sowieso ist es üblich, Funktionstests zu schreiben. Das konnte ich mir bis heute noch nicht angewöhnen.
-
Ausführlich. Rauf und runter. 😜 Ernsthaft: Backtests sind mir wichtig. Nicht, weil ich mir einbilde, damit im Live-Betrieb supertolle Ergebnisse zu bekommen, sondern um das Gegenteil zu vermeiden - schlechte Kandidaten (d.h. Parameterkombinationen) zu erwischen. Mein Backtest trifft einige Maßnahmen, um Overfitting zu vermeiden. Mit den angebotenen Backtests bei diversen Open Source Bots war ich meistens unzufrieden, weil die im Normalfall einfach die Strategie mit deinen ausgewählten Parametern einmal durchlaufen lassen und ausgeben, was in diesem einen Fall rausgekommen wäre. Da man Orderbücher nicht (bzw nur kommerziell und teuer) bekommt, bliebe nur, die selber über Monate mitzuspeichern. Das ist schon arg aufwendig und mühsam. Nichtsdestotrotz würde mich Market Making ziemlich interessieren, mir fehlt bloss der richtige Anstupser, das endlich mal auszuprobieren. Ich stelle mir vor, dass man dabei gute Sicherungsmechanismen wegen der häufigen und großen Preisbewegungen bei Kryptos braucht?
-
Bin gerade dabei, diese nette Liste durchzugehen. 👍 Z.B. "Jesse" klingt interessant. Wirbt damit, einfach nutzbar zu sein, trotzdem sehr akkurat und viele Möglichkeiten zu haben (Multi-Timeframe, Multi-Pairs, multiple Entries und Exits etc). Stöbere gerade die Doku durch, gefällt mir bisher ganz gut. Enthält laut Angabe auch genetische Algorithmen zur Optimierung der Strategieparameter; soweit bin ich in der Doku aber noch nicht. https://awesomeopensource.com/project/jesse-ai/jesse
-
👍 Das beschreibt sehr schön mein Dilemma. Obwohl ich gut rechnen und planen kann, bin ich zu vorsichtig und traue mich immer erst ein halbes Jahr später das, was ich gleich hätte machen sollen - mit den entsprechenden Opportunitätskosten.
-
👍 Und keine Angst, ich kann das auch nur so hobbymäßig, @skunkals Profi wird bei mir vermutlich auch immer mal wieder die Nase rümpfen. 😉 Dein Buch von 2016 und die Go-Version 1.15.x sind ok.
-
Also bei Java wird das zu 100% geprüft, außer zu schreibst z.B. nen int in nen String, aber das währe ja nicht schlimm. Ich vermute, dass @fjvbit eher "... die strenge Typprüfung von Java // C++ ..." gemeint hat. 😉
-
Hm, Web-Frontends kann ich leider nicht, aber eine Anzeige und Steuerung über Telegram erfüllt für mich den gleichen Zweck.
-
Wenn man sich in Cython richtig reinkniet, dann kann man Python Code schreiben, der mit C-Geschwindigkeit und -Speicherverbrauch läuft. Ich hab's mal probiert, bin aber schon daran hängengeblieben, wie man eine Python-Liste in Cython konvertiert. Ich habe meinen ursprünglichen Python-Bot nach Go halb portiert und halb neugeschrieben, worauf der Backtest nur noch ein Achtel des Speichers gebraucht hat und mit zwanzigfacher Geschwindigkeit gelaufen ist. (Obwohl ich in Python meine "Massendaten" schon mit Numpy-Arrays gehalten habe.) 👍 Wie wäre es, wenn wir in diesem Thread einen einfachen Bot bauen, der sich auf das Aussteigen aus Altcoin-Trades automatisiert? Dann muss man nach dem Eingehen des Trades nicht mehr ängstlich am Bildschirm und am Kurs kleben und kann sogar entspannt schlafen gehen, selbst wenn der Trade noch läuft? 😜
-
Wie geschrieben positioniert sich Go als Backend-Sprache. Damit einher geht, dass es im Frontend-Bereich und anderen Nicht-Server-Ecken ein bisschen dünn aussieht. Auch für Maschinelles Lernen/KI hätte ich gerne die Breite wie bei Python. 😉 Nett dagegen ist, dass ein HTTP-Server und Drumherum-Geraffel in die Go-Basis-Libs eingebaut sind, womit du recht einfach REST-APIs oder Web-Anwendungen stricken können solltest. Aber Python ist zugegebenermaßen von Haus aus komfortabler zu benutzen. Aus einer Zeile Python werden gerne 5 Zeilen Go-Code, und die Go-typische Fehlerbehandlung zieht alles noch mehr in die Länge. Im Gegenzug ist es extrem angenehm, dass bereits der Compiler die Fehler entdeckt, die ich in Python erst zur Runtime bemerkt hätte. 😉
-
Oh ja, ich bin immer froh um eine IDE, die mir bei den Syntax-Details auf die Sprünge hilft. 😉
-
Das könnte die oben erwähnte ccxt (https://github.com/ccxt/ccxt, auch für JavaScript und PHP). Mein Java ist gut 20 Jahre her, insofern sorry. Das ist schon sehr speziell, da wird dir kaum einer folgen können ... Obwohl so ganz spezielle Fragen auch ihren Reiz haben: Da hätte mich eine Antwort auch interessiert, obwohl ich von der Bitcoin-"Technik" unter der Haube überhaupt keine Ahnung habe und die Antwort vermutlich überhaupt nicht verstanden hätte. 😉
