Design Pattern approach - vs classical pattern approach - context and prune rules

Discussion in 'Strategy Building' started by harrytrader, Dec 19, 2003.

  1. coming soon - it's just to make you run your imagination for the moment :D
  2. Nevertheless I will join a picture which I will comment later on when I will feel less lazy to do so :)
    <IMG SRC=>
  3. I have borrowed the term "Design Pattern" to software architecture engineering. As said here Dirk Riehle and Heinz Zullighoven give a nice definition of the term "pattern" which is very broadly applicable:

    <FONT COLOR=BLUE>A pattern is the abstraction from a concrete form which keeps recurring</FONT> in specific non-arbitrary <FONT COLOR=RED>contexts</FONT>.

    Of course we are not in the field of software engineering and patterns used in software engineering won't be applicable, so it is the principles that I want to borrow. Notably the importance of contexts is crucial. Context is the difficult part of using patterns because it is not obviously explicit and often will stay implicit and fuzzy that's why design pattern approach in software engineering stays an art with trial and errors approach. Nevertheless this art is not savage it is codified to be reusable in similar contexts. If we come back to trading a context can be for example that some patterns have significance only after market has made a strong bullish trend. Precondition is a closed concept and its importance has growed recently only in object programming as quality software becomes more and more questionable with so many bugs appearing. Preconditions are used in so-called "design by contract" as discussed here:
    Preconditions are basic requirements which protects the user of the pattern. For example you cannot divide a number by zero so precondition is number must be different from zero. As for trading an example of precondition is that a buy level must obviously be lower than a sell level.
    Prune rules are not used in software engineering but rather in chaos theory patterns studies or artificial learning intelligence. I use the term as "super" preconditions which combines preconditions with some contexts notably dynamic contexts (the distinction between static and dynamic analysis is also a useful aspect of design pattern in software engineering) for example when market opens at such or such level.

    That's all about generalities today before I enter into details. Next I will talk about the difference between a "design" pattern and a traditional trading pattern.

  4. Finally I won't explain more it's too theorical for the vast majority instead I have decided to show the implementation through "Baby Trader" whose objective is Win/Loss ratio > 3 to 10+, only 3 points stop and %>75 with AUTOMATIC TRADE :D see