Forex1+

Hallo, das ist schockierend, ich bin im Detail noch nicht komplett durchgestiegen aber ich frage mich bleibt noch etwas handelbares übrig oder war es das dann komplett mit Daytrading? Gibt es danach noch irgendwelche Underlyings die man "normal" traden könnte, welche wären das? LG

"Korrelation der Kryptowährungen untereinander nimmt immer weiter zu" https://kryptoszene.de/korrelation-der-kryptowaehrungen-untereinander-nimmt-immer-weiter-zu/ Solange das so ist kann man IOTA vergessen. Schade. Da sieht man mal wieder (wie bei Aktien) das fundermentale Dinge heute überhaupt keine Bedeutung mehr haben.

https://coin-hero.de/deutsche-universitaet-will-iota-fuer-reale-industrieanwendung-nutzen/ "Fundamental" bleibt IOTA für mich an der Spitze, die technischen Vorteile gegenüber den anderen Technologien sind massiv. Grenzenlose Skalierbarkeit, keine sinnlose Stromverschwendung, etc. Der Nachteil bleibt aber, und das sollte man nicht unterschätzen, die scheinbar gezwungene Korrelation mit den unterlegenen Technologien wie Bitcoin etc. Insofern, wenn die Schwachsinns-Kryptos kaputt gehen, bekommt auch leider IOTA eins auf den Deckel. Spannend ist daher ob der Korrelationskoeffizient zu den anderen in Zukunft sinkt und sich IOTA abkoppeln kann. Langfristig wird die Sache interessant bleiben, ich denke die Leute werden lernen Kryptos differenzierter zu betrachten und sich so in Zukunft die Spreu vom Weizen trennt.

Ist da jetzt echt jeder Broker der betreffenden Ländern betroffen? Und die OECD passt dann gewissenhaft auf die Daten auf oder wer ist der Glückliche? Datenhandel, so ein lukratives Geschäftsmodell...

Bin auch investiert. Zur Zeit ist das Ding in starker Korrektur nach dem Run zur Fünfer-Marke (bezogen auf IOTUSD) und auch weil Microsoft die Kooperation dementiert hat. Aber langfristig sehr sehr interessant und die Technologie überzeugt mich (made in Germany ). Soll aber bitte keine Kaufempfehlung sein, die Exchanges und eigentlich das ganze Thema steht unter massiven Beschuss von Angriffen (bitfinex hat da seine Erfahrung gemacht), ohne 2FA da sowieso nichts machen und schon gar nicht mit Geld was weh tut. Euroeinzahlung bei bitfinex ist erst ab 10000€, daher wie schon gesagt wurde am besten mit anderem Coin tauschen, ich hatte es mit ETH getauscht. Sonst geht auch noch binance als Exchange. Hoffentlich eher ein paar MINOTA sonst wäre es arg wenig, oder eben ein paar Millionen IOTA Lieber hier im Thread

[offtopic] es sind 48.6% [/offtopic]

Der Error zeigt einen ungültigen Funktionsparameterwert. Prüfe vielleicht mal ob Funktionen wie zB. OrderCloseBy() auch immer die richtigen Ticketnummern bzw. Parameter bekommen. Grüße

Wenn ich mich richtig erinnere geht das per // Kommentar direkt hinter der Variable in der gleiche Zeile welche als extern deklariert ist. Zum Beispiel: extern int Timeframe = 0; // Kommentar der den Variablennamen ersetzt Gruß

Hallo, zum Systemtraden habe ich Schritt für Schritt ein eigenständiges Programm (keine DLL) geschrieben das alles ausser der Ausführung übernimmt. MT5 möchte ich als flexiblen Executor und Datenquelle nutzen. Da natürlich mehrere Märkte gehandelt werden sollen, überlege ich ob ich alles in ein Programm und somit Prozess packe, die Systeme darin pro Markt in eigenen Threads laufen lasse, die Kursdaten bündele ODER für jeden Markt ein Programm und somit Prozess laufen lasse, die Kursdaten einzeln bezogen werden. Die Daten kann man per EA pro Markt per DLL rausziehen und darüber auch die Execution laufen lassen. Alternativ könnte man auch (etwas komplizierter aber geht) die Daten mehrerer Märkte mit nur einem EA rausziehen. Würdet Ihr das pro Markt getrennt machen oder Bündeln? Bei der Trennung in eigene Prozesse sehe ich den Vorteil, dass wenn ein System eine Exception verursacht nicht gleich der Prozess mit allen Threads kaputt geht, ich bin nicht sicher ob man mit try-catch alles abfangen kann...? Auf der anderen Seite wäre eine Bündelung komfortabler, man muss nicht für jeden Markt den EA und den Prozess einzelnd starten. Beim Zorro Projekt habe ich gesehen, wird pro Markt ein EA mit DLL geladen und darüber eine Bridge realisiert, das Zorro Programm ist aber wohl nur ein Prozess und bündelt alle Märkte. Welche Variante findet Ihr am besten, wie würdet Ihr das machen? Gruß

if (TimeCheck) { // geliebter Zeitraum: // normale Tradinglogik... } else { // ungeliebter Zeitraum: if(Orders_offen) { // schließe alle offenen Orders } }

Bei einem Einzeiler nach einer if Abfrage kann man die Klammern weglassen lag das Verständnis evt daran? Du kannst es auch so schreiben: bool TimeCheck = true; if (TimeHour(iTime(NULL,0,0))==22 && TimeMinute(iTime(NULL,0,0))>=50) { TimeCheck = false; } if (TimeHour(iTime(NULL,0,0))==23) { TimeCheck = false; } if (TimeHour(iTime(NULL,0,0))==00 && TimeMinute(iTime(NULL,0,0))<30) { TimeCheck = false; } if (TimeCheck) { // Mach mich reich :) } Gruß

Naja hängt davon ab wie und womit die Studie gemacht wurde... Die Ineffizienzien findet eben nicht jeder und das die Märkte so effizient sind hat man ja oft gehört HFTler benutzen vor allem einen kurzen Draht (Serverstandort) und hardwarenahe Programmierung, eine besondere intellektuelle Leistung braucht man da nicht loben bei dem Vorteil

Ich würde die Periode des Indikators so einstellen das sie entsprechend der gewählten Zeiteinheit dem Zeitraum entspricht. Der Zeitraum ergibt sich aus der gewählten Periode und der Zeiteinheit der Kerzen. Es gibt sicher auch den Usecase, wo es mit der Unixzeit besser klappt. Für mich ist meistens interessant welcher Wochentag und welche Zeitspanne von Stunden am Tag daher die Präferenz diese Werte direkt vorliegen zu haben.

Der Vorteil ist, dass die Daten in dem Format vorliegen wie sie auch verarbeitet werden. Ein Filter der Trades nur von 9-17 Uhr zulässt braucht dann nur die Abfrage if((Stunde>=9)&&(Stunde<17) und fertig. Stunde dann zb als char in einem Struct. Per Unixzeit wird die if Abfrage wesentlich komplexer da erst die Stunde aus den Unixsekunden ermittelt werden muss und dieser Vorgang braucht Zeit zumindest in cpp deutlich spürbar wie ich festgestellt habe.

Hallo, hiermit eröffne ich mal ein Thread rund um das Thema Datum und Zeit und wie damit Systemtrader beim Programmieren umgehen. Zwei Aspekte sind, in welchem Format liegt die Zeit vor und wie verarbeite ich es zum Abgleich zwischen Zeitpunkten oder die Ermittlung gewisser Zeitspannen, Wochentage oder sonstigen Zeitfiltern. Meißt liegt die Zeit in den Historys im Timestamp Format YYYYMMDDHHMMSS(NNN) vor. Intern in den Codes wird aber meißt die Unixzeit für die Filter verwendet. Das finde ich irgendwie naja komisch denn das Timestampformat der History muss zuerst in Unixzeit umgerechnet werden. Und dann um aus der Unixzeit Wochentage, Stunden und weiteres rauszuholen bedarf es einer Zeitstruktur um die Komponenten für den gregorianischen Kalender zu erhalten (in zb cpp struct tm). Um Filter zu bauen kommen schon ansatzweise komplexe Funktionen dabei raus um die gewünschten Abfragen durchzuführen. Interessanterweise wird in Tradingbüchern zur Entwicklung automatisierter Systeme so gut wie nicht auf das Thema eingegangen. Die Umwandlungen führen natürlich zu einer Performancebremse, nicht im Livetrading aber schon deutlich spürbar im Backtesting. Da drängt sich mir der Gedanke auf, wieso die Zeit nicht in effektiverer Form zur Verfügung stellen, sodass die Filter einfacher gestaltet werden können. Ohne permanente Umwandlungen von Unixzeit zu den Infos aus dem gregorianischen Kalender wäre es schneller aber man erkauft sich diesen Vorteil evt. durch mehr Speicherverbrauch. Jetzt würde mich interessieren wie andere Systemtrader damit umgehen oder dazu sagen? Es sollte doch nicht sein das die Timestampverarbeitung und Zeitfilter so einen Flaschenhals erzeugen. Grüße

Hier ist eine Liste: https://github.com/pirate/sites-using-cloudflare/archive/master.zip Von https://github.com/pirate/sites-using-cloudflare

Pragmatisch aber ich bin ziemlich sicher das es performantere Lösungen gibt (die natürlich aufwändiger sind) Es ist die Frage ob man Tickqualität gegen Performance eintauschen will indem man sie synthetisiert bzw. auf OHLC rechnet. Sobald man viele verschiedenen Tickquellen parallel verarbeitet fängt das Problem an. Da es nur ein Performanceproblem ist, ist es am Ende ein Optimierungsproblem und kein Backtestproblem. Was Threading angeht denke ich kann man nie früh genug anfangen alles einzuplanen, bevor ich was anpacke checke ich lieber alles im Vorfeld, dauert zwar viel länger aber man muss dann nicht von vorn anfangen weil die Basis nicht stimmt.

Es wird eigentlich nur ein Bottleneck geben, wenn eben nicht alles in RAM passt. Ausserdem kann der Bottleneck nach der Platte auch alles Mögliche sein, Komplexität des Systems, Effizienz der Datenstrukturen, Kompilersettings, Sprache usw... Die Frage lief ja darauf hinaus wie programmtechnisch damit umgehen wenn RAM nicht reicht. DB parallel lesend in der Regel kein Problem also keine csv nehmen. Sollte ich an den Punkt kommen wo der Platten-Bottleneck kommt zB bei Portfolioticktest, dann werde ich vermutlich mehrere Varianten testen und einfach Messen welche die schnellste ist. Aber vielleicht hab ich am Ende keine Lust, rüste soviel RAM wie möglich auf und synthetisiere bei dem usecase einfach die Ticks Muss sowieso dann mal schauen ob bei Optimierungen dann die Tickgeschichten nicht zu lahm werden.

Standard-OS eher nicht: Octane III supports Microsoft HPC Server 2008, SUSE® Linux® Enterprise Server and Red Hat® Enterprise Linux operating systems. Linux configurations include SGI ProPack™ and ISLE™ cluster management software. https://www.sgi.com/company_info/newsroom/press_releases/2009/september/octaneIII.html http://www.designspace.com/staticassets/ANSYS/staticassets/partner/SGI/sgi-octane-III.pdf

Ich vermute für den Preis gibts nur die Basisversion sonst wäre es schon fast günstig. Eine Stromflatrate bräuchte man dann noch...

Klar mit genügend teurer Hardware kann man das hinbekommen (was für Singletests, wie Mythos vorgerechnet hat, nicht mal nötig wäre). Mal vom Preis abgesehen müssen die Motherboards das auch erst mal unterstützen. 32bit schafft natürlich Limits und 2038 gibts dann auch noch time-Probleme. Das Aufrüsten von RAM macht sicher mehr Sinn als komplizierte und langsameren Notlösungen zu basteln auch wenn hier praktische Limits durch Preis oder Motherboard gesetzt sind. Aber für den interessierten User wie mich war die spannende Frage, was machen Amibroker oder Kollegen wenn zu wenig Ram zur Verfügung steht, dass es zum Vorladen nicht reichen kann? Die kommerziellen Plattformen müssen so programmieren, dass es kompatibel mit vielen Computern unterschiedlicher Ausstattung ist. Die Mindestanforderungen sind z.B. bei Amibroker sehr genügsam mit 128 MB RAM, empfohlen 512 MB RAM. Also kann man davon ausgehen, dass das Programm mit 128 MB noch funktionsfähig wäre. Und man kann davon ausgehen, dass 128 MB für einen Test mit fein skalierten Daten wie Tick oder eben worstcase Portfolio, nicht reicht um es vorzuladen. Entweder dieser Fall wurde von den Proggern komplett ignoriert und man verlässt sich auf das OS welches den Speicher auf die Festplatte auslagert (pragmatisch aber langsam), oder die Daten werden dann direkt (oder werden sowieso) von der Platte gezogen.

Auf einem Underlying geht das wirklich gut das stimmt. Mit dem Threading bezog sich auf Portfoliotests wo es dann viele unterschiedliche Quellen gäbe. Aber bis dahin hab ich sowieso noch genug andere Baustellen

Wenn man sich RAM vs SSD nochmal näher anschaut (Link) muss man schon deutlich feststellen das zwar SSD im Vergleich zu HDD einen großen Sprung gemacht hat aber RAM ist nochmal eine ganz andere Welt. Zugriffszeit Faktor ca 1550, lesen-MB/s Faktor ca 100 im Vergleich zu SSD. Daher würde ich schon sagen der Flaschenhals ist weiterhin die Festplatte/SSD (oder die Systemlogik wenn man damit übertreibt).

Je nachdem was das System so als Futter braucht, würden auch noch die OHLC Zeitcharts dazukommen aber dessen Liste ist, je höher der TF, auch viel kleiner als bei den Ticks. Wo es eng wird ist allerdings beim Multithreading wenn gleichzeitig und unabhängig die Daten im Ram bereit gestellt werden müssen. Was du zur SSD schreibst hab ich bisher nicht so betrachtet und find ich gut. Es wäre natürlich optimal gar keine Zwischenschicht zu bilden denn dann kann man sich das Gebastel mit dem Zwischenladen in den RAM sparen und alle Charts direkt aus der DB heraus beziehen. Man müsste es einfach mal testen. Vielleicht machen es die großen Plattformen auch nicht anders als Tabellen von der Platte zu iterieren. Allerdings selbst die Portfoliochecks sind echt schnell und das auch bei HDDs. Das war ja auch der Grund warum ich dachte, dass die ein bestimmten Trick zum durchschleifen nutzen auf den ich noch nicht gekommen bin.

Ich kenne es nur von MT4, da wird für die Ticksimulation eine große Datei erzeugt die dann vermutlich durchgeschleift wird. MT4 ist aber sicher nicht so das beste Beispiel für sowas. Eine DB auf einer SSD durchzuschleifen ist sicher schon nicht schlecht aber vom Ram ist eben doch noch was anderes.