Interessensabfrage: Wer möchte selber einen Tradingbot erstellen?

[Jokin]

@Herr Coiner ... hast Du nochmal bei Dir geschaut wie's läuft und interessante Auswertungsideen?

Gegenüber dem 06.03. hab ich nun mal eben 8% Wertzuwachs im Portfolio. Das ist aber nicht weil der Balancebot so super rentabel arbeitet sondern das ist zum Großteil den Kurssteigerungen der gebalancten Coins geschuldet.

Aber wie genau bekommt man nun die Entwicklung der Kurse so rausgerechnet, dass man eine Performance des Bots errechnen könnte?

Ich hab hier mal einen kleinen Berechnungs-Ansatz gewagt:

Am 06.03. war NEO 8,73 USD wert und heute am 12.03. ist NEO 8,92 USD wert - das sind 2,2% Kurssteigerung.

Über die Portfoliogewichtung von 19% trägt diese Kurssteigerung mit 0,00414 zur gewichteten Wertsteigerung von 7,92% bei.
Gleichzeitig hat sich aber auch der Portfolio-Wert von 9,59 ETH auf 10,38 ETH gesteigert, was 8,24% ausmacht.

Wäre es nun legitim zu behaupten, dass die Kursschwankungen der vergangenen Woche zu einer Rendite von 8,24% - 7,92% = 0,32% führten?

... sollte das tatsächlich korrekt ermittelt sein, dann würde eine monatliche Rendite von 1% drin sein :-)

 

 

[PeWi]

3 hours ago, Jokin said:

Wäre es nun legitim zu behaupten, dass die Kursschwankungen der vergangenen Woche zu einer Rendite von 8,24% - 7,92% = 0,32% führten?

Sicherlich nicht.

Denn die 8.24% Wertsteigerung sind in der Einheit "ETH" gemessen, die 7,92% der Coins dagegen in "USD". Rechne also auch die ETHs in USD um, oder rechne alles in ETH.

[PeWi]

Meine Rechnung ist viel simpler - ohne Garantie auf formelle Richtigkeit.

Ohne Bot hättest du 9,59 ETH als ETH behalten, mit Bot hast du jetzt 10,38 ETH in Coins.
Folglich ist dein Gewinn 10,38 ETH * 134,72 USD/ETH  -  9,59 ETH * 138,81 USD/ETH = 67,21 USD (entspricht 5,05%).
(ETH-Preise von coinmarketcap um 12h des jeweiligen Tages.)

 

Bearbeitet 12. März 2019 von PeWi

[PeWi]

Um deinen Wertzuwachs oder -verlust für den Fall zu berechnen, dass du anfangs einmalig deine Coins gemäß deiner Gewichtung gekauft und stehen gelassen hättest, fehlen mir noch Zahlen. (Bei nochmaligen Lesen ist mir aufgefallen, dass eigentlich das dein angestrebtes Ziel war ... )

Entweder wieviel Prozent ETH du noch zusätzlich zu deinen ca. 100% Coins hattest, oder wieviel deine Coins in absoluten Zahlen waren, damit ich darüber den ETH-Anteil am Gesamtportfolio ausrechnen kann.

Bearbeitet 12. März 2019 von PeWi

[PeWi]

Nachtrag: In einem der früheren Beiträge hast du aufgelistet, dass zu den 100% Coins noch 25% ETH kommen. Damit ließ sich alles restliche berechnen.

So komme ich auf einen Gewinn von 5,85%, wenn du deine Coins nach deiner angegebene Gewichtung gekauft und liegengelassen hättest.
Mit dem Rebalancen durch den Bot kommst du auf 5,05% Gewinn (siehe Berechnung oben), also weniger.

Meine Tabelle ist leider kein Muster an Klarheit, ich hoffe, ihr kommt damit trotzdem klar - man kauft Coins nach der anfänglichen Gewichtung (alles mit 'anfangs'), bekommt damit eine Coinzahl ('gleichbleibend') und kann damit berechnen, was diese Coins beim Liegenlassen heute Mittag ('jetzt') wert gewesen wären.

 

Bearbeitet 12. März 2019 von PeWi

[Jokin]

vor 2 Stunden schrieb PeWi:

Denn die 8.24% Wertsteigerung sind in der Einheit "ETH" gemessen, die 7,92% der Coins dagegen in "USD". Rechne also auch die ETHs in USD um, oder rechne alles in ETH.

Richtig ... ich Depp 😞

Dann würde das aber bedeuten, dass der Bot mal eben 5% in einer Woche gemacht hat ... das halte ich für enorm unrealistisch.

 

vor 4 Minuten schrieb PeWi:

Unerfreulicherweise komme ich auf einen Gewinn von 5,85%, wenn du deine Coins nach deiner angegebene Gewichtung gekauft und liegengelassen hättest.
Mit dem Rebalancen durch den Bot kommst du auf 5,05% Gewinn (siehe Berechnung oben), also weniger.

Also dann:
Mit Bot: +5,05%
Ohne Bot (ETH-HODLer): -2,9%
Ohne Bot (6x COIN-Hodler + 25% bleiben in ETH): +5,85%

Von der Logik her könnte das nun hinkommen, denn der Bot balanciert schließlich aus, der wartet ja nicht bis ein Coin an seinem Maximum ist, sondern casht vorher schon immer einen kleinen Teil aus. Dieser kleine Teil reitet nicht mehr mit bis nach ganz oben.

 

[PeWi]

On 3/8/2019 at 9:09 AM, Jokin said:

und verflixt, das ist mal wieder Python. Es sieht so aus als käme ich da nicht drumrum 😞

Ein interessanter Artikel zu Python ...

https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13763980b5a1

[Jokin]

vor 6 Stunden schrieb PeWi:

Ein interessanter Artikel zu Python ...

https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13763980b5a1

Der gilt nahezu vollständig für fast jede andere Programmiersprache ebenso 🙂

Meine Bottlenecks sind große Datenbankstrukturen, da kommt es auf die Performance der Datenbank an und ich erlebe schon massive Unterschiede zwischen dem 1&1-MySQL-Cluster, meiner MySQL-DB auf dem VPS und der Maria-DB auf meinem Raspi.

Aber durch Optimierung hab ich das auch jeweils wieder hinbekommen - lazy is dann nich mehr ...

[Herr Coiner]

vor 19 Stunden schrieb Jokin:

@Herr Coiner ... hast Du nochmal bei Dir geschaut wie's läuft und interessante Auswertungsideen?

Ich schaue täglich mal auf die Grafik, sonst nichts. Am 24.02 habe ich Gewinn mitgenommen, gerade rechtzeitig bevor der ETH von über 140€ wieder ziemlich abgesackt ist.
Der Gesamtportfoliowert lag dann nur noch bei 0,73 ETH und stieg inzwischen auf 0,86 ETH jetzt (13.03. 8 Uhr). Das ist ein Zuwachs in ETH um 17,8 %, wenn ich richtig rechne.

Das kann sich doch sehen lassen Natürlich ist der ETH jetzt einiges weniger in EUR wert, aber das ist ja ne andere Sache.

[PeWi]

5 hours ago, Jokin said:

Der gilt nahezu vollständig für fast jede andere Programmiersprache ebenso

Er hebt ja darauf ab, dass Entwicklungszeit das teuerste sei, und dass laut der zitierten Studie die Entwicklung mit Python nachweisbar schneller geht (nur noch von Perl übertroffen).

Seine Grundthese, dass man Performance-Bottlenecks mit dickerer Hardware ausgleichen kann, stimmt sicherlich grundsätzlich.

Trotzdem gehe ich mit dem Autor nur teilweise konform.

Er denkt anscheinend hauptsächlich in normalen Anwendungen/Webanwendungen, in denen das wichtigste Geschwindigkeitskriterium die Reaktionszeit für den Benutzer ist, und bei denen man gut mittels Computerclustern parallelisieren kann (was DB und Weboberfläche betrifft).
Und das gilt vor allem im professionellen Umfeld, in dem sowohl für die Entwicklungszeit als auch für Hardware direkte Kosten anfallen.

Für "uns", soweit wir daheim in unserer Freizeit ebenfalls programmieren, gilt das aber nur eingeschränkt.

Wenn ich weniger lange zum Entwickeln brauche, habe ich deswegen nicht mehr Geld für Hardware, weil ich meine freien Stunden nicht einfach monetarisieren kann.

Zum anderen stoße ich bei meinem Bot durchaus an Geschwindigkeitsgrenzen aufgrund von Python, wenn viel zu verarbeiten oder zu berechnen ist.

Python unterstützt Parallelisierung nicht soooo gut;normales Multithreading läuft "dank" GIL nur auf einem einzigen Kern (hilft also nichts für Berechnungen), und richtiges Multiprocessing hat natürlich getrennte Adressräume, was die gegenseitige Kommunikation aufwendiger macht und zusätzlich Zeit kostet, wenn man einiges an Datenmengen zwischen den Prozessen hin- und herschaufeln muss.

Zusätzlich hat paralleles Arbeiten einiges an Haken und Ösen und ist schwieriger zu debuggen.

Die Komplexität steigt merklich, wenn ich in meinem Programm die Parallelität selber programmieren und verwalten muss, und nicht einfach "gekapselt" nutzen kann, in dem ich z.B. eine DB-Abfrage einfach an einen Cluster statt einer einzelnen Datenbank senden kann.

Fazit: Bei meinem eigenen Bot merke ich die Langsamkeit von Python schmerzlich, und ich kann sie nicht einfach durch dickere Hardware erschlagen.

[MixMax]

vor 42 Minuten schrieb PeWi:

Zusätzlich hat paralleles Arbeiten einiges an Haken und Ösen und ist schwieriger zu debuggen. 

Nett ausgedrückt.  Es ist ein Packt mit dem Teufel. Es können Bugs auftreten die nicht deterministisch sind, die du niemals findest und dich verzweifeln lassen.

Bearbeitet 13. März 2019 von MixMax

[PeWi]

18 minutes ago, MixMax said:

Es ist ein Packt mit dem Teufel. Es können Bugs auftreten die nicht Deterministisch sind, die du niemals findest und dich verzweifeln lassen.

Treffend formuliert!
 

Einen weiteren Punkt gegen Python habe ich oben noch vergessen:

Sobald man Python nicht für sich auf seiner eigenen Hardware betreibt oder zentral als Webanwendung für Kunden, fallen einem die Deployment-Probleme von Python auf die Füsse.

Python ist von Haus aus für die Verwendung als interpretierter Source gedacht. Will man den Quelltext nicht freigeben, weil es um eine kommerzielle Anwendung geht, die beim Kunden läuft, muss man das ganze irgendwie "richtig" kompilieren, damit man den Quelltext los wird.

Exkurs:
Das kompatibelste und stabilste scheint bisher Cython zu sein. Das hat aber auch seine Tücken, weil man für jede Version von Python und für jedes OS eine eigene Version kompilieren muss. Zusätzlich muss der Nutzer trotzdem Python und alle benötigten Module in der richtigen Version selber installieren, damit die Cython-Kompilate funktionieren. (Das fällt mir gerade bei Ubuntu 18.04 aufwärts und Python 3.6 bzw 3.7 auf die Füße ...)

Fazit: Python hat durchaus seine Tücken und ist keineswegs für alle Anwendungsszenarien so problemlos, wie es in obigem Artikel erscheint.

Bearbeitet 13. März 2019 von PeWi

[Herr Coiner]

vor 2 Stunden schrieb PeWi:

Fazit: Bei meinem eigenen Bot merke ich die Langsamkeit von Python schmerzlich, und ich kann sie nicht einfach durch dickere Hardware erschlagen.

Bist du sicher, dass es "nur" an der Sprache liegt? Gerade bei interpretierten Sprachen kommt es auch stark darauf an, wie man progammiert, nicht nur was man programmiert. Python kenne ich zwar nicht, aber als Interpretersprache dürfte die Sache wohl ähnlich liegen wie z.B. bei ECMA-Script (Javascript). Nehmen wir z.B. einen Codeschnipsel wie diesen in Javascript (so ähnlich oft gesehen):

var found = false;
for (var i = 0; i < bli.bla.blu.blo.blubb.length; i++) {

  if (bli.bla.blu.blo.blubb[i] == bli.bla.blu.blo.blonk() ) {
  
    found = true;
  }
}
return found;

Das kann in mehrfacher Hinsicht einfach nur langsam sein:

1. Es wird immer die ganze Schleife durchlaufen, obwohl man beim ersten Fund schon abbrechen könnte bzw. sollte.
2. Es wird bei jedem Durchlauf bli.bla.blu.blo.blonk() ausgefüht, obwohl sich das Ergebnis der Funktion ja nicht ändert.
3. Es wird immer eine ganze Objekthierarchie (bli.bla.blu.blo...) durchlaufen, um auf einen Wert oder ein Objekt zuzugreifen.

Punkt 3 wird oft nicht gesehen, aber zahlreiche Tests meinereseits haben ergeben, dass ein Programm viel schneller läuft, wenn man Objekte oder Werte, die mehr als einmal gebraucht werden, in einer lokalen Variablen zwischenspeichert. Im obigem Beispiel bietet sich dafür auf jeden Fall bli.bla.blu.blo.blubb an. Das hat zusätzlich den Vorteil, dass das Programm leserlicher wird. Und natürlich sollte man bli.bla.blu.blo.blonk() nur einmalig ausführen (Punkt 2), und zwar vor der eigentlichen Schleife:

var i = 0, 
    obj = bli.bla.blu.blo, 
    search = obj.blonk(),
    values = obj.blubb;

for (; i < values.length; i++) {  

	if (search === values[i]) {

		return true;  
	}
}
return false;

 

Bearbeitet 13. März 2019 von Herr Coiner

[PeWi]

1 hour ago, Herr Coiner said:

• Es wird immer die ganze Schleife durchlaufen, obwohl man beim ersten Fund schon abbrechen könnte bzw. sollte.
• Es wird bei jedem Durchlauf bli.bla.blu.blo.blonk() ausgefüht, obwohl sich das Ergebnis der Funktion ja nicht ändert.
• Es wird immer eine ganze Objekthierarchie (bli.bla.blu.blo...) durchlaufen, um auf einen Wert oder ein Objekt zuzugreifen.

Aller drei Probleme bin ich mir bewusst.

Dafür waren der C64, sein Basicinterpreter und das kommentierte Romlisting, in dem jeder einzelne Maschinenbefehl von Interpreter und C64-Betriebssystem kommentiert war, sehr lehrreich.

[Serpens66]

Wozu braucht man eigentlich eine Datenbank? Oder braucht man mit Python das garnicht?
Ich meine orderbooks oder meine selbst erstellten orders kann ich doch wunderbar in in python innerhalb einer Klasse (zb self.orders) abspeichern und habe so immer zugriff drauf.
Aktuell speichere ich ohnehin nur aktuelle Daten und keine Daten von mehreren Tagen/Wochen/Monaten, aber selbst wenn ich das wollte, könnte ich das doch ebenfalls einfach so abspeichern, wozu also eine Datenbank?

edit:
ich vermute mal, dass alles was ich in variablen abspeichere, auf den Arbeitsspeicher geht. Sofern dieser ausreicht, ists gut, aber sobald dieser droht zu erschöpfen (zb weils immer mehr daten werden), sollte man es zb auf eine datenbank auslagern?

Bearbeitet 13. März 2019 von Serpens66

[MixMax]

vor 8 Minuten schrieb Serpens66:

Wozu braucht man eigentlich eine Datenbank? 

Das hab ich mich auch gefragt. Da das aber so überhaupt nicht meine Programmiersprache ist, fühlte ich mich nicht kompetent genug, dass wirklich zu fragen.

Also warum nicht den ganzen Kram einfach ganz normal auf die Platte schreiben?

Bearbeitet 13. März 2019 von MixMax

[PeWi]

44 minutes ago, Serpens66 said:

Wozu braucht man eigentlich eine Datenbank? Oder braucht man mit Python das garnicht?

Prinzipiell ist das doch von der Sprache unabhängig?

Wenn du Daten hast, die einen Botabsturz oder -neustart überstehen müssen, dann müssen sie auf Platte gespeichert werden. Ob als Textfile oder in einer Datenbank, hängt dann vom Umfang der Daten, was du mit ihnen machen willst und deinen Gepflogenheiten ab.

[Herr Coiner]

vor 1 Stunde schrieb MixMax:

Das hab ich mich auch gefragt. Da das aber so überhaupt nicht meine Programmiersprache ist, fühlte ich mich nicht kompetent genug, dass wirklich zu fragen.

Also warum nicht den ganzen Kram einfach ganz normal auf die Platte schreiben?

"ganz normal auf die Platte"... wie meinst du das? Man hat z.B. drei Coins, und jeder hat täglich einen Kurs, oder sogar 4 Kurse (OHLC). Nach einer Woche will man dann sehen, wie sich die Kurse entwickelt haben. Wie würde das konkret auf der Platte aussehen? Wie holt man z.B. den Coin3-Schlusskurs vom Mittwoch wieder zurück von der Platte? Vielleicht in einzelnen Dateien speichern etwa so:
Coin1-Montag-O.txt
Coin1-Montag-H.txt
Coin1-Montag-L.txt
Coin1-Montag-C.txt

… usw. usf. und jede Datei enthält dann eine Zahl? Das wäre natürlich extrem umständlich, platzverschwendend und praktisch nicht zu gebrauchen.

Dafür hat man eben eine Datenbank mit mindestens einer Tabelle drin, woraus man dann die gewünschten Werte ganz einfach wieder auslesen kann, mit Hilfe einer Abfragesprache wie SQL. Sowohl das Speichern wie auch das massenweise Auslesen bestimmter Daten wird dadurch sehr einfach. Es ist ja nicht so, dass Datenbanken nur ein Klotz am Bein wären, im Gegenteil. Sie nehmen einem viel Arbeit ab.

[MixMax]

vor 14 Minuten schrieb Herr Coiner:

"ganz normal auf die Platte"... wie meinst du das? Man hat z.B. drei Coins, und jeder hat täglich einen Kurs, oder sogar 4 Kurse (OHLC). Nach einer Woche will man dann sehen, wie sich die Kurse entwickelt haben. Wie würde das konkret auf der Platte aussehen? Wie holt man z.B. den Coin3-Schlusskurs vom Mittwoch wieder zurück von der Platte? Vielleicht in einzelnen Dateien speichern etwa so:
Coin1-Montag-O.txt
Coin1-Montag-H.txt
Coin1-Montag-L.txt
Coin1-Montag-C.txt 

Ja so ähnlich meint ich das, nur halt alles in einer Datei.

[Jokin]

vor 2 Stunden schrieb Serpens66:

Wozu braucht man eigentlich eine Datenbank?

Ich schreibe mein Logdaten in die Datenbank, damit ich komfortabel in den Einträgen suchen und filtern kann.
Ich schreibe auch meine histrorischen Daten in die Datenbank, damit kann ich auch da Auswertungen durchführen.

Außerdem LIEBE ich Datenbanken über alles, ich bin damit groß geworden und schreibe keinerlei Daten auf die Festplatte, da sowas viel zu umständlich ist.

Weiterhin parallelisiere ich meine Software damit auf absolut simple Art und Weise. Denn auch mit PHP kann ich nicht einfach mehrere Aufgaben parallel abarbeiten lassen - aber ich tu's dennoch :-)
... ob nun PHP oder Python ist vollkommen egal, mein Parallelisierungskonzept ist super einfach und unabhängig von der Programmiersprache.

[MixMax]

vor 5 Minuten schrieb Jokin:

Außerdem LIEBE ich Datenbanken

Das reicht mir als Antwort 🙂

Bearbeitet 13. März 2019 von MixMax

[Serpens66]

ok, ich hab meine logdateien bisher als txt datei gespeichert, eine datei für jeden Tag und in der neuen woche werden die dann überschrieben (sind in erster line zum Fehlerfinden da, nicht um iwas auszuwerten).

Bzgl Parallelisierung Jokin, hast du dann ein Skript welches zb alle x Minuten das Orderbook abfragt und das ergebnis in ne datenbank schreibt und alle bots bedienen sich dann von der datenbank anstatt selbst nen call zu machen, oder wie läuft das ?

Bearbeitet 13. März 2019 von Serpens66

[PeWi]

58 minutes ago, Herr Coiner said:

"ganz normal auf die Platte"... wie meinst du das? Man hat z.B. drei Coins, und jeder hat täglich einen Kurs, oder sogar 4 Kurse (OHLC). Nach einer Woche will man dann sehen, wie sich die Kurse entwickelt haben. Wie würde das konkret auf der Platte aussehen? Wie holt man z.B. den Coin3-Schlusskurs vom Mittwoch wieder zurück von der Platte? Vielleicht in einzelnen Dateien speichern etwa so:
Coin1-Montag-O.txt
Coin1-Montag-H.txt
Coin1-Montag-L.txt
Coin1-Montag-C.txt

… usw. usf. und jede Datei enthält dann eine Zahl? Das wäre natürlich extrem umständlich, platzverschwendend und praktisch nicht zu gebrauchen.

Wieso kommst du mit so 'nem abstrusen Vorschlag? Nur damit du "Abspeichern in Textdateien" als unsinnig abtun kannst?

Etwas realistischer würde man das z.B. in einer CSV-Datei pro Coin speichern. Da passen dann jeweils ganz viele Kurse rein und brauchen vermutlich auch kaum mehr Platz als deine DB.

[Jokin]

vor 38 Minuten schrieb Serpens66:

Bzgl Parallelisierung Jokin, hast du dann ein Skript welches zb alle x Minuten das Orderbook abfragt und das ergebnis in ne datenbank schreibt und alle bots bedienen sich dann von der datenbank anstatt selbst nen call zu machen, oder wie läuft das ?

Ja, so ungefähr.

vor 38 Minuten schrieb Serpens66:

eine datei für jeden Tag und in der neuen woche werden die dann überschrieben (sind in erster line zum Fehlerfinden da, nicht um iwas auszuwerten).

Ich werte weit mehr als Fehler aus, mir geht es z.B. auch darum Statusmeldungen zu sehen und um mich selber zu optimieren. Außerdem kann ich zu einem Datensatz aus verschiedenen Quellen Informationen hinzufügen.

vor 15 Minuten schrieb PeWi:

Da passen dann jeweils ganz viele Kurse rein und brauchen vermutlich auch kaum mehr Platz als deine DB.

Platzbedarf ist bei mir kein Grund "pro Datenbank". 

[MixMax]

vor 1 Stunde schrieb Jokin:

Weiterhin parallelisiere ich meine Software damit auf absolut simple Art und Weise. Denn auch mit PHP kann ich nicht einfach mehrere Aufgaben parallel abarbeiten lassen - aber ich tu's dennoch 🙂
... ob nun PHP oder Python ist vollkommen egal, mein Parallelisierungskonzept ist super einfach und unabhängig von der Programmiersprache.

Das ist wirklich sehr geschickt, damit gehst du allen multithread Problemen von vornherein aus dem Weg.

Bearbeitet 13. März 2019 von MixMax