Technix

Für funktions-lokale statische Variable ist es in der Doku explizit angegeben: Es entspricht damit dem Verhalten in C, wo bereits der Compiler die Werte einsetzt und den fertigen statischen Datenblock ohne Änderung in der Programm-Initialisierung läßt. Das Initialisieren der (hoffentlich nicht allzu vielen) globalen Variablen in init() kann trotzdem als guter Stil gelten gelassen werden.

Der Zusammenbau einer Konstante funktioniert nicht, da die vollständige Konstante selber das Atom für den Parser ist. Wegen der internen Farb-Darstellung geht: color C = ((b << 8) + g) << 8 + r // oder gleichwertig: color C = b << 16 + g << 8 + r

Auch wenn es in der Natur von Gerüchten liegt, daß Genaueres schwer zu erfahren ist und Mitreden darüber eigentlich ein schlechter Diskussionsstil ist, sollte es inhaltlich durchaus einige Gründe für dieses Gerücht geben können. Kosteneinsparung beim Personal ist ein solcher Grund und beim Erfüllen der notwendigen mehrfachen Anforderungen für die verschiedenen Juristdiktionen ein zweiter. Der wichtigste ist aber das Geschäftssystem "Verbrannte Erde", bei dem nur einmal alle gierigen Kleinst-Spekulanten abgezockt werden können. Danach ist für lange Zeit nicht mehr viel zu holen, da erst neue Leute mit neuer Hybris nachwachsen müssen, die meinen, daß sie mit ihrem Mini-Kapital clevere Macher von Abzock-Plattformen, die noch dazu genaueste Nutzer-Statistiken über all ihre Opfer und deren Verhaltensweisen haben, um deren Geld erleichtern können. Daß das aber nicht möglich ist, hängt damit zusammen, daß die ohnehin recht wenigen wirklich dauerhaft proftitablen Trader von solchen Plattformen mit allerlei Schikanen herausgedrängt werden, insbesondere mit stark verzögerter manueller Ausführung (RFQ). Grundsätzlich wollen die OTC-Buden alles Kapital des Traders und das recht zügig und eher kein dauerhaftes Geschäft mit den Spreads. Diesem Ziel dienen auch die "Trade-Out-Levels", "Airbags", Mini-"Maintainance Margins" oder wie auch immer sie genannt werden. Würde bei 100 % der Margin Schluß mit dem Trade sein, würde der Trader nämlich wenigstens diese behalten. Erst durch ein deutliches Unterschreiten der ursprünglichen Margin-Anforderungen zum Triggern und dann einem gezielten Slippen bis nahe an die 0-Grenze kann überhaupt erst alles Kapital des Traders bei den OTC-Buden landen.

Das stillschweigende Weglassen eines Trades in der Abrechnung, der in der Client-Plattform bereits sichtbar war, ist kein ordnungsgemäßes Geschäftsgebaren. Jede schon mal gemachte Buchung ist durch eine erkennbare Storno-Buchung zu korrigieren. Zusätzlich zur Rückabwicklung der Buchung gehört eine kurze Begründung dafür mitgeteilt. Diese Forderungen sind bei jedem auch nur mit minimaler (und gesetzlich vorgeschriebener) kaufmännischer Sorgfalt agierenden Unternehmen zwingend und sollten daher auch explizit eingefordert werden. Ein Unternehmen, welches sich auch nur ein einziges Mal das Recht herausnimmt, Buchungen im Dunkeln beliebig zu manipulieren (unabhängig von der Berechtigung einer evtl. sogar nötigen Korrektur), ist vertrauensunwürdig, denn es geht nicht nur um einen Einzelfall, sondern um eine bewußt programmierte Infrastruktur, die solche nicht nachvollziehbaren Manipulationen ermöglicht. Ebenso sollte das der Aufsichtsbehörde mitgeteilt werden. Solange man dort mit ein paar hundert Euro spielt und das ganze auch als Spiel ansieht, kann man das vielleicht gerade noch dulden, für ordentliche Geschäfte mit relevanten Beträgen hat sich eine solche Bude disqualifiziert.

@ Henrik Diese Aussage ist nicht gerecht, da Interactive Brokers für Eröffnung und Schließung eines Kontos und die erste Rücküberweisung in jedem Monat gar nichts verlangt und die Preise für die Daten 1:1 die der Börsen sind, die IB selber in Rechnung gestellt werden. Sie kassieren also nur genau das Minimum, was überhaupt möglich ist. Bei den CFD-OTC-Buden bekommst Du deren Hauspreise und ihre Produkte haben nicht umsonst Phantsienamen wie "German30" statt DAX usw., weil Du neben ihrem Bemühen von den Börsen urheberrechtlich geschützte Begriffe zu vermeiden dort auch deren Phantasiekurse siehst. Die FX-Kurse sind bei IB übrigens völlig frei. Das Geschäftsgebaren von IB ist in der Beziehung also geradezu vorbildlichst. Als Viel-Trader bist Du mit einer Trennung der Kosten für Daten und Trades besser aufgestellt als mit einem Bündelpreis, wo die Datenpreise implizit in den Trade-Preisen oder Spreads enthalten sind, es sei denn, das wird mit einer ordentlichen Rabatt-Staffel wieder ausgeglichen, die es aber gerade bei den OTC-Anbietern, die sich über den Spread finanzieren, nicht gibt. Der einzige ehrliche Kritikpunkt an IB ist ihr Service-Desk, auf den man sich etwas einstellen muß, sonst kann ich nach vielen Jahren Handel dort nur Positives berichten und kenne eine ganze Reihe von Tradern, die das genauso sehen.

Auch wenn davon auszugehen ist, daß es sich in diesem Fall um massive Copyright-Verstöße handelt, verbietet die bekannteste Open-Source-Lizenz GPL den Verkauf von Software zu beliebig hohen (also insbesondere auch weit über eigene Kopier- oder Materialkosten hinausgehenden) Preisen überhaupt nicht. Sie verlangt nur, daß dem neuen Nutzer der Software genau die gleichen Rechte eingeräumt werden, wie dem Übergebendem, insbesondere die Möglichkeit des vollständigen Zugriffs auf den Quelltext und dessen Modifizierung. Freie Software nach Sicht der an die Free Software Foundation angelehnten Lizenzen (was bei weitem nicht alle Lizenzen für freie Software sind) ist mit den Worten des wichtigen Pioniers Richard Stallman im Sinne von "Free speech" und nicht im Sinne von "Free beer" zu verstehen. Einige Lizenzen für freie Software, wie z. B. die BSD-Lizenz erlauben sogar die kommerzielle Nutzung in proprietärer Software unter der einzigen Bedingung des Belassens ursprünglicher Copyright-Vermerke. Bei Freigabe in die Public Domain gelten sogar überhaupt keine Restriktionen mehr, wobei ganz wichtig ist, daß fast alle in den USA mit direkten Steuermitteln erstellten Programme dazu gehören, also insbesondere viele Ergebnisse universitärer Arbeiten und anderer staatlicher Einrichtungen.

Für die API sind folgende Beschränkungen angegeben, die dann theoretisch eigentlich für jede Software gelten sollten. Mit der bei den API-Demos verfügbaren Excel-Tabelle kann man aber über die DDE-Schnittstelle nach Änderung der entsprechenden Parameter wahrscheinlich auch längere Historien (notfalls in Stücken) herunterladen. Das hat mir zumindest mal Herr Zebisch vom Schweizer Support-Team gezeigt, allerdings ohne daß ich es mal selber gemacht habe, da ich die eigenen gestreamten Daten aufbewahre. Die Demo sagt ohnehin nicht sehr viel, da die Real- und Papertrading-Accounts mit genau den bezahlten Daten-Abos gehen. Da IB sowohl bei der Kontoeröffnung als auch beim Auszahlen von Geld recht fix ist, ist die beste Idee, mit einem eigenen Konto alles auf dem Papertrading-Account durchzugehen.

Wenn es wirklich keine Hinweise auf die geänderten Passagen gibt, kann man die PDF-Dokumente mit einem der PDF-Diff-Tools ansehen, ersatzweise auch nach einem PDF-zu-Text-Konverter und die reinen Texte mit der Vergleichsfunktion eines Editors oder einem Text-Tool wie diff.

@ siscop duncan's Lösung ist wohl das, was Du meinst. Der Fehler ist, daß die Operationen innerhalb der IF-Bedingung Einzelwerte erfordern, Du sie aber mit dem vorher gewonnenen Array aus Ref beschickst. Um einen Einzelwert aus einem Array zu holen sind die [] zu nutzen, Ref versetzt ein ganzes Array um den Offset. Es gilt: Ref(X, n)[m] = X[n + m] (hoffe ich wenigstens mal, ohne es getestet zu haben)

Ref liefert ein Array, keinen Einzelwert.

Ich kann nur dringendsd empfehlen, den ganzen Konfigurations-Einstellungsbaum vor dem Traden durchzugehen und überall sinnvolle Einstellungen vorzunehmen und jede Bedienhandlung vorher im Paper-Trading-Account zu probieren. Das empfiehlt sich durchaus auch für jedes neue Instrument, damit man nicht irgendwas (wie z. B. den Kontrakt-Multiplikator oder eine Auführungs-Kondition) übersieht. Nachtrag: Uups, das ist komisch: Vor meinem Post habe ich nur das Eröffnungspost von siscop ohne Followings gesehen. So war die Mühe umsonst. Da ich nun auch die Followings gesehen habe, kann ich zur automatischen Anmeldung sagen, daß die nur über Tools auf Betriebssystem-Ebene geht, da von TWS-Seite dieser Dialog bewußt nicht umgangen werden soll. Für solche Fragen ist es nützlich im IB-Thread bei AB und im IB-Forum selber nachzusehen.

@ forextrading24 Sollte die Stabilität eines EA nicht höher sein, als daß er von 1/10-Pips abhängt?

@ Henrik Die graphische Aufbereitung ist eine der ganz großen Stärken von R. Dafür gibt es eine große Zahl von Paketen auf jedem CRAN-Mirror. Alle Mirrors haben den gleichen Inhalt, man kann also den nächsten nehmen. Selbst wenn man die Statistik nicht nutzen will, ist R alleine zum Darstellen von Bildern sehr gut zu verwenden. Die Zerlegung in aufwendige Berechnungen anderswo und die Darstellung der Resultate mit R ist ein durchaus häufig gegangener sinnvoller Weg. Romain François stellt auf seiner Web-Seite Super-Inspirationen für tolle R-Grafiken verschiedener Autoren mitsamt vollständigen Quelltexten vor. Die Programmierung ist sehr einfach, da sie auf einem Nutzer-bezogenen High-Level mit wenigen Anweisungen stattfindet. Die ganzen Low-Level-Geschichten sind in den Paketen verborgen. Wenn man genug mit den diversen Parametern herumspielt und einige Graphik-Typen kombiniert, ist es immer wieder erstaunlich, was alles geht. Ähnliche Ausgaben (auch mit vergleichbaren, aber nicht den gleichen Parametern) kann man mit den Open Source Tools GNUPlot oder Octave (einem Mathlab-Clone) erstellen, wobei bei ohnehin nötigem Bedarf an nahezu universellen statistischen Fähigkeiten durchaus R der Vorzug gegeben werden sollte.

@ conglom-o Mit der gleichen Strenge gesehen, entspricht eine Signalgebung auf der Basis des alten Kontraktes für den neuen ohne weitere Umrechnung dem nicht adjustierten Endloskontrakt und bei tagesübergreifenden Regeln zur Signalgebung findet die in der Nähe der Rolltermine schon irgendwo statt. Alleine schon wegen der notwendigen Datenmenge für Backtests (die nach statistischen Erfordernissen u. a. von der Trefferquote abhängt und gerade bei Systemen mit geringer Trennschärfe der Regeln sehr stark zunimmt), die über sehr kurze Time-Frames hinausgehen, werden meist Daten mehrerer Kontrakte irgendwie zusammengebracht werden müssen. Wichtig ist nur der Aspekt, daß auf dem Futuresmarkt die Kontrakte in ihren ersten Zeiträumen nach der Neueinführung (also je nach Kontrakttyp schon sehr lange vor ihrem Verfall), mangels Liquidität und wegen unsystematischen Abweichungen nur sehr bedingt für die Signalgebung benutzt werden können und die Haupt-Aufmerksamkeit auf den aktuellen und den folgenden Kontrakt zu richten ist, entweder mit Adjustierung oder ohne, aber immer im Bewußtsein der Problematik und der Auswirkungen je nach getestetem System.

Beim Future-Handel müssen die Kontrakte zu einem einheitlichen Kontrakt, dem Endlos-Kontrakt, zusammengehängt werden. Dabei gibt es grundsätzlich ein Problem, da verschiedene Kontrakte wegen der unterschiedlichen Fälligkeiten deutlich unterschiedliche Wirtschaftsgüter sind, die auf dem Markt auch unterschiedliche Preise haben. Rein rechnerisch bestünde der theoretische Unterschied aus den unterschiedlichen Cost-of-Carry. Die Cost-of-Carry bestehen ganz wesentlich aus den zu zahlenden Zinsen (long, bei Zins-Futures bei inverser Zinsstruktur und bei Währungs-Futures in Abhängigkeit der Zinssätze auch bei short), den vereinnahmten Zinsen (genau das Gegenteil der Long-Seite, da die Verzinsung bis zur Fälligkeit durch die Markt-Teilnehmer selber über den Preis geregelt wird), sonstigen Zahlungen (erhaltene bzw. entgangene Dividenden und Sonderausschüttungen) und Kosten zum Handling des Underlyings (insbesondere bei physisch lieferbaren Rohstoffkontrakten). Praktisch weichen die Preisdifferenzen davon zum Teil erheblich (auch innerhalb eines Tages schwankend und als Spread auch eigenständig handelbar) ab, da zusätzlich Erwartungen der Markteilnehmer in Preis- und Zinsänderungen eingehen oder schlichtweg niemand die Arbitrage so schnell hinbekommen hat oder überhaupt daran interessiert war (z. B. weil er sein Preismodell zu große Unsicherheiten zeigt). Der Endlos-Kontrakt kann durch einfaches Zusammenhängen gebastelt werden, was den Vorteil hat, daß die Preise mit den historischen übereinstimmen. Der Endlos-Kontrakt kann auch adjustiert werden, wozu (neben anderen) meist eines der folgenden 3 Verfahren genutzt wird: Die Kurse eines festgelegten Ausgangszeitraumes werden 1:1 übernommen, beim Kontrakt-Wechsel wird die Differenz der Kontrakte vom neuen Kontrakt subtrahiert. Dabei bleiben alle zukünftigen Kurse stabil, haben aber Werte, die niemals gehandelt wurden. Die Kurse des letzten Kontraktes werden 1:1 übernommen, beim rückwirkend durchgeführten Kontrakt-Wechsel wird die Differenz der Kontrakte zum vorigen Kontrakt summiert. Vorteil ist, daß der aktuelle (und für ein System meist wichtigste) Kontrakt die gleichen Kurse hat, wie der Endloskontrakt. Nachteil ist, daß mit jedem neuen Kontrakt eine neue Rückwärts-Rechnung nötig wird. Der Kontrakt-Wechsel wird über den Zeitraum der Differenz zweier folgender Kontrakt-Fälligkeiststermine kontinuierlich im Verhältnis Rest-Laufzeit des aktuellen Kontraktes / Abstand der beiden Verfallstermine für den aktuellen Kontrakt und 1 - das Verhältnis für den neuen Kontrakt vorgenommen. Das ergibt die am natürlichsten wirkenden Zahlen, die aber einen Bias haben, der beim einen oder anderen Indikator zu subtilen Misdeutungen führen kann. Die beiden ersten Verfahren erzeugen oft wenig intuitive adjustierte Kurse, es sind sogar negative Kurse denkbar. Sie haben aber den Vorteil, daß die Wertveränderung einer Position, die aus lauter fotlaufend gerollten Futures besteht, direkt der Differenz der adjustierten Kurse entspricht. Die Verfahren können modifiziert werden, indem sie über den Logarithmen durchgeführt werden, also bezüglich der Kurse relativ und nicht absolut adjustiert wird. Welche Adjustierung man benutzt, hängt vom Zweck ab, insbesondere welche Indikatoren oder Regeln das Handelssystem benutzt. Für einige Zwecke reichen auch nicht-adjustierte Endloskontrakte und ich kenne mehrere Trader, die sie auch im Backtest erfolgreich nutzen, während sie für andere Trading-Ideen nicht reichen. Eine für alle Zwecke brauchbare einfache Daumenregel gibt es leider nicht, wenngleich viele Trader einfach irgendein vom Datenlieferanten implizit geliefertes Adjustierungsschema nutzen - und je nach System mal vernachlässigbare Fehler, mal aber auch fragwürdige Resultate bekommen.

Nachtrag: Genau weiß ich nicht, wo der Vorteil von TheCollectiveFX mit etwa 67 $ / 1 Mio. EUR.USD RT (Tier 2 .. 9) bzw. etwa 52 $ / 1 Mio EUR.USD (Tier 10, 11) liegen soll. Damit sind sie nämlich eher teuer. Daß kleine Trader mit Tier 10 und 11 da bevorzugt werden, erscheint auch komisch. Da sind ja selbst die Kommissionen des bestens eingeführten und universellen Brokers Interactive Brokers mit 40 $ / 1 Mio. EUR.USD RT besser, wobei man auf dem Markt auch ohne extreme Mühe noch deutlich billigere Broker findet.

Wie auf der Seite von thecollectivefx.com zu sehen ist, werden keine neuen Accounts angeboten. Das ist bei einem geordneten Geschäftsbetrieb schon ungewöhnlich, da völlig unabhängig von den (angeblich so einzigartigen) Motiven des Clubs, die Gesetze des Kapitalismus Wachstum erfordern, selbst um den aktuellen Status zu halten, denn die Liquiditäts-Provider können ihre Mindest-Umsätze ja jederzeit erhöhen. Beim Abschluß einer Vereinbarung mit thecollectivefx hatten die Liquiditäts-Provider mit Sicherheit auch eigene Motive, wie die Vergrößerung ihrer Umsatzbasis im Auge, die durch ein Schließen für Neuanmeldungen nicht unterstützt werden. Daher steckt da bestimmt ein anderer Grund hinter, der nicht offen kommuniziert wird. Selbst in dem Fall, daß alle bisherigen Trader durch ganz außerordentliche Fähigkeiten dem Liquiditäts-Provider ständige Verluste beschert hätten, wäre die Vergrößerung der Kundenbasis richtig, da irgendwann auch schlechte Trader kommen würden. Ich nehme eher an, daß nach dem längeren Lavieren in einer Grauzone nun endgültig juristisch geklärt ist, daß eine aufsichtsrechtliche Zulassung erforderlich ist. Vielleicht wurde für den bisherigen Kundenstamm eine vorübergehende Konstruktion zur Weiterführung gefunden, z. B. durch Einbeziehung der zulassungsrelevanten Dinge unter das Dach eines geeigneten Haftungsgebers, der aber die Konditionen für die Trader nochmals mit seiner Geschäftspolitik abgleichen will. Vielleicht ist es auch der Beginn des Rückzuges mit noch weiteren Folgen für den bisherigen Kundenstamm. Komisch ist auch, daß man seine Website unter Erzeugung von Kosten renoviert, um sie danach in einer ihrer wichtigsten Funktion, dem Vergrößern der Kundenbasis, partiell stillzulegen. Vollauf überzeugend seriös sieht irgendwie anders aus.

@ siscop In der Hauptaktivität, dem Traden, hat aber keiner was zu verschenken. In jeder Branche gibt eine riesig lange Liste von Gratisangeboten, selbst das Hauptprodukt wird oft als Werbegeschenk angeboten. Trotzdem gibt es als Summe und in Dauer in keiner Branche was umsonst. Das Schreiben im Web oder Bereitstellen von Tools ist genau dann nicht die Hauptaktivität, wenn es dauerhaft gratis geschehen kann. Geschieht es als die Hauptaktivität, kann es beim Zwang zur Finanzierung des Lebensunterhaltes nicht gratis geschehen. Wenn man sich eigene Gedanken zu einer Sache gemacht hat, ist das schriftliche Ausformulieren übrigens auch mit einem großen eigenen Vorteil verbunden, relativ unmißverständlicher Klarheit. Genau aus diesem Grund werden auch im stillen Kämmerlein oder in der Industrie Unmengen von Dokumenten verfaßt, die später kaum jemand liest, die trotzdem nicht nutzlos sind. @ Knochen Für differenzierte Quotestellung gab es schon nachgewiesene Beispiele, wo Leute regelmäßig automatisch erzeugte Screenshots mit OCR (Optical Character Recognition) ausgewertet haben und so sogar Anbieter ohne API-Schnittstelle prüfen konnten. Als Hinweis an alle Java-Cracks sage ich mal, daß die Java-basierten Plattformen ohne offizielle API zumindest zum Auslesen der Kurse über die Java-Debug-API angezapft werden können. Bei Produkten mit offiziellen APIs ist da ja sowieso kein Problem. Die historischen Daten bei einem Reload können auch bei ordentlicher Arbeitsweise von den damals aktuell gesehenen Daten abweichen. Das hängt von der Datenpflege-Politik der Anbieter (z. B. Spike-Korrekturen, die für den Backtest durchaus positiv sind) und der damaligen technischen Übertragungsqualität ab, die auch durch außerhalb des Anbieters liegende Ursachen nicht immer optimal sein muß. @ Krümel Ich denke schon, daß die meisten wirklich guten und aktiven Leute wissen, was sie an Dir haben. Diverse Dauer-Leecher und Rüpel kann man leider nie vermeiden und es ist nur menschlich, sich darüber zu ärgern. Die richtige Frage ist aber, ob sie diesen Ärger überhaupt wert sind.

Ob genau dieses Plugin eingesetzt werden muß, sei dahingestellt, es ist aber sehr wohl exemplarisch für die Durchstechereien der Branche. Mit auch nur einem Minimum an realer Trading-Erfahrung, Beobachtungsgabe und Verständnis der Märkte für ein auch nur annähernd erfolgreiches Trading und insbesondere bei einem nur oberflächlichen Vergleich mit wohlgeordneten Nicht-OTC-Märkten und erst recht bei einer systematischen Auswertung, von denen man im Netz genügend findet oder sie auch leicht einfach selber machen kann, wird man bei der überwiegenden Anzahl der Anbieter, und dabei leider gerade auch einigen der führenden, sehr schnell eines Schlechteren belehrt. Unverbesserlichen Optimisten sei aber definitiv versichert, daß es genügend Gestaltungsspielräume selbst bei einer unter den Augen von Experten stattfindenden Clean-Room-Entwicklung gibt, den Kunden systematisch zu benachteiligen. So ist es wegen der seqentiellen Arbeitsweise von Computern in jedem Fall nötig, die Orders in irgendeiner Reihenfolge auszuführen und das muß auf einem konkreten technischem Equipment erfolgen. Die Festlegung der Order-Bearbeitungs-Reihenfolge kann durchaus auch mit stichhaltigen Begründungen so geschehen, daß sie irgendwer als Nachteil empfinden kann und selbst die einfache Preis-Zeit-Reihenfolge ist nicht gerecht, da sie kleine Orders durch eine einzige größere Order, die vor ihnen liegt, unverhältnismäßig benachteiligt, so daß sie selbst an geregelten Börsen wie z. B. der EUREX bei den Renten-Futures auf recht komplexe Weise modifiziert wird. Weiterhin müssen bei Anbietern mit hoher Auslastung viele unterschiedliche technische Systeme mit unterschiedlicher Leistungsfähigkeit der Komponenten eingesetzt werden, wo der Anspruch auf Gleichbehandlung der Kunden lange nicht soweit geht, daß jedem Kunden das gleiche Equipment zur Abwicklung zusteht und es ökonomisch auch gar nicht möglich ist, tagtäglich das neueste Equipment vorzuhalten. Beim Zusammenbau eines Rechenzentrums wird man auch funktionierende Stränge zusammengehörigen Equipments (Firewalls, Router, Order-Eingangs-Server, Daten-Connection-Server, Datenbank-Server für aktive Orders und für das Logging, Backup-Systeme u. a. m.) nicht auseinanderreißen, so daß sich verschiedene Stränge nicht nur minimal unterscheiden werden, sondern in Summe eher gravierend. Die Entscheidung, wer auf das beste Equipment umziehen darf, ist dem Anbieter völlig willkürlich überlassen. Ansprüche auf Losverfahren oder ähnliches gibt es nicht. Selbst, wenn man durch Beschränkungen einer Jurisdiktion bestimmte Dinge an einem Standort nicht machen darf, kann man sie an für diese Jurisdiktion unerreichbare Standorte mit in genau einer interessierenden Frage laxeren Regeln auslagern, was in einer globalisierten Welt einerseits völlig normal ist und andererseits technisch nicht mehr kostet als ein Anfrage- und ein Antwort-IP-Telegramm mit einer anderen IP-Adresse, statt zum nächsten Rechner in einem Rack des gleichen Rechenzentrums auf die andere Seite der Welt. Bei der Gestaltung solcher Arbeitsabläufe wird sehr genau auf die Einhaltung des Rechtes an allen Standorten geachtet, mit der Ausgestaltung im Ganzen aber sehr wohl oft ein Ziel versucht, welches sich in der formalen Dokumentation der Zieldefinitionen nicht vordergründig wiederfindet. Zur Gewährleistung der formalen technischen, juristischen und ökonomischen Korrektheit werden regelmäßig für Outsider unvorstellbar hohe Summen für ganze Berater- und Prüfer-Stäbe ausgegeben. Projekte, in denen es um viel Geld geht, ziehen durch ihre auch für die externen Dienstleister hohen Budgets dabei durchaus nicht irgendwelche Hinterhof-Buden an, sondern die Besten der Welt. Von denen plaudert auch keiner juristisch verwertbar, wobei auch gerade das mit ein Grund ist, sie zu nehmen. Die Honorarsätze liegen soweit über dem in der eigentlich betroffenen Branche üblichen Niveau, daß es für keinen Beteiligten einen Sinn machen würde, sich da hinaus zu katapultieren und darüber hinaus erfahren selbst innerhalb solch exklusiver Umfelder oft nur einige Entscheider alle Ziele des Projektes bis ins letzte Detail. Die weniger offiziellen Ziele werden dann über den operativen Spielraum im Tagesgeschäft trotzdem sehr stringent umgesetzt. Die in jedem größeren Projekt zu sehenden Spannungen zwischen den Beteiligten resultieren bei Weitem nicht so sehr aus der menschlichen oder fachlichen Inkompetenz der Beteiligten, auf die fast alle Outsider sie schieben, sondern aus knallharten Interessen-Konflikten, die nur mit Mühe unter der Decke zu halten sind. Wer sich zudem bei einem OTC-Anbieter noch eine vernünftige Antwort auf die Frage gibt, wie genau denn dort die Slippage für einen einzelnen Kunden überhaupt zustande kommt (denn sie entsteht selbst bei völlig korrekter Arbeitsweise erst durch eine willentliche und programmierte Vermittlung zwischen dem Markt außerhalb des Anbieters und der Umlage auf seine Kunden), wird sehr schnell bestens verstehen, daß übermäßiges Vertrauen überhaupt nicht angebracht ist und eher aus Naivität herrührt. Da niemand gerne seine eigene Naivität zugibt, sollte der Kontoauszug als Indikator dafür etwas mithelfen. Durch den wieder etwas näher an die Realität geführt, kann man dann ganz sachlich zwischen 100 %-ig eigenen Fehlern und Defiziten des Anbieters differenzieren, beides hat u. a. auch mit Naivität zu tun, einmal der bei der realistischen Erkennung der eigenen Fähigkeiten und zum anderen der beim unangebrachten Vertrauen zum Broker. Die wenigen dauerhaften Gewinner haben an beiden Fronten ihre Hausaufgaben erledigt und werden bei aller inneren Zufriedenheit als Mensch an ihre Trades trotzdem strenge Maßstäbe anlegen, indem sie nicht nur auf die Höhe des objektiven Gewinnes abstellen, sondern auf die Differenz zum bei perfekter Ausführung Machbaren. Wer sich mit zuweilen noch naiveren Vertriebsleuten der Anbieter auf irgendwelchen Messen und Roadshows unterhält, wird natürlich viel Blabla hören. Wirklich Kundige unterhalten sich nicht über das Ob, sondern über das Wie und das Wieviel, bei Kontakt mit den richtigen Leuten bei den Anbietern durchaus auch als qualifizierter Kunde. Wenn qualifizierte Kunden selbst betroffen sind, gelingt es ihnen sogar oft, Kulanz herauszuhandeln, wo andere nur automatisierte Formschreiben sehen, insbesondere wenn sie zudem noch höhere Umsätze machen. Nach einigen Jahren Trading-Erfahrung kann ich nur auf den hohen Nutzen eines guten Kontaktes zu wichtigen Mitarbeitern beim Anbieter hinweisen, denn - das übersehen Anfänger leider völlig - werden trotz aller Computerisierung die wirklich wichtigen Grundsatz-Entscheidungen letztlich von Menschen getroffen. Kunden mit hohen Umsätzen (die auch bei Super-Discount-Konditionen noch regelmäßig mit einigen Hundert EUR pro Tag zum Deckungsbeitrag des Brokers beitragen) sind auch keinesfalls machtlos, sondern werden durchaus umworben. Das Prinzip "verbrannte Erde" richtet sich aber gegen die große Masse kleiner raffgieriger Neunmalkluger, denen einfach nur schnellstmöglich ihre Kohle abgenommen werden soll, bevor sie selber erkennen, daß sie es nicht packen und die noch vorhandenen Reste abziehen.

Das ist eher nur eine Spitze vieler Eisberge. Von unterschiedlicher Quotestellung je nach Kunde und dessen Position über die Priorisierung von Orders, deren Positionen gegen das Haus laufen, bis zur vollständigen statistischen Durchdringung des Handelsverhaltens, daß die Anbieter am Ende viel mehr über Euer Trading wissen als Ihr selber, ist noch vielmehr drin. Zu Verschenken hat in der Branche der maximalen Gier niemand etwas.

@ Mythos Die Idee mit mehreren Brokern sehe ich genauso und ich würde mich auch daran machen, die von Dir angefragte Kommunikation und Synchronisation anzuarbeiten. Da Dir, als mal vermuteter Nicht-C/Windows-Super-Crack aber mit ein paar hingeworfenenen Bemerkungen kaum geholfen ist, muß ich es wohl selber programmieren, wozu ich aber nicht vor Mitte nächster Woche komme. Mir schwebt da eine ganz klare Client-/Server-Lösung vor, bei der auf MT-Seite die Kommunikation über eine recht einfache Client-DLL erfolgt, die 2 Threads benutzt, einen zum Versenden der aktuellen Kurs-Daten dieser MT-Instanz an den Server und einen zum Erhalt von Handels-Anforderungen bei im Server erkannten Arbitrage-Möglichkeiten, vielleicht bei Erfordernis noch einen dritten zum Management. Die Verwaltung aller Kommunikationen, der gelieferten Kurse, der abgeleiteten Handels-Anforderungen und der Zurechnung zu den beteiligten Systemen findet auf dem Server statt, wobei die einfachste Lösung pro angemeldetem MT-System zwei Threads benötigt, die aber bei Nutzung asynchroner I/O auch ggf. auf 2 Kommunikations-Threads für jeweils ein Dutzend angeschlossene MT-Systeme reduziert werden können. Dazu kommt noch ein Management-Thread, ein Thread zur Anmeldung neuer Systeme und bei guter Laune noch einer, der das ganze beobachbar macht, z. B. für eine Web-Site. Für die Kommunikation zwischen der Client-DLL und dem Server nehme ich TCP/IP-Sockets, womit das ganze auch sofort Internet-fähig ist und nicht auf lokale Windows-Systeme beschränkt ist. Gut finde ich, daß Du Dich jetzt dem inhaltlichen Problem der fehlenden Trade-Synchronisation (insbesondere bei Nicht-Zustandekommen der Gegenseite eines Trades) näherst, denn da ist einiges an fachlichen Ideen nötig, um nicht durch einen einzigen Ausfall einen riesigen Verlust zu erleiden. Die Verfolgung beauftragter und offener Trades sollte man nicht von der optischen Auffasssung abhängig machen, sondern streng algorithmisch im Server-Modul. Die muß ja nur inhaltlich richtig sein, nicht aber auf Anhieb zu überschauen. Die erste Phase der Nutzung sollte aber die Nutzung des Systems zur Ermittlung der Kurs-Stellungs-Schwankungen im Tagesverlauf sein, um sinnvolle Zeiträume für den Ausgleich der Differenzen zu haben, denn wegen der fehlenden Transferierbarkeit der Assets muß die Position ja beim gleichen Dienstleister auch irgendwann wieder glattgestellt werden. Ebenso könnte man außerhalb der eigentlichen Arbitrage-Funktion mal prüfen, ob die Anbieter unterschiedliche Kurse stellen je nach bereits eingegangener Position, so etwa flat xx50 - xx52, short xx52 - xx54, long xx48 - xx50 und wie lange sie das bei Nachkäufen aufrecht erhalten. Bei aller Aufgeschlossenheit bei der programmtechnischen Umsetzung, gehe ich immer noch davon aus, daß nach allen Transaktionskosten keine dauerhafte Gewinnerzielung möglich sein wird. Weiterhin wirft spätestens das Zusammenschalten von Systemen verschiedener Nutzer einige juristische Probleme auf und selbst das Zusammenschalten von Systemen des gleichen Nutzers wird durch die AGB der Anbieter (wenngleich höchstwahrscheinlich juristisch unwirksam) meistens ausgeschlossen.

@ Mythos Ja, etwas Aufwand muß man für eine richtig programmierte Synchronisation schon treiben. Der ist aber zwingend notwendig, weil sonst in einem längeren Einsatz-Zeitraum andauernd undefinierte Zustände auftreten. Die Plump-Methode ist übrigens die manuelle Anlage eines leeren Lock-Files zum Lesen und Schreiben als Synchronisations-Hilfsmittel. Ein Prozeß darf dann nur etwas mit den derart manuell geschützten Daten machen (Lesen oder Schreiben), wenn er das File geöffnet bekommt. Ansonsten hat es gerade der andere Prozeß geöffnet und beansprucht den Zugriff auf die Daten. Leider muß man dabei auch pollen (= beschäftigt warten, in einer Schleife mit Sleep() wieder und wieder prüfen), was man neben anderem mit den Betriebssystem-Funktionen vermeiden will. Auf Sleep() kann man sich so genau nie verlassen. Normalerweise sollte man mittels Synchronisations-Funktionen oder Callback-Events punktgenau synchronisieren. Auch wenn Programmierer oft "auf die Schnelle" Sleep() benutzen, stimmt, wo im Near-Realtime-Bereich mit Sleep() (& Co. in anderen Umgebungen) hantiert wird, meistens etwas nicht mit der richtigen Nutzung eines ordentlichen Synchronisations-Protokolles und führt zu oft kaum nachvollziehbaren und teils nur schwer wiederholbaren Effekten. Bei Sleep() sollte immer mit einer größeren systematischen Ungenauigkeit gerechnet werden. Sleep() ist nicht für die harte Realtime-Programmierung gedacht, sondern für die Wiederholung vormals wegen mangelnder Ressourcen-Verfügbarkeit blockierter Operationen, wie History-Einlesen oder Order-Ausführungen. Dafür reicht es, für Realtime-Zeit-Messungen nicht. Die können mit den speziellen High-Resolution-Timern bei den Timer-Funktionen des Betriebssystems ausgeführt werden. Eine genauere Auflösung von Timern, die Aktionen auslösen macht in der Struktur von Windows auch keinen Sinn, da durch die minimal an einen Prozeß vergebenen Zeitscheiben und die Unmengen von der Hardware ausgelösten höher priorisierten Interrupt-Anforderungen eine solche Genauigkeit nicht durchgesetzt werden kann, im Gegensatz zur nachträglichen Messung.

@ Mythos Echte Blockaden (vollständige Verklemmungen) gibt es nicht, solange jeder Prozeß nur in sein(en) File/Datenbereich schreibt und der andere dort nur liest. Dazu ist die einzig nötige Synchronisation der Ausschluß eines gleichzeitigen Lese- und Schreibzugriffs. Dazu dienen bei Microsoft die Synchronization Functions. Dabei kann es nur eine Wartezeit bis zur Beendigung des Schreibens, aber bei Nutzung mehrerer Files keine Blockade geben, die aber (abzüglich des minimalen Overheads für die Prozeß-Umschaltung) auch ohne IPC (Inter process communication) nötig gewesen wäre. Wenn ein blockierendes Lesen innerhalb eines Threads erlaubt ist, kommt man bzgl. des Lesens und Schreibens sogar ganz ohne explizite Synchronisation im User-Code aus, wenn Sockets oder Named-Pipes und darauf aufbauende höher abstrahierende Mechanismen wie z. B. Mailslots oder Message Queuing genutzt werden. (Die Variablen, die die Inhalte für den Hauptthread festhalten, müssen aber gegenüber dem empfangenden Thread immer noch synchronisisert werden, wobei es dann aber sogar eine einfache Crical Section mit dem geringsten Overhead tut.) Damit kann man sich sogar mit einem entfernten MT oder gar einem eigens geschaffenen Arbitrage-Pool-Server (vorher bezüglich der rechtlichen Implikationen genau die AGB des MT-Anbieters lesen und ggf. von einem Juristen auf die Wirksamkeit prüfen lassen!) koppeln. Mit ein wenig Wrapper-Code kann man mit den ganz normalen File-I/O-Funktionen der C-Standard-Bibliothek schreiben/lesen und kriegt den IPC-Mechanismus oft auch ziemlich transparent hin.

@ siscop Post 36 <{POST_SNAPBACK}> ist die typische Antwort eines Programmierers, der auch Dinge aufwendig programmiert, die in der Sache wegen des ökonomischen Grundsatzes TANSTAAFL schon von Vornherein im Grenzbereich liegen. Natürlich arbeitet Arbitrage gerade im Kernbereich von TANSTAAFL (schließlich ist Arbitrage gerade er Prozeß, der den Grundsatz erst Realität werden läßt), aber es sollte sich jeder gute Programmierer fragen, ob bei den Anbietern jedweder Finanz-Dienstleistungen nicht ebenso sehr gutes Programmier-Know-How gepaart mit ebenso gutem ökonomischen Know-How und massiven Ressourcen (ggf. bei ihren IT-Dienstleistern) zusammenkommt. Weiterhin gehört die Vermeidung von Arbitrage-Möglichkeiten geradezu zu den panischen Urängsten von Finanz-Dienstleistern, da sie bei kompetenter Umsetzung sowohl blitzartig schnell als auch als dauerhaftes kleines Leck große systematische Verluste erzeugen kann und vielfach auch von potenten Gegenspielern vorgenommen wird (inklusive aller möglichen spieltheoretischen Strategie-Mixe, um nicht vorschnell erkannt zu werden). Das sollte jetzt keine generelle Kritik an Programmierern sein (zumal ich selber sowohl Informatik als auch BWL studiert habe). IT-Leute sind in der Umsetzung sicher kompetent und bei ausreichender Motivation auch rasend schnell. Unzureichende Beachtung von Zusammenhängen in den (ihnen eher nicht so naheliegenden) bearbeiteten Fachgebieten führt aber häufig zu vermeidbaren Aufwendungen, die bei vorheriger vollständiger fachlicher Analyse zumindest deutlich zu reduzieren gewesen wären. Die Annahme der Möglichkeit des "Auseinandernehmens" einer Finanz-Institution durch einen Hobby-Programmierer löst bei mir bei aller Wertschätzung an der Programmier-Arbeit und den auch wirklich vorhandenen riesigen Möglichkeiten Einzelner bei konsequenter Anwendung der heutigen hochentwickelten technischen und ökonomischen Strukturen (inkl. der leichten kurzfristigen Verfügbarkeit umfassendster Ressourcen auf dem technischen und personellen Sektor) doch eher den Eindruck von übermäßigem Optimismus bis auch weitergehendem Erstaunen aus. Zuweilen stellt das intensive Arbeiten in einem Bereich, den man gut beherrscht, auch das Vermeiden von Arbeiten in Bereichen dar, wo der eigentliche Handlungsbedarf besteht, die man aber aus irgendwelchen Gründen nicht so gerne anpackt. Klar hat das Abziehen einer tollen Arbitrage-Nummer riesigen Charme und zuweilen gibt es dafür sogar unglaublich erfolgreiche Beispiele, aber die gibt es beim Sechser im Lotto auch fast jede Woche. Das eklig harte Arbeiten an den kleinen Edges im Trading, die schon viel mit harter Arbeit zu tun haben, hat diesen Charme nicht. Im Berater-Jargon nennt man dieses hobby-mäßige Arbeiten an den Lieblingskindern zeitweise nicht zielorientiert geführter Fachleute "Jugend forscht", ganz ohne Häme/Überschätzung bezüglich Berater, Hobby, Lieblings-Präferenzen, Zielorientierung, Fachleuten, Jugend und Forschung. Der Ökonom würde vor der Bewilligung auch nur einer Personen-Minute, eines Cents oder jeder anderen Ressource (teils schon vollautomatisch im Unterbewußten) unter anderem fragen: Warum bin gerade ich als Erster auf diese vermeintlich brilliante Idee gekommen? Warum werde ich damit konkurrenzlos sein/bleiben? Warum sollte sich der kompetente Opponent dagegen nicht schon vorab geschützt haben? Wie schnell wird es dauern, bis der Opponent die Nachteiligkeit erkennt und er sich dagegen schützt? Was könnte eine grobe Abweichung zwischen den theoretisch erreichbaren Resultaten mit der Realität bewirken?

// ----- Daten-Pool ---- struct DataPool // in C, not MQL { TYPE1 data1 ; TYPE2 data2 ; ... } DataPool // static , * PtrDataPool1 = (struct DataPool *) malloc // stdlib.h (sizeof(struct DataPool)) , * PtrDataPool2 = (struct DataPool *) VirtualAlloc // Win API (NULL, sizeof(struct DataPool), MEM_COMMIT, PAGE_READWRITE) ; // ----- Pointer umrechnen (wozu eigentlich?) --- struct DataPool * ptr1 , * ptr2 = (struct DataPool *)((char *) ptr1 - OFFSET) ; // ----- Es geht ja direkt ----- ptr1->... ...; ptr2->... ...;Das Memory-Mapping der Adress-Räume von Files wird z. B. in Microsofts MSDN mit folgendem Beispiel-Code beschrieben. Als Nebeneffekt kann man sich auch noch das explizite Lesen und Scheiben von Files und Ein- und Auslesen in die einzelnen Variablen sparen und hat so insbesondere bei großen Datenmengen oder komplizierten Datenstrukturen eine Beschleunigung beim Arbeits-Beginn und -Ende. Langsamer wird bei dieser Vorgehensweise gegenüber einem sonstigen direkten Speicherzugriff gar nichts (Overhead nach erfolgtem Mappen ist genau 0), da es keine fortlaufenden Zugriffe auf das Filesystem gibt, die Verzeichnissuche, Virenprüfung etc. anstoßen, das File gehört während des Mappings direkt zum Speicherbereich des Prozesses. Ansonsten wird eine Lösung, die remote über das Internet über zig dazwischen liegende Systeme angebunden ist, ohnehin nicht profitabel funktionieren, wenn sie wegen einiger Millisekunden lokaler Aktivitäten in einen Nachteil kommen sollte, da die externen Systeme in Summe größenordnungsmäßig mehr Zeit brauchen. Ohne Nutzung von Memory-Mappings ergibt sich die größte Zeitseinsparung durch permanentes Offenhalten und Neupositionieren offener Files gegenüber vielfachem Öffnen und Schließen, da dabei der Overhead sehr groß ist und in vielen System-Konfigurationen ein Realtime-Virencheck stattfindet. Die APIs dazu sind bei Microsoft in Memory Management Functions und File Management Functions und bei vollständiger Installation der IDE auch im lokal installierten Help-File beschrieben. Zugriffsfunktionen (get-..., set-...) sind selber zu schreiben und dienen zur Abstraktion der Details der Daten-Darstellung und verbergen vor MQL die Dinge, die dort nicht unterstützt sind. TYPE1 getData1() { return DataPool.data1; } // so gibt es Zugriffe auf beliebige Nicht-MQL-Daten-Elemente.Das kann beliebig erweitert werden, für Arrays, selbstgebaute assoziative Array mit Zugriff über einen String-Key und vermischte Typen usw., um nicht für jede Anwendung immer neu im Quelltext rumstochern zu müssen.