Using median to study seasonal strategies

[mjedlin66]

I wanted to share some recent analysis with you all.

I've been working to add median to tspcalc, both for the seasonal builder and for the seasonal strategies table.

Median is not 100% completed yet. Namely, you can't see the median data AND it's only calculated medians for 2004-2015 at present. It's still calculating the later years.

This strategy was made using the Seasonal Builder using "Highest Median, 2004-2015" and no other criteria.

https://www.tspcalc.com/seasonal.php?ID ... arks=C-S-I

Because it was made using 2004-2015 data, I look at how it's done from 2016- to date (10/11/2024), compared to the three equity funds:

Total Return 348.37
C Fund Total Return 230.44
S Fund Total Return 143.72
I Fund Total Return 85.05

This strategy beat the C fund 6 years out of those 9. It performed poorly in 2016 and 2024, notably, both election years.

[mjedlin66]

Edit:

More on election years. 2020 was also an election year but the strategy performed well. I did the math. If you used this strategy for every non-election year, and switched to 100% C for every election year, you'd have returned 553% give or take over the same time period.

[bloobs]

I wanted to share some recent analysis with you all.

I've been working to add median to tspcalc, both for the seasonal builder and for the seasonal strategies table.

Median is not 100% completed yet. Namely, you can't see the median data AND it's only calculated medians for 2004-2015 at present. It's still calculating the later years.

This strategy was made using the Seasonal Builder using "Highest Median, 2004-2015" and no other criteria.

https://www.tspcalc.com/seasonal.php?ID ... arks=C-S-I

Because it was made using 2004-2015 data, I look at how it's done from 2016- to date (10/11/2024), compared to the three equity funds:

Total Return 348.37
C Fund Total Return 230.44
S Fund Total Return 143.72
I Fund Total Return 85.05

This strategy beat the C fund 6 years out of those 9. It performed poorly in 2016 and 2024, notably, both election years.

Hi MJ - i'm still trying to wrap my head around this, and perhaps you can explain further. In the link you provided, should we consider the values labeled as Mean as the newly calculated Median values?

If so, are you also planning to add associated indicators IQR (interquartile range) to replace the standard deviations in current use?

[mjedlin66]

No, median isn't presently displayed. Mean is mean.

BUT at this point in time, I was able to use the seasonal builder "best fit" for median, which again, isn't shown yet. So the highest median for each month was optimized into a 12-month strategy.

[bloobs]

No, median isn't presently displayed. Mean is mean.

BUT at this point in time, I was able to use the seasonal builder "best fit" for median, which again, isn't shown yet. So the highest median for each month was optimized into a 12-month strategy.

Oh ok, thanks for clarifying. I'm curious how you structure the 2004-to-present daily price data for the funds. Is the table just simply [date], [fundname], [price]? Maybe I can help calculate these median and associated IQRs more efficiently.

[mjedlin66]

Yes. There is a share price table that is exactly what you describe.

Then there is a table derived from that which I call "dailychange" which is just

Dailychange = 1 + (today price - previous day price)/previous day price

Calculations of any timespan (three days, 1 week, 3 years, it doesn't matter) just multiply the dailychange values together and then subtract 1. I am aware it is technically more efficient to use prices on different dates. But it is plenty fast as is.

The builder goes a step further. There is a Returns table which calculates and stores the return for the a whole month based on one entry per [year] [month] [strategyID]

And then it derives a statistics table from the returns table. So it combines 2004-2009, for example. Calculates mean, min, max, median etc for 2004-2009 and stores it in a separate table specifically for 2004-2009. So all statistics are pre calculated. The user's entry for years determines which pre calculated table to use. This makes builder queries much faster for the user.

[bloobs]

Yes. There is a share price table that is exactly what you describe.

Then there is a table derived from that which I call "dailychange" which is just

Dailychange = 1 + (today price - previous day price)/previous day price

Calculations of any timespan (three days, 1 week, 3 years, it doesn't matter) just multiply the dailychange values together and then subtract 1. I am aware it is technically more efficient to use prices on different dates. But it is plenty fast as is.

The builder goes a step further. There is a Returns table which calculates and stores the return for the a whole month based on one entry per [year] [month] [strategyID]

And then it derives a statistics table from the returns table. So it combines 2004-2009, for example. Calculates mean, min, max, median etc for 2004-2009 and stores it in a separate table specifically for 2004-2009. So all statistics are pre calculated. The user's entry for years determines which pre calculated table to use. This makes builder queries much faster for the user.

Helpful to confirm that you derive a series of separate views from the initial raw data to keep them normalized and easier to maintain; i had thought you were appending the statistics records into additional columns on the base table. Now to find the time to actually code this out oy!

[mjedlin66]

Median is now available to all users in the Seasonal Builder.

[renny443]

Even though the median data isn’t fully in yet, it’s cool to see it beat the C Fund in most years, especially with the seasonal approach.