Mythos

Die erste Frage die sich aufdrängt: mit welchem Master wurde gestestet? ich hab die aktuellste Version "analysiert", die alte Version hat noch einen Bug. Und dann kommt der Debugoutput an die Tagesordnung. Print-Statements in die Vergleichsschleife, die alle nötigen Infos ausgibt, und das ganze im visuellen Modus testen. bzw. liefert eine visuelle überprüfung welche trades unterschiedlich sind vielleicht schon erkenntnisse. Wurde mit Unique= true getestet? Wenn ja: wie sieht es bei false aus. Oder hängt es möglicherweise an der einlesfunktion und er liest nur die ersten 2 subsysteme ein? Also die Analysemöglichkeiten sind noch lang nicht erschöpft, jetzt fangt es erst an spannend werden ;) Jetzt kommen die 80% der Arbeitszeit, die beim Systementwickeln immer so lästig sind *ggg*

Wie kommst du zu der Vermutung? aufgrund von Tests oder Analyse des Source Codes? Da es sicher viele Mitleser freuen wird, gehen wir einfach mal Schritt für Schritt die entsprechende Funktion durch, vielleicht finden wir ja den Fehler. [ 1]int getDirection() [ 2]{ [ 3] int index=0,direction=0; [ 4] double current_best=0,slope=0,last_slope=0,roc=0,comp=0; [ 5] bool got_one= false; [ 6] [ 7] for(index= 0;index < ArraySize(systems_);index++) [ 8] { [ 9] slope= iCustom(Symbol(),Period(),systems_[index],RegressionPeriod,AveragePeriod,0,0); [10] if(ROC_Period == 0) [11] roc= slope; [12] else [13] { [14] last_slope=iCustom(Symbol(),Period(),systems_[index],RegressionPeriod, AveragePeriod,0,ROC_Period); [15] if(last_slope != 0) [16] roc= slope/last_slope-1; [17] else [18] roc= 0; [19] } [20] [21] if(CompareSlope) [22] comp= slope; [23] else [24] comp= roc; [25] [26] if(roc > 0 && comp > 0 && got_one && Unique) [27] return(0); [28] [29] if(roc > 0 && comp > current_best) [30] { [31] got_one= true; [32] current_best= comp; [33] if(iCustom(Symbol(),Period(),systems_[index],RegressionPeriod,AveragePeriod,1,0) > 0) [34] direction= 1; [35] else if(iCustom(Symbol(),Period(),systems_[index],RegressionPeriod,AveragePeriod,1,0) < 0) [36] direction= -1; [37] else [38] direction= 0; [39] } [30] } [41] return(direction); [42]} got_one hat die Aufgabe, sich zu merken ob bereits ein System mit Gewinn (im Sinne wie wir es definieren) gefunden wurde oder nicht. Da man wählen kann ob man die Steigung der RegLine vergleicht, oder die ROC der STeigung der RegLine, übernimmt die temporäre Variable "comp" die Aufgabe des zwischenspeicherns. roc= ROC der RegSlope sofern diese sinnvoll definiert ist (slope von vor ROC_Period bars > 0) current_best ist unsere erinnerung, was der bisher beste Wert von comp war, da wir für Gewinn "comp > 0" vorraussetzen, merken wir uns nur dinge die größer als 0 sind, also beginnt current_best bei 0. die for-schleife die in [7] beginnt läuft über den gesamten Rest der Funktion, alles danach passiert also für jedes subsystem, außer wir brechen vorher ab. [9]... wir holen uns den RegSlope aus dem System [10]-[19] wir berechnen die roc des RegSlope. [21]-[24] wie oben erwähnt: comp wird entsprechend gesetzt, d.h. ab jetzt hat slope, roc und comp die Werte für das aktuelle system. [26]-[27] hier kommt die frage nach dem Unique: Unique bedeutet: "Es herrscht ein Signal für den Master, wenn genau 1 System gewinn macht" "Gewinn machen" ist definiert als: positive ROC (also die performancekurve steigt) und positive (slope oder roc, je nach parameter) Wenn jetzt "got_one" true ist, es also bereits ein system mit gewinn gibt, und Unique aktiv ist und das aktuelle system gewinn macht, dann bricht die Funktion ab und gibt 0 retour, was für den Master bedeutet "tu nix" bzw. flat. [29]: current_best speichert den bisher besten Wert von comp der gefunden wurde. (bzw. bleibt 0 wenn es keine werte > 0 gibt) hier wird also abgefragt "Gewinn und besser als alles was bisher betrachtet wurde". Ist die Antwort "ja" so speichern wir uns in [33] - [39] die aktuelle Richtung des Systems in die Variable direction und merken uns mit [31] das wir ein System mit Gewinn haben, und mit [32] den comp-Wert von diesem System Danach beginnt der nächste Schleifendurchlauf und wir machen alles fürs nächste System. In [41] wird nun die gespeicherte Richtung retouniert, sofern nicht vorher irgendwann in [27] abgebrochen wurde. Nach meinem Verständniss, wird also jedes System betrachtet und die Richtung des besten gewinnt. Wo die Reihenfolge eine Rolle spielt, ist wenn 2 Systeme die gleichen Werte für comp aufweisen aber unterschiedliche Marketpositionen haben, dann gewinnt das erste System. Aber diese Sensitivität gegenüber der Reihenfolge kriegt man nicht weg. Wenn man Unique= false setzt, seh ich bei gleichen Subsystemen, nicht wie es zu unterschiedlichen Ergebnissen bei unterschiedlicher Reihenfolge kommt. Sicher das alle restlichen "Umgebungsvariablen" gleich sind?

Überprüf mal die Einstellungen vom EA, du solltest Life Trading zulassen, aber die Checkbox für "manuell bestätigen" sollte nicht angehackt sein, sonst fragt er dich jedesmal ob du das wirklich willst.

ganz großes DANKE für den detailierten Einblick! Du bestätigst viele meiner Vermutungen und "Erfahrungen".

Natürlich, bei entsprechender Liquidität des Marktes muss die Order schon sehr groß sein, um wirklich was zu bewirken. Was ich eigentlich nur sagen wollte ist, das eine Buy Order nicht verantwortlich ist das der Kurs nach unten geht oder? Aus deiner Formulierung klingt es wieder so als würden die LimitBuys darunter den Kurs weiter nach unten ziehen... Nochmal langsam für mich zum mitschreiben: Kann (und wenn wie?) eine LimitBuy Order den Kurs nach unten bewegen (also unter das aktuelle Ask)?

Ich geb dir wohl Recht was den fairsten Preis etc. angeht, die Börse setzt den Preis so fest das möglichst viel gehandelt wird und sie somit möglichst viele Gebühren einnimmt. Und sehr große Orders haben natürlich Einfluss auf den Markt (genauso wie sehr viele kleine Orders gleichzeitig). Nur hat jede Order je nachdem auf welcher Seite eine andere Auswirkung. Wenn ich mich nicht total vertue, ändert eine große Buy-Order unter dem aktuellen Bid zwar das Gesamtverhältniss zwischen Kauf und Verkaufsaufträgen, hat aber genausowenig sofortigen Einfluss auf den Markt wie eine große LimitSell über dem aktuellen Ask. Eine große LimitBuy würde vielmehr (kurzfristig) verhindern das der Kurs unter dieses Limit fällt, da sich erstmal genug Verkäufer finden müssen, die diese Order füllen bevor der Kurs weiterfällt. Oder steh ich gerade total auf der Leitung?

Das musst du mir jetzt genauer erklären, wie können große Buy-Orders den Markt nach unten reißen? Ich hab ja schon einige Varianten getestet wie man den Markt manipulieren und damit Geld machen kann (nicht mit realem Geld und nur unter bestimmten "Vorraussetzungen" versteht sich ;), aber mit großen Buys stützt (bei Limit Buy) oder schießt man den Markt kurzfristig nach oben (bei Market Buy) oder? Hier dürfte eher was großes mit einer MarketSell Stops gefischt haben und hat sich dann auf der ausgelösten Panik nach unten wieder zurück gekauft. (Der 20 Punkte Move zurück nach oben ist ja ein schöner Bounce ;)

Auch von mir ein ganze herzliches "Servus". Also ich bin sicher nicht böse wenn du bei Begriffen etc. nachfragst (ich weiß oft selber nicht wovon ich rede ;), und die ganzen stillen Leser (an die auch mal ein "Servus" *G*) freuen sich sicher! bzgl Anfänger: falls du mal in das feeling von realem traden reinschnuppern willst, ohne dabei echtes Geld zu riskieren, kannst du ja mal beim Beta-Test von Kiwee reinschauen. *ganz unverhohlen Werbung vor der offiziellen Bekanntgabe mach*

Erst das Herz für arme Mathematiker, und jetzt ein gnädiges nicken... Die Woche ist gerettet!

Naja Point is schon "wichtig"... gleich wichtig wie Bid,Ask, Stoplevel, Spread etc... (vor allem weil die letzten zwei in Point angegeben sind;) Ok, es ist ein Skalierungsfaktor, aber die können ja auch wichtig sein... F1 hilft hier wiedermal sehr: "The current symbol point value in the quote currency." Bei EURUSD hast du zB meist Point = 0.0001. Es ist ratsam "absolute" Parameter, wie in diesem Fall die TP-Differenz, in Points eingeben zu lassen, da du damit einen Symbolunabhängigen Fixpunkt hast. hth

stimmt, es gab einen kleinen Bug in Zusammenhang mit dem Unique. Das Problem sollte nur auftreten wenn Unique auf true gesetzt ist (was ich persönlich nicht für sinnvoll halte). hier eine neue Version (geändert haben sich nur 2(4) Zeilen in der FUnktion getDirection()): eSystemOfSystems.mq4 Nochmal zur Erinnerung an alle mitleser: Dieses SystemOfSystems is bewusst sehr allgemein gehalten, es kann also mit beliebigen subsystemen verwendet werden, wenn diese als indikatoren vorliegen, nur 2 Parameter nehmen (RegressionPeriod und AveragePeriod) und als 1. (Line 0) Linie den Regressionslope und als 2. (Line 1) Linie die aktuelle Position liefern. Mehrere Parameter der Subsysteme müssten hardcoded oder per config-file gehandelt werden. mfg

Ich wusste doch ich hab die Reihenfolge der Zahlen falsch... es war schon ARIMA, die 0 ist der AR Anteil (weiß nicht mehr ob das q oder p war). also die 1. Differenz ist eine zufällige Störung. TU Graz. inzwischen im 10. Semester... .... (ich sag ja da laufen die leute alle weg ;) Hm, man könnte doch die durchschnittliche Länge der Phase, an die Steigung der RegLine anpassen oder? Sodass man bei starken Bewegungen schnellere Wechsel erwartet. zu den langen Trends: Ich würde X gar nicht direkt in das System als solches einspielen, sondern eher indirekt. Sprich wir "merken" uns zwar X, aber verwenden es nur, um Y und Z zu bestimmen. Wenn jetzt ein langer Trend ist, dann liefert die RegSlope durchgehend diese Trendkomponente. Ich lass mich auch gern von anderen Grundannahmen überzeugen, ich vermute nur, das wir welche treffen müssen. Und sie sollten sehr basic sein, weil wir ja nichts wirklich wissen... Zu den kurzen Sprüngen: Ich denke es ist schwer mit einem statistischen System schnelle Bewegungen zu traden, wenn man versucht die aktuelle Marktsituation zu traden. Denn da hat man mMn nicht genügend Daten um signifikante Aussagen zu treffen. Um so kurze Bewegungen zu traden, müsste man sie eher vorhersagen (also Marktphasenwechsel). Sprich in unserem System würden so kurze Bewegungen einfach nicht getraded werden, da dann die letzten Z Bars nicht mit den letzten Y zusammenpassen und das Sys damit flat bleibt. Ich denk wir würden hier nur die "durchschnittlichen" Bewegungen handeln, und nicht die außergewöhnlichen. Natürlich, ich schreib nur gern dazu wenns nur eine unausgereifte Idee ist, sonst denkt noch jemand ich wüsste wovon ich rede (Mathematikerkrankheit ;)

Full ACK!

is ja nur ein kleines kunststoffpfählchen.. außerdem wars ja nur ein Wink ;) und überhaupt: EDIT: ging ja richtig high-speed. Danke! EDIT 2: und jetzt sind sie weg... und mein post steht da wie bestellt und nicht abgeholt

Ich antworte jetzt einfach trotzdem hier, und hoffe das whipsaw oder krümel den mathematischen Teil in einen eigenen Thread schnippseln müsst jetzt meine Mitschrift rauskramen, aber ARMA unterscheidet sich von ARIMA ja dadurch, das bei ARIMA Eigenwerte Aber nich so wichtig, wollt eigentlich eh nur sagen, das statistisch gesehen, bei meinen derzeitigen Möglichkeiten die beste Erklärung für den Kurs ein random-walk ist... was ja jetzt nit optimal für Prediction ist... :( Bin jetzt auch kein Fachmann in Statistik (vor allem nicht wenns um die höhere Statistik geht, aber ich glaub man kann hier schon mit den Basics einiges versuchen ala KISS. Auf alle Fälle erhöht es sicher das Verständniss des Marktes ;) und seit ich Mathe studier hab ich mich dran gewöhnt das die Leute plötzlich weglaufen anfangen sobald man mit den Themen anfängt... Zur Idee: Wir müssen sicher mal Grundlegende Annahmen treffen, die man dann ja als "Parameter" im System haben kann, und möglicherweise mehrere Varianten gleichzeitig laufen lässt. Ideen für so Grundannahmen meinerseits: * Die Marktphasen ändern sich i.A. kontinuierlich * Der Markt bleibt im Mittel X Bars(Minuten,Stunden) in ca. der gleichen Marktphase (das könnte man im laufenden Betrieb immer aktualisieren) Dann wär mein erster Ansatz eine LinREg auf die letzten Y Bars (Y bei slope ~ 0: geschätzte Stdabw als Kanal traden bei |slope| > 0 : die geschätzte stdabw. des Kanals in Trendrichtung traden. Den Hypothesentest könnte man dann noch insofern einbauen, als das man die von den Y Bars geschätzten Werte, auf die letzten Z (mit Z Flat. MM und RM muss man dann halt anpassen. wie immer nur mal so als "in den Raum gestellte Idee". *mit dem Zaunpfal nach Krümel winkt*

Jein, es geht mir eigentlich gerade nur darum (gemeinsam) Antworten zu finden, wie die Aussehen ist sekundär. @stationär: Ich hab mal den DAX ein bissl analysiert was das angeht (bin nicht wirklich Experte im Gebiet Zeitreihenanalyse, aber interessiert hats mich halt) und der ist leider nicht stationär (ich weiß da braucht man nicht viel analyse dazu ;). Aber das "Hauptproblem" was bei meiner Analyse herausgekommen is: am besten würde ein ARIMA(1,0,1) (ich glaub das wars) fitten wobei die Varianz des Störterms nicht exakt konstant wär... Sprich Q_t = mu_t + eps_t, wobei mu_t = mu_{t-1} + delta_t mit eps und delta zufällig gestört (i mag die Formulierung ;) mit Erwartungswert = 0 und Varianz= ? (nicht konstant) Die große Frage ist natürlich das "Was ist Q_t?", aber wie du schon sagst: Es würd uns ja auch reichen es hinreichend zu approximieren, wenn wir wüssten das die approx stimmt ;) kurze Idee: man könnte doch versuchen 2-3 "Modelle" für den Markt zu entwickeln (Trendkanal, Seitwärtskanal etc.). Unter der Annahme das diese Modelle korrekt sind, kann man dann wiederum eine Strategie rausrechnen, die einem einen positiven Erwartungswert liefert. Gleichzeitig müsste es doch möglich sein einen Hypothesentest zu formulieren, der uns genau testet ob wir die Annahme momentan verwerfen müssen. Entscheiden sich die Tests signifikant für eine Annahme, so traded man diese strategie, bis der Test sagt "nicht mehr erfüllt". Dabei wählt man die Signifikanzniveaus recht strikt, nach dem Motto "Qualität vor Quantität". Wie gesagt nur so eine kleine Idee, die mir grad durch den Kopf geschossen ist. hmm...langsam hat das nix mehr mit Pyramiden zu tun... ich seh schon whipsaw mit der schere anrauschen...

Richtig vermutet. OrdersTotal() ist eine built-in function. Die Funktionsweise wird in der Hilfe von MT genau beschrieben (Funktionsnamen markieren und F1 drücken bringt dich direkt dorthin). Nein, das sind alle offenen Orders von diesem Account. Es gibt auch noch OrdersHistoryTotal(), das sind alle geschlossenen Orders. Du kannst beliebig viele EAs am gleichen Symbol und auch Timeframe laufen haben. Um die Orders jedoch zu den einzelnen EAs zuordnen zu können gibt es OrderSymbol() und OrderMagicNumber(). OrderSymbol() sagt dir von welchem Symbol diese Order ist. Die MagicNumber, ist eine beliebige Nummer, die du der Order beim erstellen mitgeben kannst und die sie dann dauerhaft behält. Wenn jetzt jeder deiner EAs seinen Orders eine andere Magicnumber gibt, kannst du mithilfe von Symbol und Magicnumber eindeutig entscheiden ob diese Order nun zu deinem EA gehört oder nicht. Ich codiere meist zur Laufzeit noch zusätzlich den aktuellen Timeframe in die MagicNumber dazu, wodurch es möglich ist den gleichen EA am gleichen Symbol aber in unterschiedlichen Timeframes laufen zu lassen, ohne das sie sich gegenseitig in die Quere kommen. zb so: #define MAGIC_NUMBER 1230000 int magic = MAGIC_NUMBER + Period(); Stoploss und Takeprofit wie du das hier vielleicht meinst, ist in MT keine eigene Order, sondern vielmehr eine Eigenschaft einer Order. Sprich du hast dann 1 Longorder mit SL und TP. Keine eigenständige Shortorder dazu. Wenn du eine Longorder schließen willst, bringt es dir bei MT auch nichts, wenn du eine gleich große Short eröffnest. Dann hast du nur 2 Orders die sich gegenseitig hedgen. Es wird auch keine Order "automatisch" (also Serverseitig) erstellt (als SToploss oder so). OrdersTotal() wird also nur größer, wenn du selber einen OrderSend Befehl schickst. (und kleiner, wenn bei einer Order SL oder TP geht, oder du eine Order mit OrderClose() schließt) (Das alles gilt nur in der Theorie, ich hab schon von Brokern gehört die über Nacht Hedgingpositionen gegeneinander aufrechnen und somit schließen. Ist natürlich nicht nett, da der EA damit "vergisst" das er ja eigentlich im Markt war.) hth PS: Nur nicht abschrecken lassen weil du der einzige Fragensteller bist, es lesen sicher sehr viele mit, die nicht wissen was oder wie sie fragen sollen und sich sehr freuen das du fragst.

Sorry, hab mich glaub ich falsch ausgedrückt. was ich eigentlich meinte: Geg: stoch. Prozess Q_t, Zufallsvariablen X und Y, Einstiegszeitpunkt s, Ausstiegszeitpunkt t, maximale Positionsgröße m und ein n mit n|m die teilpositionen. X sei jetzt der Gewinn wenn ich einfach bei s voll kaufe und bei t verkaufe. Erwarteter Gewinn wär also E(X)= E((Q_t-Q_s)*m) ... (ohne Gebühren, usw... ) Y sei jetzt der Gewinn, wenn ich bei s mit n Positionen einsteige, und dann bis zum Zeitpunkt t in jedem Zeitschritt r(ganz vergessen: Q_t is natürlich diskret) folgendes macht: Q_{r} >= Q_{r-1} und Gesamtpositionsgröße Zum Zeitpunkt t wird dann die gesamte aufgelaufene Position wieder verkauft. Die Frage: Unter welchen Bedingungen ist E(X) Klar, deswegen auch der Erwartungswert oder? Wenns wirklich mathematisch wird, fang ich meist eh automatisch an TeX zu tippen ;) lg

Erstmal willkommen im Forum jfc Hab grad leider keinen Zugriff auf das Buch, deswegen frag ich dich direkt: Die Gewinnerwartung (also Erwartungswert vom Gewinn) bleibt nur gleich wenn du "nicht weißt" wie sich der Kurs während dem Nachkauf/pyramidisieren verhält oder? Habs mir nicht durchgerechnet (da ich auch nicht genau weiß welches Setting ich verwenden will/soll) aber rein gefühlsmäßig: Wenn ich die Annahme treffe (was in der Praxis ja stimmt) das sich der Kurs bewegt während ich nachkaufe (also zb alle 5 Minuten eine Aufstockung, dazwischen beobachte ich den Kurs) und ich nur nachkaufe wenns im Zeitraum davor nach oben gegangen ist. Dann müsste sich der Erwartungswert des Gewinns unterscheiden vom Erwartungswert wenn ich alles auf einmal kaufe. (Wenn wir sagen wir kaufen in Summe immer gleich viel, und verkaufen zu einem fixen Zeitpunkt später.) Wie gesagt, ich habs mir nicht durchgerechnet, wär aber mal interessant, unter welchen Annahmen Pyramidisieren einen Vorteil bringt. (und ob es überhaupt einen Vorteil bringt). btw: du erwähnst den Begriff Pyramidisieren im Zusammenhang mit Spieltheorie. Da es hier ja eigentlich um die Frage "was ist Pyramidisieren" gegangen ist, und inzwischen ein paar Unterschiedliche Definitionen aufgetaucht sind. Könntest du kurz beschreiben was man unter Pyramidisieren in der Spieltheorie versteht? @whipsaw: sorry wenns zu mathematisch wird, aber ich glaub es kann sehr interessant sein, wie die Gewinnerwartungen sich theoretisch ändern bei so Dingen wie pyramidisieren. Trader leben im Prinzip ja nur vom Erwartungswert

sollte eigentlich nicht sein, da jeder Indikator ja für sich abgeschlossen ist. Und auch die TB von jedem aufrufenden Modul als eigenständige Instanz aufgerufen wird (werden sollte). Ich kann das Verhalten hier auch leider nicht reproduzieren (wenn ich den RSI 2 mal unter verschiedenen Namen mit unterschiedlichen Parameter laufen lassen, funkt alles wie es soll...) habt ihr mal versucht das ganze "schrittweise" zu machen? also den "geheimen" Teil wegzulassen und schaun ob die Probleme dann immer noch bestehen... Ohne Code bzw. "Testfall" ist es schwer zu sagen was falsch sein könnte, weil das theoretisch vom Programmierfehler bis zu einem MT-Bug gehen kann... (MT zeigt ja bei einem solchen Indi teils sehr interessantes verhalten)

jein, du musst unterscheiden zwischen Reihenfolge im Code und Programmablauf. In MQL ist es egal wo im Code eine Funktion "erklärt" (definiert) wird. Wenn irgendwo im Code die Funktion aufgerufen wird, springt der Programmablauf an die Stelle wo die Funktion steht und führt diese Zeilen aus bis zum return, dann springt er zurück. Und das "wohin springen" findet der Compiler beim kompilieren raus. Das ist auf alle Fälle das, was dieser Codeblock tut. Bei einem EA ist das "was er tut" und das "was er tun sollte" bzw. "ob die kommentare dazupassen" nicht immer das gleiche ;) Zu den sachen die man abchecken sollte: das kann ma so jetzt schwer sagen, hängt ganz vom EA ab. Du solltest auf alle Fälle immer über den aktuellen Status deiner Orders informiert sein. (falls du sowas meinst)

So ungefähr (nur nicht so schön formuliert) hätt ich mir das auch gedacht gehabt. hat aber den effekt, das der aktuelle Bid bei 900 steht, der aktuelle Ask bei 950, man aber dennoch bei 1000 ausgeführt wird, und wenn der LimitSell größer war, danach der Ask immer noch bei 950 stehen würde... was von Käuferseite doch auch irgendwie seltsam wäre... vor allem ohne Level2

Ich glaub das genau in die Richtung der Frage die ich mir gestellt hab. Aber bei der EUREX scheint es umgekehrt zu sein. Wenn 2 Orders zum gleichen Preis vorhanden sind, gilt "first come first serve". geht es aber darum wer den "für sich besseren Preis kriegt" wird die neueste (also eben eingestellte) Order bevorzugt. Dieses Verhalten sorgt auf alle fälle für mehr volatilität.

so abstrakt is es gar nicht, bei kiwee kommts regelmäßig vor... gefillt wird auf alle Fälle, und es gibt ja nur ein LimitSell und ein LimitBuy das gefillt werden kann. ? So wie ich das verstanden habe, würde es an der EUREX anders laufen. Die im Orderbuch stehende Limit Sell wird zum angegeben Preislimit ausgeführt (950). Also kriegt der Verkäufer nur seine mindestens geforderten 950 und der Käufer kommt 50 günstiger weg. oder irr ich mich. @Krümel: aber danke für die Info, schön das wir das gleiche gefunden haben ;)

ok, kanns mir selbst beantworten: Quelle Eurex