Day-Night System

Discussion in 'Automated Trading' started by syswizard, Jul 15, 2019.

  1. ph1l

    ph1l

    If the price pairs (prev_close_price, today_open_price) were
    (100, 50) (50, 60) (60, 75)
    and you started with $100, the result would be -$50 + $10 + $15 == -$25 for an average of -$8.33

    If the test used
    (today_open_price / prev_close_price - 1) * 100
    the daily results would be -50, 20, and 25, and the average would be -1.6667

    Using
    ((today_open_price - prev_close_price) / min(today_open_price, prev_close_price)) * 100
    the daily results would be -100, 20 and 25, and the average would be -18.3333

    Neither of these are perfect. An alternative would be the geometric mean of today_open_price/prev_close_price to get the compound growth rate == ( ((50 / 100) * (60 / 50) * (75 / 60)) ** (1/3) == 0.90856029641607
    Then it would be possible to get the final result as $100 * 0.90856029641607 * 0.90856029641607 * 0.90856029641607 - $100 == -$25

    For the previous data, using (today_open_price / prev_close_price - 1) * 100, the mean per-trade result would be 0.0354375702680139 percent (not much different)

    And the geometric mean of today_open_price/prev_close_price == 1.00030503962027 which is a compounded, per-trade growth rate of 0.030503962027 percent (also not much different).

    So as you and others have noticed, always buying at the close and selling at the open would likely lose money after transaction costs.
     
    #21     Jul 17, 2019
    tommcginnis likes this.
  2. I am going to try to revisit this system in Multicharts using only SPY and QQQ going back to 1999 ...and add a trend overlay to see if the performance can be improved by going short the close in bear markets or in significant down-trends. Because of transaction costs, I don't see the value of looking at each of the components of these ETF's.
     
    #22     Jul 18, 2019
  3. ph1l

    ph1l

    I tried a variation of buying at the next close and selling at the following open with a genetic programming rule generator that I wrote.

    An example of a rule is:
    upload_2019-7-19_22-41-6.png

    where the inputs are the last five days of SPY close prices (adjusted for dividends and splits), VIX close values, and 13-week treasury bill rate close values.
    The rule returns NAN (not a number) for no suggested trade or 1 when it suggests buy SPY at the next close and sell at the following open.

    The rule summary has the number of input data records (6639 with input data for trades starting 1993-02-08 through 2019-07-17), the number of times the rule would have indicated to buy (1664), and the number of successful simulated trades (917) where success means the trade had a simulated gain in the top 40 percent of values. For this set of data, that simulated gain threshold was 0.143 percent. The mean value of 0.127258 corresponds to a mean gain of
    exp(0.127258 / 100)-1 percent or 0.1273 percent. This is somewhat better than the mean gain of 0.0380 percent for buing at the close and selling at the following open over the entire history period.

    The body of the rule can be thought of as a simple programming language with registers (e.g., R0) to store intermediate calculations, constants (e.g., 0.982902), inputs (e.g., IRX001 for the 13-week treasury bill rate from one trading day ago), and statements with operators (*, +, <=, etc.). Each if statement has a single nested then statement (can be another if statement) which runs when the condition of the if statement evaluates true. The language has no else part for if statements.

    The three input types, SPY, VIX, and IRX, are incompatible with each other. This means any operation with two incompatible inputs has a result of NAN and if statements with incompatible or NAN operands evaluate false. Registers take on the input type of whatever they are assigned to.


    This will need some more work before I'd be willing to risk money on it.
     
    #23     Jul 19, 2019
    tommcginnis likes this.