INVESTOX-Forum

Hallo trader-hawk,

danke für Dein positives Feedback in Bezug auf unsere Arbeit. :o)

Wenn Du mit den CSV-Daten aus dem Download für den FDAX arbeitest und Reiners KnowledgeFlow unverändert übernimmst, ist es in der Tat so, dass auf Basis dieser Daten die KK abwärts verläuft.
Das ist auch in Video 2 gegen Ende so zu sehen.

Der Grund dafür liegt aber eher nicht in der Prognose der SVM.
Die Predict Output-Datei der SVM enthält ja folgende beiden Prognosen –

a) die bereits angesprochene Prognose der ROC, die auch Basis für die Signalgebung im Beispiel-Handelssystem ist
b) die Prognose der Schlusskurse


Die Prognose der Schlusskurse wurde im Beispiel-Handelssystem nicht für die Signalgebung eingesetzt. Sie wurde aber im mittleren Teilchart zur visuellen Prüfung gechartet.
Wenn Du Dir diese Prognose anschaust, wirst Du feststellen, dass der tatsächliche Kursverlauf für die Beispiel-Daten von der SVM eigentlich recht gut prognostiziert wurde.

Das negative Ergebnis für die mitgelieferten Kursdaten und das Beispiel-Projet resultierte eher daraus, dass für diesen Betrachtungszeitraum die einfache Abfrage der ROC-Schwelle > bzw. < 0 ungeeignet gewesen ist.
Hier müsste man sicherlich in nächster Zeit prüfen, ob man in Abhängigkeit vom Trendverhalten unterschiedliche Signalschwellen für die ROC in unterschiedlichen Marktphasen wählen sollte.

In die richtige Richtung geht hier meiner Ansicht nach die Arbeit von klexer, der ja bereits die Signalgebung in seinem Handelssystem differenziert in Abhängigkeit der Werte der ROC-Outputs betrachtet hat.
Auch ich möchte klexer dafür danken, dass er seine Ergebnisse veröffentlicht hat !!!!

Gerade im Forex-Bereich kann auch ich mir den Einsatz der SVM sehr gut vorstellen.
Viele werden es wissen – wir hatten in der Vergangenheit im Forex große Probleme damit, ausreichend lange und saubere Historien für konventionelle Systementwicklungen zu erwerben.
Solche Historien sind derzeit am Markt nicht verfügbar – werden aber für SVM basierte Systeme dann ja auch nicht mehr benötigt.


PS:
Die KK in der Grafik auf meiner Webseite steigt übrigens wieder, weil ich dort (nur für die Grafik) mit aktuelleren Kursdaten und leicht geänderten Zeitraum-Einstellungen gearbeitet habe. Die Webseite wurde ja erst erstellt, nachdem der Download schon einige Tage im Web stand.

.... ups jetzt habe ich gerade gesehen, dass mir in meinem letzten Beitrag ein Fehler unterlaufen ist.

In der Predict Output-Datei des Beispiel-Projektes wird doch nur der Ref(ROC(Close, 1, %), 1) prognostiziert!!!
Datum und Close werden nur durchgereicht, weil Investox diese Daten zur Bildung eines neuen Titels benötigt.
Close wird also nicht prognostiziert.

Sorry dafür - man sollte sich eben nicht mit zu vielen Dingen gleichzeitig beschäftigen.

Hallo Tobias,

mit folgendem Workaround ließen sich am Wochenende bei mir RTT-Dateien korrekt in Weka einlesen und verarbeiten:

a) Regions- und Spracheinstellungen umstellen -Englisch (USA) Datums-Format YYYY MM DD mit Leerzeichen
b) Export aus der RTT-Datei in txt-File über den Dateninspektor (max. 1-2 Tage)
c) Kopieren + Einfügen der Kurse aus der txt-Datei in Exel
d) Leerzeichen aus Datum mit Suchen/Ersetzen eliminieren
e) Punkte ggf. gegen Komma in Close austauschen (...könnte aber auch schon über die Regions- und Spracheinstellungen zu Beginn erfolgen)
f) als CSV-Datei abspeichern
g) in Weka einlesen und Ergebnis mit Textviewer gegenprüfen

Zu den gleich als nächstes kommenden Fragen :
Ja-meine Lösung ist derzeit noch kompliziert.
Ja- man kann den Vorgang automatisieren

Dazu muss aber jemand etwas Code schreiben - ich habe das bisher zeitlich noch nicht geschafft.
Ich gehe aber stark davon aus, dass diverse Programmierer unter den knapp 250 Anwendern sind, die sich das Data Mining EOD-Paket inklusive Videos bisher gedownloaded haben.

Vielleicht stellt ja der eine oder andere Programmier-Profi der Community eine elegantere bzw. automatisierte Lösung zur Verfügung.....

Zitat

Ist das Normal bzw. an was könnte das liegen?

Nein es ist nicht normal. Das Einlesen der Daten und die Berechnung der SVM erfolgt -wenn alles richtig läuft- in Sekundenschnelle.
Probier bitte einmal folgendes aus:

a) Schließe den Weka-KnowledgeFlow und beende Weka
b) Starte den Weka neu und öffne den KnowledgeFlow erneut.
c) Streiche die ersten 3 DataSet-Verbindungen (Rechsklick auf die roten Pfeile dann "DataSet" auswählen)
d) Klicke rechts auf den CSV-Loader , wähle "Configure" und wähle den Ort der AX.RAD Datei neu aus
d) Gehe auf den ersten der beiden CSV-Saver unten links, wähle aus dem Submenü "Configure" und gib unbedingt im Feld "Dateiname" ein passendes Prefix (z.B. Train) ein. Klicke dann auf Select Directory and Prefix.
e) Gehe auf den zweiten der beiden CSV-Saver unten rechts, wähle aus dem Submenü "Configure" und gib unbedingt im Feld "Dateiname" ein passendes Prefix (z.B. Predict) ein. Klicke dann auf Select Directory and Prefix.
f) Setze die ersten 3 Dataset-Verbindungen neu
g) Klicke oben links auf den CSV-Loader und wähle aus dem Submenü "Start Loading"

Geht es dann schneller ?

PS:
Die genannten Arbeitsschritte müssen immer ausgeführt werden, wenn ein *.kfml (i.e. Layout-File) geöffnet wird. Die *.kfml-Loayout-Files speichern die Pfadangaben für die Datenherkunft und die Output-Ordner nicht mit ab - deshalb müssen sie dort neu gesetzt werden.
Bei der Arbeit mit *.kf-Dateien müssen die Pfadangaben nicht neu gesetzt werden.
Sollte es auch mit *.kf-Dateien einmal zu Problemen beim Einlesevorgang kommen, sollte aber auch das Trennen und Neusetzen der ersten 3 DataSet-Verbindungen helfen.

Zusatzfrage:
Die Weka Heap-Size ist raufgesetzt, so wie das in der Liesmich.txt !!!! des Downloads beschrieben ist ?