Hallo DownUp,

mein Tai Pan 13 hat scheinbar nicht die gleiche Anzeige wie Dein Fenster "Listenkonfiguration".
Bei mir fehlt die Zeile: "Nur Kurse berücksichtigen vom ...".

Deinen Wunsch zur Rechenzeitverkürzung kann ich nachvollziehen.

Im Fenster "Listenzeitraum", von Dir im 1. Bild rot eingerahmt,
- kann man sowohl den gewünschten Zeitraum
- als auch nur die gewünschte Anzahl von Tagen einstellen. Es ist ein bißchen hakelig.

Nimmt man nur die Tageszahlangabe, dann sollten immer die letzten gewünschten Tage verwendet werden.
So gesehen wärst Du dann immer up to date. Ich habe es allerdings nicht probiert. Bei Listen hatte ich noch kein Rechenzeitproblem.

Vielleicht könnte man das Zeitproblem auch programmseitig aus dem Weg schaffen, falls Du Deine Liste programmiert hast. Ein Schwerpunkt wäre da die Verwendung von Variablen für die Kursdaten. Die müßten dann nicht jedes Mal aus der Datenbank gelesen werde. Bei Verwendung verschiedener Kursdaten und zusätzlichen Indikatordaten geht das sehr zu Lasten der Rechenzeit. Das habe ich schon ausgetestet.

Was meinst Du, würde Dir das helfen?

Schöne Grüße
Taxus

Hallo Taxus,

danke für die Informationen zu Deinen Testergebnissen.

Für Tai-Pan Nutzer die selber Formeln schreiben halte ich hier somit folgende Regel fest:

Werden in einer Formel Close , High, Low, Open und Volumen-Daten und/oder werden mehrere Indikatoren (SMA, ROC etc..) in Kombination verwendet so kann die Rechenzeit verkürzt werden, indem im Kopf der Formel die C, H, L, O und V Daten zuerst an Variablen übergeben werden. Anschliessend werden in der Formel diesen Variablen eingesetzt.

Im Kopf der Formel müsst Ihr dann also zuerst die Übergabe der Daten aus der Datenbank an Variable programmieren. Da die Daten der Datenbank Kursarrays (Zahlenreihen-Kombination aus: Index-Reihe, Datum-Reihe, Zeit-Reihe, Kursdaten-Reihe) sind, erben die Variablen automatisch den gleichen Charakter und werden auch zu Kursarrays:

{Übergabe Kursdaten an Variable}
aC:=C;
aO:=O;
aH:=H;
aL:=L;

Verwende ich in der Formel die “Schlüsselwörter“ C, O, H, L so übergebe ich dem Programm offenbar indirekt die Anweisung „Lese Daten aus der Datenbank“ Lese ich hingegen die Daten zuerst in Variable ein und verwende dann diese Variablen in der Formel so holt das Programm die Daten nur noch aus dem programmseitig angelegten Zwischenspeicher. Daraus rührt dann eine Rechenzeitverkürzung.

Hinweis: Weiss ich als Formelschreiber im Voraus, dass ich für meine Zielsetzung nur 256 Daten (1 Jahr) benötige, dann kann ich auch bedingen, dass nur Kursdaten ab einer bestimmten Index-Nr. eingelesen werden. Angenommen die Kursreihe für Nestle beginne mit der Index-Nr. 1 und endet heute mit der Nr. 5591, dann könnte ich programmieren:

aC:= if(Index > Count(C) -256, C, Leer);
oder:
aO:= if(Index>Count(C)-256, Kurse.Lesen („WPK-Nummer“, „Open“, „Tage“),Leer);

Count(C) misst immer die Anzahl Elemente einer Kurs- oder Datenzahlenreihe. In meinem Beispiel mit Nestle ergibt Count(C) = 5591:

Das Verkürzt zwar nicht die Rechenzeit, weil immer noch pro Titel die ganze Zahlenreihe bzw. Kursarray eingelesen wird. Erstelle ich aber eine Binary Wave wie von Herrn Goerke vorgestellt, so kann ich „Zwischenresultate-Zahlenreihen“, welche ich vom Debugger Fenster „Variable“ nach Excel kopiere, in Excel visuell schneller kontrollieren. Statt durch 5‘000 Zahlen (z.B. Nestle) muss ich mich nur durch 256 Zellen durchscrollen.

Mit freundlichen Grüßen
DownUp

Ich stimme mit allen Punkten mit down up überein, bis auf diesen:

---

Downup schrieb:
Dieses Konstrukt -> Datenbank an Ort A -> Übertragung zu Endkunde an Ort B ist im Zeitalter von Clouds nicht mehr zeitgemäss und entspricht nicht der kommunizierten Zielsetzung von Carlyle. Vom Arbeitsablauf her gesehen ist es ja auch so, dass historische Daten (bis zu 10‘000 Handelstage) vom Chartanalyse-Anwender nur punktuell benötigt wird, nämlich dann, wenn er eine spezifische Handelsstrategie anhand historischer Daten testen will. Für das effektive Eingehen von Positionen am Markt werden vom Anwender nur die aktuellsten ca. 1300 Handelstage-Daten benötigt.

---

Ein Chart ist für mich umso wertvoller, je länger er zurück geht. Mit den 1.300 Handelstagen bin ich nicht einverstanden. Das ist viel zu wenig.

Bei den übrigen Punkten stimme ich Ihnen voll zu. Auch Ihre Ausführungen bzgl. Carlyle fand ich sehr interessant und aufschlussreich.

Hallo an alle und natürlich L+P,

wir haben tatsächlich ganz unterschiedliche Meinungen zu dem was notwendig ist und was nicht.
Das kann einem aber auch nicht überraschen.

Und wenn das Signalmodul nur für mich wäre, da es keine weitere Zustimmung aus dem Forum zum Signalmodul gibt, was ich beim besten Willen nicht verstehen kann, bitte ich L+P sehr darum, daß das Signalmodul erhalten bleibt.

Man muß es ja nicht nutzen und preiswerter wird Tai Pan dann sicher auch nicht werden.

Ich werde gerne noch einmal die Berechtigung des Signalmoduls aus meiner Sicht beschreiben.
Alle Gegner des Signalmoduls bitte ich dann einfach mal um Zurückhaltung.
Wir brauchen ja nicht zum x-ten Male betonen was uns nicht paßt.

Dazu braucht es allem Anschein weit mehr nachvollziehbare Argumente als bisher von mir dargelegt.
Das übernehme ich sehr gerne.

Ich möchte L+P ebenfalls bitten, nicht von der gesamten Kurshistorie abzuweichen. Ich denke auch nicht, daß es mit weniger Daten preiswerter werden wird.

Woran mir ganz besonders gelegen ist, ist daß Tai Pan zu einem führenden Börsensoftwareprogramm ausgebaut werden könnte, wenn man mit den Anwendern zusammen arbeiten würde.
Mir ist schon klar, daß das ein außergewöhnlicher Weg wäre.
Der sollte sich aber extrem für L+P und uns lohnen und zwar durch bedeutend mehr Abonnenten.

Das würde allerdings schon ein ganzes Stück Arbeit erfordern. Dazu braucht es gute Entwickler mit entsprechendem Sachverstand, eine überragende Börsensoftware und das beste mögliche Angebot an Kurs - und Fundamentaldaten.

Mit großem Nachdenken habe ich die Ausführungen von DownUp gelesen, daß hier ganz andere Adressen vielleicht den Lauf der Dinge bestimmen. Ob das eher gut oder nicht so gut für uns Anwender ist wird sich noch zeigen. Meine Bedenken sind da eher naheliegend.

Schöne Grüße Euch
Taxus

... aber eigentlich ging's ja hier ursprünglich um das Listenmodul.

Norbert

Hallo,

mir ist völlig klar, daß auch dieser Beitrag vordergründig nichts mit dem Listenmodul zu tun hat. Die von mir im Folgenden ausgeführten Kernaussagen sind allerdings verallgemeinernd als Verbesserungsvorschläge zu werten und beziehen sich im übertragenen Sinn u. a. auch auf das Listenmodul. Insofern sollte die Einordnung meines Beitrages an dieser Stelle gerechtfertigt sein, auch wenn er sich nochmals ausschließlich - sozusagen "exemplarisch" - mit dem Signalmodul und den Signalcharts befaßt. Das Signalmodul/der Signalchart ist als "Musterbeispiel" deswegen so gut geeignet, weil es, wenn ich mich richtig erinnere, bis ich vor kurzem so gut wie nie derart umfassend in der Diskussion/Kritik stand.

@ Taxus,

aufgrund meines beruflichen Hintergrunds in der IT-Branche mit intensiven Kontakten zu den unterschiedlichsten Unternehmensebenen, wurden von mir messerscharfe, auf den konkret diskutierten Sachverhalt bezogene, "objektive", (also möglichst nicht von persönlichen Meinungen geprägte) klare und somit auch für "Nichtfachleute" unmißverständliche, d. h. nicht fehlzuinterpretierende Aussagen zu bestimmten Sachverhalten erwartet, um optimale Entscheidungen treffen zu können. Diese Art der Argumentation ist mir in all den Jahren in Fleisch und Blut übergegangen, hat allerdings für "Normalanwender", die dies nicht "gewöhnt" sind, einen entscheidenden Nachteil: sie kann durchaus den Eindruck erwecken, ich sei überheblich, würde "Schwarz-Weiß-Malerei" betreiben und würde andere Leute bevormunden bzw. deren "Meinung" nicht akzeptieren bzw. tolerieren wollen. Dieser Eindruck ist allerdings falsch - es geht mir immer nur um die "Sache" - konkret die Signalcharts -; deshalb entschuldige ich mich auch nicht für meine Art der Argumentation. Allerdings entnehme ich Deinem Beitrag zum "Erhalt" der Signalcharts/des Signalmoduls, daß ich Dich mit meiner Argumentation über deren "praktischen Sinn" doch ziemlich "in die Ecke gedrängt" zu haben scheine. Dies tut mir wirklich leid.

Aus diesem Grund nun folgende Klarstellung zu Deiner "Entspannung" und zum Thema "Signalcharts":

Das Allerwichtigste zuerst: Es dreht sich bei Diskussionen - egal ob aus Sicht eines Unternehmens oder aus Anwendersicht - in den seltensten Fällen (d.h. wenn überhaupt, dann nur nachrangig,) um das "WAS" (also die Signalcharts), sondern praxisbezogen und vorrangig immer um das "WIE" - noch konkreter - WIE KOSTEN-/ZEITINTENSIV" (ist die Umsetzung eines Problems mit Signalcharts).

Bezogen auf die Signalcharts in Tai Pan bedeutet dies:

1) Wie sinnvoll (zeitsparend) können sie bezogen auf konkrete Anwendungen in Tai Pan eingesetzt werden?
2) Wie sinnvoll (zeitsparend) können sie in Tai Pan im Vergleich zu anderen Softwareprodukten eingesetzt werden?

zu 1) Sinn (Zeitersparnis) in Bezug auf konkrete Anwendungen in Tai Pan

Meine im allerersten Post beschriebene Anwendung war
a) der Einsatz eines Signalfilters zur Gewinnung von Signaldaten. Diese wurden benötigt:
b) für Kaufentscheidungen
c) für weitere Auswertungen im Sinne eines Handelssystemtests (= Ermittlung von Kennzahlen zur Bewertung vieler einzelner Trades)

zu 1a) Signalchart versus Signalfilter
Durch die Verwendung eines Signalfilters (konkretes Beispiel war ein EMAxEMAy-Signalfilter), können - dank der prinzipiell sehr anwenderfreundlichen und relativ flexiblen Einstellmöglichkeiten von L&P (wir setzten einmal voraus, der Filter würde "richtig" funktionieren) mehrere Varianten blitzschnell durchgetestet werden, da sich alle Parameter (x, y, Untersuchungszeitraum) leicht und schnell einstellen lassen.
Wie sieht im Vergleich dazu der Einsatz von Signalcharts aus? Vorgefertigte Signalcharts zum Thema Indikator-Indikatorschnitte gibt es nicht. Sie müssen für jede zu testende Variante erst erstellt werden. So "leicht" (wie von Dir behauptet) ist das aber nicht: Jedes Signal muß vom Anwender codiert werden - das macht Arbeit und erfordert gewisse Programmierkenntnisse/einen gewissen Programmieraufwand (wobei wir wieder bei der Dringlichkeit eines sinnvollen Programmierhandbuch wären). Ferner muß für jede Variante bezüglich Indikatoreinstellung/Untersuchungszeitraum ein nach Deinen eigenen Worten "genau zugeschnittenes" Layout hinter die (Signal-)Charts "gehängt" werden. Wie lange soll das dauern? Ist das - bezogen auf den Zeitaufwand - eine sinnvolle Anwendung? Der Anwender "Michael" hat in diesem Zusammenhang Signalcharts völlig zu recht als eine relativ "starre" Lösung bezeichnet.

zu 1b) Signalcharts zur Umsetzung von Kaufentscheidungen

Für Kaufentscheidungen ist die Betrachtung einer (auf die zukünftige Entwicklung des Assetts gerichtete) Chartanalyse durchaus sinnvoll.
Sie kann allerdings auf Basis eines jeden x-beliebigen Charts ("Signalchart", "Filterchart" bzw. "Normal"-Chart mit einem nach Anwenderwunsch bezüglich Chartart, Indikatoren etc. konfigurierten und "dahintergehängten" Layout) durchgeführt werden; ein spezieller Signalchart mit eingeblendeten historischen "Signalen" kann (theoretisch) natürlich verwendet werden, ist aber in keinster Weise erforderlich. Werden zusätzliche Informationen benötigt, so bringt die Anzeige "historischer Signale" gar nichts, da die Ermittlung sinnvoller "Kennzahlen" nur aus dem Signalchart heraus (Stichwort Profittester) auch nach Deiner Meinung völlig unzulänglich sind. Sinnvolle Zusatzinformationen ergeben sich erst dann, wenn man die Signale der Signalcharts mit entsprechenden Informationen aus Listen des Listenmoduls "von Hand" verknüpft. Das hat dann aber nichts mehr mit den Signalcharts in Tai Pan per se zu tun. Deshalb war mein Urteil in diesem Zusammenhang: Signalcharts sind völlig überflüssig! Zu dieser Aussage stehe ich nach wie vor.

zu 1c) Implementierung (Verwendung) von Signalcharts im Sinne eines "Backtests"

Deine Aussage/Meinung hierzu war



Da stimme ich Dir voll und ganz zu. Selbstverständlich kann man in Tai Pan auch "Backtests" durchführen. Da Tai Pan bereits recht gut an eigene Anwenderbedürfnisse angepaßt werden kann und obendrein noch eine eigene Programmiersprache besitzt, ist in Tai Pan (in den Händen eines geschickten und effizienten Programmierers) theoretisch ohnehin nahezu "Alles" möglich (zumindest, wenn die Funktionen der Programmiersprache dies erlauben) - insofern kann Deiner Meinung/Aussage nicht sinnvoll wiedersprochen werden.
Doch ist der Versuch, mit den Mitteln von Tai Pan einen "Backtest" durchführen zu wollen, in Bezug auf den dazu erforderlichen Zeitaufwand wirklich sinnvoll? Wer kennt sie denn überhaupt (gemeint sind alle Funktionen der Programmiersprache) und welcher Anwender kann denn derart schnell und effizient damit umgehen, um "schnell mal" eine sinnvolle Backtestmöglichkeit zu programmieren? Und wie definierst Du Deinen "Backtest"?

Zum Hintergrund: Ein "Backtest" besteht in der Regel aus zwei Komponenten: einer "grafischen" Auswertung (mit mehreren Charts; u.a. auch "Signalcharts", mehreren Equity-Kurven wie z.B. "Underwater"-Equity etc.) und einer "zahlentechnischen" Auswertung in Listenform. Die Signalcharts sind in Tai Pan bereits vorhanden, aber was ist mit den "Kennzahlen" eines Backtests in Listenform - schließlich ist das Listenmodul ja angeblich eine der anerkanntermaßen "besonderen Stärken" von Tai Pan?

Nun es gibt in Tai Pan zwar eine Unzahl vorgefertigter Listen, eine Liste zum Auswerten/Bewerten von Einzeltrades gibt es - ei, wer hätte das gedacht - leider nicht einmal ansatzweise. Die Berechnung vieler "Kennzahlen" eines "branchenüblichen" Backtests anderer Softwareprodukte ist - da hast Du auch wieder recht - nicht sonderlich schwierig - es reichen fast immer die vier Grundrechenarten. Allerdings umfassen die "Kennzahlen" eines "branchenüblichen" Backtests je nach Güte/Qualität und Möglichkeiten desselben so zwischen 30 und 80 Werte, d.h. Du müßtest für eine vergleichbare Qualität in Tai Pan zunächst eine Liste mit 30 bis 80 Spalten "von Hand" einrichten bzw. programmieren. Nun, da Du offensichtlich mit Tai Pan gerne "spielst", kannst Du selbstverständlich gerne bei Deiner Meinung bleiben. Ich "spiele" stattdessen lieber mit den unterschiedlichen Testparametern und den "Kennzahlen" - letztendlich also den Auswertungsergebnissen von Backtests - das erscheint mir im Hinblick darauf, ohne allzu viel Zeitaufwand lukrative Bedingungen für Handelsansätze zu finden, wesentlich effektiver.

Unabhängig von Deiner bzw. meiner Meinung/Vorliebe bezüglich irgendwelcher "Spielereien" kann jedoch objektiv Folgendes festgestellt werden:
Ein "branchenüblicher Backtest" erfordert - allerdings bei nur wenigen Kennzahlen - die Bildung von Teil- bzw. Zwischensummen. L&P hat - allerdings in einem anderen Zusammenhang - selbst bestätigt, daß eine Bildung von Teil-, Zwischen- bzw. Gruppensummen mit dem Listenmodul zur Zeit nicht möglich ist. Nun ist es durchaus vorstellbar, daß dies mit erheblichem Aufwand in irgendeiner Form "umgangen" werden kann - nur wer möchte das denn in Anbetracht des enormen zusätzlichen Zeitaufwandes wirklich tun?
Fazit: Deine "persönliche Meinung und Arbeitsweise" in allen Ehren - ein "branchenüblicher Backtest" ist - objektiv gesehen - in Tai Pan praktisch nicht möglich! Deshalb bleibe ich bei meinem Urteil auch in diesem Zusammenhang: Signalcharts sind völlig überflüssig!

Heißt das nun: Signalcharts sind generell in Tai Pan überflüssig? Nein, selbstverständlich nicht!

Wer meine Ausführungen genau genug gelesen hat, dem ist aufgefallen, daß ich im Zusammenhang mit 1b und 1c Signalcharts als völlig überflüssig beurteilt habe. Objektiv betrachtet sind sie lediglich oftmals überflüssig, denn es gibt immer noch den Punkt 1a) zu berücksichtigen - d.h. konkret: Es gibt natürlich jede Menge Signale, für die es in Tai Pan keinen effektiven, einfach zu bedienenden, vorgefertigten Tai Pan Filter gibt.
Für diese Fälle gilt: Entweder man programmiert sich einen entsprechenden Signalfilter, was, - wenn man mein im Forum dokumentiertes Codebeispiels eines solchen Filters betrachtet -, nicht unbedingt ein Kinderspiel ist, oder man erstellt sich, exakt so wie Du es in Deinen Beiträgen beschrieben hast, sinnvollerweise - weil wesentlich weniger zeitintensiv - den einen oder anderen Signalchart.
Darüberhinaus gäbe es, ohne daß ich hier noch weitere Beispiele "auswalzen" möchte, - völlig unabhängig von irgendwelchen persönlichen Vorlieben oder bevorzugten Arbeitsweisen - durchaus ein paar sinnvolle, weil effektive Anwendungsmöglichkeiten von Signalcharts in Tai Pan.

Konkret heißt das: Auch ich benutze Signalcharts in Tai Pan in dem Kontext, in welchem der Einsatz von Signalcharts objektiv sinnvoll ist.
Das Problem hierbei: Der Einsatz von Signalcharts in Tai Pan ist in relativ wenigen Fällen objektiv sinnvoll.

Die Begründung hierfür ergibt sich aus der Beantwortung von Punkt 2) welche sich zunächst mit der Frage nach dem WIE befaßt.

@ alle

Wie (sinnvoll, effektiv) sind Signalcharts in Tai Pan im Vergleich zu anderen vergleichbaren Softwareprodukten (wie z.B. MetaStock) implementiert?

Zu diesem Punkt möchte ich "Michael" ausdrücklich um eine kurze Stellungnahme bitten, da er - ebenso wie ich - u.a. auch MetaStock aus seinem "Arbeitsalltag" als aktiver Börsensoftwareanwender - also aus der Praxis heraus - kennt.

Nun zum Vergleich: MetaStock verfügt - ebenso wie Tai Pan - über Signalcharts. In MetaStock sind die Signalcharts sinnvollerweise mit dem dort vorhandenen "Handelssystemtester" zur Durchführung von "branchenüblichen Backtests" verbunden. In der Praxis bedeutet dies:
Es werden die Testdaten für irgendwelche "Signale" in den Handelssystemtester eingegeben, d .h. es können Stop- und Zielkurse (neben mehreren anderen Stops) auf absoluter oder relativer Basis sowie weitere Daten wie z.B. der Testzeitraum eingegeben werden. Selbstverständlich müssen - analog zu den "Signalen" in den Signalcharts von Tai Pan - die "Signale" auch in MetaStock meist selbst codiert und eingegeben werden. Soviel zu den Gemeinsamkeiten. Jetzt zu den alles entscheidenden, signifikanten Unterschieden.
Nach Eingabe der Testdaten startet man den Test und nach wenigen Sekunden liegen die Testergebnisse (also die Zahlenwerte in Listenform) vor. Im Prinzip genügt ein Mausklick (die "Umschaltung" ist bei den einzelnen MetaStock-Versionen etwas unterschiedlich) und man kann sich für eine charttechnische Beurteilung den zum Test dazugehörigen, in Bezug auf Signale und Testzeitraum automatisch angepaßten Signalchart (Equity-Chart) mit den entsprechenden Ein- und Ausstiegssignalen anzeigen lassen. Will man mit den Testparametern und Auswertungsdaten ("Kennzahlen") ein bißchen "spielen", so geht daß ganz einfach und schnell: Parameter ändern - Test starten - Ergebnislisten praktisch sofort auswerten - und per Mausklick automatisch die dazu passende charttechnische Signalchartdarstellung anzeigen lassen um sie zu beurteilen, kurz: "information" at your fingertip" in Reinstkultur.

Das "Besondere" daran bzw. in MetaStock ist also die sinnvolle, effektive und praxisorientierte Verknüpfung von ausführlicher, zahlenmäßiger Auswertung in Form diverser Ergebnislisten und grafischer Auswertung in Form von Signalcharts.

Was hat Tai Pan demgegenüber Sinnvolles entgegenzusetzen, obwohl es ebenfalls über Signalcharts und ein anerkannt hochwertiges Listenmodul verfügt? - Nichts -

Warum ist das so? Weil die Signalcharts in Tai Pan - im Gegensatz zu MetaStock - im Kontext wenig sinnvoll und noch weniger praxisorientiert implementiert wurden - es fehlt offensichtlich an praxisrelevantem Know-How!

Die eigentliche Beantwortung von/Meinung zu Punkt 2) möchte ich somit den anderen Tai Pan-Anwendern - sofern sie denn andere Softwareprodukte, die einen sinnvollen Vergleich überhaupt gestatten -, kennen, selbst überlassen.

Welche Schlüsse/Lehren lassen sich daraus ziehen:

1) Das Beispiel Signalcharts ließe sich auf sehr viele andere "Features" von Tai Pan übertragen - (Ich allein könnte den überwiegenden Teil der Programmfunktionalitäten von Tai Pan "verbal in Schutt und Asche legen"; für den "Rest" findet sich mit Sicherheit noch der eine oder andere Tai Pan-Anwender) - selbstverständlich immer mit der Bemühung um logisch nachvollziehbare Argumente zur Begründung, möglichst mehrfache Anwendungsbeispiele zur Verdeutlichung und - falls möglich - mit passenden Vergleichen zu anderen Softwareprodukten zwecks objektiver Bewertung.

Das Ergebnis ließe sich bestimmt in wohlwollenderer Form präsentieren als ich das tue - es wäre trotzdem in vielen Fällen immer das Gleiche.

2) Aus diesem Grunde kann man sich das weitere "Durchhecheln" einer endlosen Latte von Programmfeatures sparen - es gilt "pars pro toto" - in nahezu jeder Hinsicht.

Das bedeutet: Praktisch müssten nahezu alle Features in Tai Pan sinnvollerweise nachgebessert werden - die Frage lautet nicht WAS? sondern WIE?

3) Genau aus dem gleichen Grund (nicht WAS sondern WIE) ist ein Vergleich von Programmfeatures von Tai Pan mit den gleichen Features vergleichbarer Softwareprodukte weitestgehend sinnlos und überflüssig. Während ein Signalchart in MetaStock aufgrund seiner Implementierung (sinnvolle Verknüpfung zu anderen Programmfeatures) ein mächtiges und effektiv einsetzbares Tool ist, kann man mit dem Signalchart in Tai Pan, ebenfalls aufgrund seiner Imlementierung (fehlende Verknüpfung bzw. fehlende Programmkomponenten), nur in wenigen Fällen die "Maus hinter dem Ofen hervorlocken" - er ist ein vergleichsweise stumpfes "Multifunktionstool" (ähnlich dem gleichnamigen "Billigteil" aus dem Baumarkt) mit dem man theoretisch "Alles" praktisch jedoch tendenziell eher "Nichts" machen kann - völlig unabhängig davon, ob man "gerne" damit arbeitet oder nicht.
Hinzu kommt, daß die (verbliebenen) Möglichkeiten eines Signalcharts subjektiv von unterschiedlichen Anwendern völlig unterschiedlich "bewertet" werden. Kurzum: Der im Forum angesprochene "flächendeckende" Vergleich der Programmfeatures von Tai Pan mit anderen Softwareprodukten ist verplemperte Zeit - deshalb werde ich mich daran auch nicht beteiligen.

4) Es fehlt L&P an praxisrelevantem Know-How! Na und? Nicht jeder, der schnelle Autos baut, muß auch Rennfahrer sein! Peinlich wird die Sache doch erst dann, wenn der Autobauer dem Kunden ein "Goggomobil" aufschwatzen will, mit dem Hinweis darauf, dieses sei im Verhältnis zu einem Porsche Turbo Targa das "bessere und schnellere" Auto, weil es im Verhältnis zu diesem prozentual mehr Motorleistung "auf die Räder" bekommt. Wie Herr Albrecht bereits festgestellt hat, gibt es weit mehr als 1000 Forumsmitglieder, die mit Sicherheit auch an der Börse aktiv sind. Genügend praxisrelevantes Know-How ist also bereits vorhanden - nur eben nicht bei L&P selbst, sondern bei L&P-Kunden! Was liegt näher, als beide Komponenten in Form einer sinnvollen Kooperation "auf Augenhöhe" miteinander zu vereinen: Das Know-How kommt weitestgehend von den Anwendern, die softwaremäßige Umsetzung erfolgt weitestgehend durch L&P. Das wäre eine sinnvolle Symbiose, die darüberhinaus das "Abchecken" sinnvoller Programmfeatures in anderen Softwareprodukten völlig überflüssig machen würde. Alle erforderliche Informationen und Bewertungen sind bereits in den Köpfen von L&P-Forumsmitgliedern enthalten. Man muß dieses Potential nur nutzen wollen - das geht allerdings nur in Form einer echten Kooperation.

Die bisherige Art der Softwareentwicklung bei L&P in der Form "L&P entwickelt Programmfeatures für Kunden" ist im wahrsten Sinne des Wortes ein "Auslaufmodell" - es bedeutet aus meiner Sicht: Es müssen in einer Vielzahl von Folgeversionen regelmäßig jede Menge "Löcher" gestopft werden.

Herr Schebaum hat von Seiten von L&P bereits ein gewisses Interesse signalisiert.

Na denn - packen wir es an

hound dog

Hallo hound dog,

danke für Deine Ausführungen.

Von uns hat wohl Jeder seine persönlichen Anwendungen, die er mit Tai Pan realisieren will und vielleicht auch kann.
Ich nutze z.B. das Depotmodul gar nicht. Ich kenne das Alte und vom Neuen lese ich nur Euere zahlreichen Kritiken. Mir würde es aber nicht einfallen generell den Sinn eines Depotmoduls zu hinterfragen.

So ist es bei mir mit dem Signalmodul.
Ich kann nutze es ohne große Mühe nutzen, von komplizierten Anwendungen und erforderlichen Programmierungen abgesehen.
Mit der Signaldarstellung über die gesamte Charthistorie kann ich schnell sehen, ob die Handelssignale zu einem positiven Gewinnsaldo führen werden.

Aus jedem Signalsystem kann man den Backtest mit einem einzigen Programm erledigen, und Jürgen, man kann wahrscheinlich alle denkbaren Auswertungen berechnen lassen.
Das Backtestprogramm dafür ist für alle denkbaren Anwendungen immer gleich.

Schwierig und aufwendig ist in aller Regel nur die Programmerstellung der Handelssignale.
Da es für die Bedingungen der einzelnen Handelssignale unendlich viele Möglichkeiten gibt, kann man aus meiner Sicht dafür auch keine globalen Backtests vorbereiten auch andere Softwareprogramme sollten das nicht können, weil sie die Bedingungen der Nutzer nicht kennen, allenfalls kann man z.B. für ähnliche Anwendungen Module schaffen, die kombiniert und angepaßt werden können.

Ein Layout zu schaffen ist kein großer Aufwand sondern nur eine einmalige Leistung.
- Man gestaltete einen Chart mit der gewünschten Anzahl von Einzelcharts für Tages-, Wochen-, Monats- und Jahreskurse.
- Die Signale sind dann mit Pfeilen für Kauf und Verkauf eingetragen.
- In jedem Fenster werden je ein "Indikator"-Fenster mit Backtest-Ergebnissen ohne und mit Gebühren angehängt.
- Dazu die individuelle Ansicht und das ist schon alles.

Das ist sicher schnell hingeschrieben und erfordert schon Zeit.

Aber mit einem solchen Layout kann man dann seine Kataloge schnell durchblättern, eine Liste erstellen, einen Filter fahren und vielleicht sogar ein Makro anlegen. Dann wäre alles bis auf die Käufe und Verkäufe automatisiert.

Zeit könnte man sich einsparen, wenn man im Team daran arbeiten würde.
Mir würde das sehr helfen.

Erstmal würde sofort bekannt, ob das schon gelöst wurde, und ob es sich lohnt, weiter daran zu arbeiten.
Damit drückt man Niemandem seine Meinung auf. Jeder kann es ja trotzdem versuchen, weil er halt anderer Meinung ist und die Erfahrung selbst machen will. Das ist doch ganz klar. Das geht mir doch genau so.

Schöne Grüße
Taxus